From oej@edvina.net Mon Jul 1 00:44: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 A91B021F8F15 for ; Mon, 1 Jul 2013 00:44: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 fQPisQ9b2gl4 for ; Mon, 1 Jul 2013 00:44:03 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id D89B221F8EC3 for ; Mon, 1 Jul 2013 00:44:02 -0700 (PDT) Received: from [192.168.40.15] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 03ECC93C1AF; Mon, 1 Jul 2013 07:44:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Olle E. Johansson" In-Reply-To: Date: Mon, 1 Jul 2013 09:43:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0CF0F686-FB6B-4F87-9E3D-09BB1BB750FB@edvina.net> References: To: Dan York X-Mailer: Apple Mail (2.1508) Cc: "fluffy@cisco.com" , "Peterson, Jon" , "Olle E. Johansson" , Hadriel Kaplan , "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: Mon, 01 Jul 2013 07:44:03 -0000 28 jun 2013 kl. 22:34 skrev Dan York : >=20 > On 6/28/13 4:03 PM, "Peterson, Jon" wrote: >=20 >> 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 > 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: During all the years I've participated in SIPit, we've been able to = start tests on RFC4474 once and could send a message between two implementations, but not receive and acknowledge the other way. In the SIPit 30 summaries I find: "There was one RFC4474 Identity implementation present." SIPit29: "There were three RFC4474 Identity implementations present." ""** Identity There were several SIP Identity implementations present. We tested = creating and verifying the Identity assertions at proxies. It wasn't immediately = obvious to some=20 implementers that the resource pointed to by the Identity-Info URI had = to be DER=20 encoded (a result of the requirement to use application/pkix-cert). = Unfortunately,=20 the tar encoded at the end of 4474 has .cer files in it that are PEM = encoded." RFC 4474 was published in 2006, and in 2011 we got the first = interoperability test between two implementations at SIPit to work one-way. Just FYI. /O= From ekr@rtfm.com Mon Jul 1 06:39: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 35E3E11E80D5 for ; Mon, 1 Jul 2013 06:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.046 X-Spam-Level: X-Spam-Status: No, score=-102.046 tagged_above=-999 required=5 tests=[AWL=0.930, 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 uYlG3S3l2b4J for ; Mon, 1 Jul 2013 06:39:03 -0700 (PDT) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2493F21F9310 for ; Mon, 1 Jul 2013 06:39:03 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id f14so2049563qak.7 for ; Mon, 01 Jul 2013 06:39:00 -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=P7PKZEkO0W5XG8VUeRlHIeJ/uMdS5n9FmdTu5blN6jA=; b=A/u0hgVoBF+/fDK7WfoMxi2oWM3o0qo305dQ/9DRkCz6/ZnbDeICoI9NOWLWQs9v7m NEWAmM0/VRk2yzch0kK0ELzNpM0It3FPuq+yr20wqFlJazow263wt17u0YMuZQpFb9mI pJGW0JptVwfVuMcNINpq+i+GoaGXscOcS5xzX19LLjL14x+nlfy/+pLLMgi4CmJi+Gj9 KkL2GHOWkbNHZXl3tDS+yQImV2lBnuMZz+EHMILCLauJeG59IakV9dlpWFun5rimtqgv uw5Kea1ZFTlar07DhcfPs6Pws9nBI9GB/Tn9/p9VzcMYLaPnFdjR8hHORqVTOwUQnAAv ApKQ== X-Received: by 10.49.83.37 with SMTP id n5mr31492204qey.57.1372685940037; Mon, 01 Jul 2013 06:39:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.94.137 with HTTP; Mon, 1 Jul 2013 06:38:19 -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: Mon, 1 Jul 2013 06:38:19 -0700 Message-ID: To: "DOLLY, MARTIN C" Content-Type: multipart/alternative; boundary=047d7b6da166d82dc204e07359ac X-Gm-Message-State: ALoCoQnrnjZFZ92fM46xOztBChKnFIOWcjyd5W3OTLZ47Mp5apiFJjdO7JgrlkpzRCVbUSLZVoj0 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: Mon, 01 Jul 2013 13:39:09 -0000 --047d7b6da166d82dc204e07359ac Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable It might help to clarify my position here... >From a technical perspective, most of the stuff on a smartphone is an app, including the dialer. >From a user's perspective, the dialer is something built into the phone.. If we build something that requires the user to replace their dialer with something they download, that's not going to be very successful. >From the perspective of what we can build, however. since we know the dialer is just general purpose code running on the phone, and we know that downloadable apps can do DB lookups as calls come in, we know that there's no major technical obstacle to the smartphone vendor building a dialer that does such lookups. This of course does not mean that they will, but means that a design that depends on it is feasible technically. Hope that helps. -Ekr On Sun, Jun 30, 2013 at 1:32 PM, Eric Rescorla wrote: > > > > 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 thoug= h >> she has a smart phone. This is the user we have to protect=85 do you agr= ee? >> > > 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 t= o > 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 > builtin > 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 > > --047d7b6da166d82dc204e07359ac Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
It might help to clarify my position here...

From a technical perspective, most of the stuff on a smartphone= is an app,
including the dialer.

From a user's perspective, the dialer is something built int= o the phone..
If we build something that requires the user = to replace their dialer with
something they download, that&= #39;s not going to be very successful.

From the perspective of what we can build, = however. since we know the
dialer is just general purpose c= ode running on the phone, and we know
that downloadable app= s can do DB lookups as calls come in,
we know that there's no major technical obstacle to the smar= tphone
vendor building a dialer that does such lookups. Thi= s of course does
not mean that they will, but means that a = design that depends on
it is feasible technically.

Hope that helps.
-Ekr



On Sun, Jun 30, 2= 013 at 1:32 PM, Eric Rescorla <ekr@rtfm.com> wrote:



On Sun, Jun 30, 20= 13 at 1:20 PM, DOLLY, MARTIN C <md3135@att.com> 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 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 nu= mber of flavors,
depending on whether:

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

But I t= hink Henning's point is that there is nothing particularly difficult ab= out
the smartphone manufacturer adding this sort of functionality= to the builtin
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


--047d7b6da166d82dc204e07359ac-- From Henning.Schulzrinne@fcc.gov Mon Jul 1 06:44:48 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE9011E811B for ; Mon, 1 Jul 2013 06:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.657 X-Spam-Level: X-Spam-Status: No, score=-0.657 tagged_above=-999 required=5 tests=[AWL=1.942, 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 foPUL2eK0t8s for ; Mon, 1 Jul 2013 06:44:36 -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 B823911E8125 for ; Mon, 1 Jul 2013 06:44:35 -0700 (PDT) Message-ID: X-CheckPoint: {51D187C0-4A-D2C987A5-2FFFF} From: Henning Schulzrinne To: Eric Rescorla , "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+4AARjaAgAACS4CAAADvAIAAAy0AgAEeuYD//72V5Q== Date: Mon, 1 Jul 2013 13:44:31 +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="Windows-1252" 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: Mon, 01 Jul 2013 13:44:48 -0000 I agree on the less-desirable user option. In the Android eco system, there= are probably three parties that could do this without user involvement: Go= ogle; the smartphone manufacturer (HTC, Samsung, etc.) and the carrier. The= y already routinely modify key components of the OS. One would hope that an= y such feature is user-configurable. Based on recent discussion at a confer= ence in Europe, the prevalence of robocalls appears to be highly country-sp= ecific. Living in a small country with a somewhat-obscure language (Finnish= , Croatian) affords some protection. ________________________________ From: Eric Rescorla [ekr@rtfm.com] Sent: Monday, July 01, 2013 9:38 AM To: DOLLY, MARTIN C Cc: Henning Schulzrinne; Richard Shockey; stir@ietf.org Subject: Re: [stir] Out-of-band vs. in-band It might help to clarify my position here... >From a technical perspective, most of the stuff on a smartphone is an app, including the dialer. >From a user's perspective, the dialer is something built into the phone.. If we build something that requires the user to replace their dialer with something they download, that's not going to be very successful. >From the perspective of what we can build, however. since we know the dialer is just general purpose code running on the phone, and we know that downloadable apps can do DB lookups as calls come in, we know that there's no major technical obstacle to the smartphone vendor building a dialer that does such lookups. This of course does not mean that they will, but means that a design that depends on it is feasible technically. Hope that helps. -Ekr On Sun, Jun 30, 2013 at 1:32 PM, Eric Rescorla > wrote: 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 s= he has a smart phone. This is the user we have to protect=85 do you agree? 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 f= lavors, 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 featu= re to a program. Is that something you disagree with? -Ekr From john.barnhill@genband.com Mon Jul 1 06:48: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 C962511E815A for ; Mon, 1 Jul 2013 06:48:13 -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 jgnkMrijhI1i for ; Mon, 1 Jul 2013 06:48:09 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0185.outbound.messaging.microsoft.com [213.199.154.185]) by ietfa.amsl.com (Postfix) with ESMTP id B342911E8125 for ; Mon, 1 Jul 2013 06:48:08 -0700 (PDT) Received: from mail160-db8-R.bigfish.com (10.174.8.237) by DB8EHSOBE034.bigfish.com (10.174.4.97) with Microsoft SMTP Server id 14.1.225.23; Mon, 1 Jul 2013 13:48:07 +0000 Received: from mail160-db8 (localhost [127.0.0.1]) by mail160-db8-R.bigfish.com (Postfix) with ESMTP id AB4B82E0201; Mon, 1 Jul 2013 13:48:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:63.149.188.7; KIP:(null); UIP:(null); IPV:NLI; H:owa.genband.com; RD:63-149-188-7.dia.static.qwest.net; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zzbb2dI98dI9371I1432I4015Izz1f42h1ee6h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275bh8275dhz2dh2a8h668h839h946he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h14ddh1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received: from mail160-db8 (localhost.localdomain [127.0.0.1]) by mail160-db8 (MessageSwitch) id 137268648580153_12270; Mon, 1 Jul 2013 13:48:05 +0000 (UTC) Received: from DB8EHSMHS006.bigfish.com (unknown [10.174.8.247]) by mail160-db8.bigfish.com (Postfix) with ESMTP id 05F7CD8004B; Mon, 1 Jul 2013 13:48:05 +0000 (UTC) Received: from owa.genband.com (63.149.188.7) by DB8EHSMHS006.bigfish.com (10.174.4.16) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 1 Jul 2013 13:48:03 +0000 Received: from gbex03.genband.com (172.16.26.228) by GBEX01.genband.com (172.16.21.91) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 1 Jul 2013 08:46:44 -0500 Received: from GBPLMAIL01.genband.com ([fe80::70bf:29d1:2cfe:42b5]) by gbex03.genband.com ([fe80::640f:e3d4:2f62:cf12%29]) with mapi id 14.03.0123.003; Mon, 1 Jul 2013 08:46:43 -0500 From: John Barnhill To: Henning Schulzrinne , Eric Rescorla , "DOLLY, MARTIN C" Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObffAOQVpWqFEhUiMZSaiDlSZ+ZlBDysAgARfFACAABohgIAAArsAgAAJJgCAAMiEgIAAYXCAgAA/T4CAAAVDgIAABX+AgAF0k4CAAx4NgIAAB9GAgAAC/gCAABpmgIAAAXSAgAM7pICAAAEugIAABGQAgAAMhICAAAINAIAAAeqAgAACS4CAAADvAIAAAy0AgAEeuYCAAAG8gP//vYqA Date: Mon, 1 Jul 2013 13:46:43 +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: [172.16.21.114] Content-Type: text/plain; charset="Windows-1252" Content-ID: <78B38E52EBEC74449A4EF620B05CDAC0@genband.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: genband.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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: Mon, 01 Jul 2013 13:48:13 -0000 sorry I can't be in Berlin. You could sell tickets to this. Thanks, jb John Barnhill Office of the CTO On 7/1/13 9:44 AM, "Henning Schulzrinne" wrote: >I agree on the less-desirable user option. In the Android eco system, >there are probably three parties that could do this without user >involvement: Google; the smartphone manufacturer (HTC, Samsung, etc.) and >the carrier. They already routinely modify key components of the OS. One >would hope that any such feature is user-configurable. Based on recent >discussion at a conference in Europe, the prevalence of robocalls appears >to be highly country-specific. Living in a small country with a >somewhat-obscure language (Finnish, Croatian) affords some protection. > >________________________________ >From: Eric Rescorla [ekr@rtfm.com] >Sent: Monday, July 01, 2013 9:38 AM >To: DOLLY, MARTIN C >Cc: Henning Schulzrinne; Richard Shockey; stir@ietf.org >Subject: Re: [stir] Out-of-band vs. in-band > >It might help to clarify my position here... > >From a technical perspective, most of the stuff on a smartphone is an app, >including the dialer. > >From a user's perspective, the dialer is something built into the phone.. >If we build something that requires the user to replace their dialer with >something they download, that's not going to be very successful. > >From the perspective of what we can build, however. since we know the >dialer is just general purpose code running on the phone, and we know >that downloadable apps can do DB lookups as calls come in, >we know that there's no major technical obstacle to the smartphone >vendor building a dialer that does such lookups. This of course does >not mean that they will, but means that a design that depends on >it is feasible technically. > >Hope that helps. >-Ekr > > > >On Sun, Jun 30, 2013 at 1:32 PM, Eric Rescorla >> wrote: > > > >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=8Ano app, even though >she has a smart phone. This is the user we have to protect=8A do you agree= ? > >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 >builtin >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 > > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir > From michael.hammer@yaanatech.com Mon Jul 1 07:27: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 229C911E8111 for ; Mon, 1 Jul 2013 07:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.380, 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 PLCAUU-2lfvO for ; Mon, 1 Jul 2013 07:27: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 0CB7911E810E for ; Mon, 1 Jul 2013 07:27:52 -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, 1 Jul 2013 07:27:52 -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//xBlgABQvIAAADC3FgAAJqlXAAAnMeAAADPu4sAArOxSAAE2Hz/A= Date: Mon, 1 Jul 2013 14:27:51 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC0FEEC@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> <265BCEE1-6697-41D5-9B1D-C309BFFDFA84@oracle.com> In-Reply-To: <265BCEE1-6697-41D5-9B1D-C309BFFDFA84@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.52] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_003C_01CE762C.7E049070" 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: Mon, 01 Jul 2013 14:27:58 -0000 ------=_NextPart_000_003C_01CE762C.7E049070 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Although you are disagreeing with me, your statements actually support my points. Note, however, that the value of an E.164 number is not just syntactical, you need all the digits to be semantically unambiguous. While current systems have learned through trial and error, I still think that explicitly specified mechanisms would help to ensure interoperability sooner. Where signatures are concerned, having ambiguous inputs will lead to high probability of validation failure. That was where I felt things were getting off track. Mike -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Saturday, June 29, 2013 11:16 AM To: Michael Hammer Cc: stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) 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. > 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 ------=_NextPart_000_003C_01CE762C.7E049070 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcw MTE0Mjc1MFowIwYJKoZIhvcNAQkEMRYEFIiMfeuNQtPMh+uqXOCFqg4TjW0oMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAIzXFDBJ3Xthyn9LrGFpjZMoO5HL4qyUeK5HWPGLn amAz9N2ZnF3WK4YpWgZH8byEF6DA/ZFWinkpnt0Vv+/l79J8p+t23zgX1e4Ygq3gXg4MGvD9OXdd kf2WcjY1oRVAL9jKXE15z8CwrMBIcQgFZrqS4GX7m7imTHPma5M/Wd/JS1QcwvrnvGA+AEQRFxDO CzgeVFfwvi6optrndYlmv1Pdcr++Sk1Jd69YjXcnbfdx3dvMwIdJge49vIc6kWRQkO8TzHxTbXM9 YwbypwXPfrWUzvzZc/oCYfpwVBklrS29MPFwXfGQ5yTEeBeHr5x2+kdPKUe7hLpgxc25DaA1BwAA AAAAAA== ------=_NextPart_000_003C_01CE762C.7E049070-- From richard@shockey.us Mon Jul 1 09:17: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 D11DC11E8160 for ; Mon, 1 Jul 2013 09:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.913 X-Spam-Level: X-Spam-Status: No, score=-99.913 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_42=0.6, 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 7M8EuxGYnggo for ; Mon, 1 Jul 2013 09:17:54 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id E987811E8181 for ; Mon, 1 Jul 2013 09:17:49 -0700 (PDT) Received: (qmail 18565 invoked by uid 0); 1 Jul 2013 16:17:27 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.bluehost.com with SMTP; 1 Jul 2013 16:17:27 -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=CYUbSRwPSY1mRY9RS91sWOeOoOOKpy5357qJTyFB2Nc=; b=cf1CauRAIEyRjPa4HBSG51dai5gnqi6IbzJWzzVWRk7Tx5VuMFTevIKrDMlw+/x/Fh4K0If1JgzA8LanX13FBHSvREpIbsAc98kgT/rqNwZtR7OY7gvXOE0a7nJ45937; Received: from [72.66.111.124] (port=49636 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Utgn8-0001PO-H6; Mon, 01 Jul 2013 10:17:26 -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> <939661CC-A122-4B04-A18D-8E00C94E4452@att.com> In-Reply-To: Date: Mon, 1 Jul 2013 12:17:24 -0400 Message-ID: <011501ce7676$79b756c0$6d260440$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0116_01CE7654.F2A5B6C0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFSz1HqEPsK2rOmM+sJgaXsYRJDIQI7uFAkAj6JaWgCF6RaiAKs8NY7AY4htgACFA+BuwE/ky+fAYPBB5cCAKnRJAFR8nnJAMFBynkCP03DuQH7I00NAlbZzeMBSmnMUwE/sJHpAU7ESzQCVYlorQIv65iFAlhodnUB6QIYzgFHspaXAmh39QYBemZvawIuyElrmNUzORA= 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] 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, 01 Jul 2013 16:18:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0116_01CE7654.F2A5B6C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit NO this does not help at all. Irrespective of what may or may not be possible on handsets it's irrelevant to the problem. You ignore that nearly 50% or more of the voice minutes are probably landline enterprise and residential. Where no solution is possible unless its network based. This includes nearly all Enterprise Voice ( aka SIP Trunking) and Digital voice over a broadband connection aka FIOS, uVerse and other DSL derivatives in Europe and elsewhere. The data indicates that SIP Trunking will pass T1 enabled circuits/sessions by 2016 in the US and Canada. If a network based solution could be designed and implemented, and I think it's possible, then the handset problem goes away as well in VoLTE/IMS operations and we know that CDMA and HSPA+ system which still use TDM switching will be retired sooner rather than later. . I have zero confidence that some crowd source reputation based system would work and I'm very skeptical on anything that would involve an E2E like system. It would be useful it some people try think like a normal consumer or small business and not the IETF'er. Part of our task it to remove complexity from system not inject it. Just because iMessage is cool doesn't mean it's poised to take over the world. A network solution may not be possible but it's the shortest path to success in the short term. From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Eric Rescorla Sent: Monday, July 01, 2013 9:38 AM To: DOLLY, MARTIN C Cc: stir@ietf.org; Richard Shockey; Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band It might help to clarify my position here... >From a technical perspective, most of the stuff on a smartphone is an app, including the dialer. >From a user's perspective, the dialer is something built into the phone.. If we build something that requires the user to replace their dialer with something they download, that's not going to be very successful. >From the perspective of what we can build, however. since we know the dialer is just general purpose code running on the phone, and we know that downloadable apps can do DB lookups as calls come in, we know that there's no major technical obstacle to the smartphone vendor building a dialer that does such lookups. This of course does not mean that they will, but means that a design that depends on it is feasible technically. Hope that helps. -Ekr On Sun, Jun 30, 2013 at 1:32 PM, Eric Rescorla > wrote: 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.no app, even though she has a smart phone. This is the user we have to protect. do you agree? 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 builtin 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 ------=_NextPart_000_0116_01CE7654.F2A5B6C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

NO this does not help at all.  Irrespective of what may or may = not be possible on handsets it’s irrelevant to the = problem.

 

You ignore that nearly 50% or more of the voice minutes are probably = landline enterprise and residential. Where no solution is possible = unless its network based. This includes nearly all Enterprise Voice ( = aka SIP Trunking)  and Digital voice over a broadband connection = aka FIOS, uVerse and other DSL derivatives in Europe and elsewhere. =  The data indicates that SIP Trunking will pass T1 enabled = circuits/sessions by 2016 in the US and Canada.

 

If a network based solution could be designed and implemented, and I = think it’s possible, then the handset problem goes away as well in = VoLTE/IMS operations and we know that CDMA and HSPA+ system which still = use TDM switching will be retired sooner rather than later.  . I = have zero confidence that some crowd source reputation based system = would work and I’m very skeptical on anything that would involve = an E2E like system.    It would be useful it some people = try think like a normal consumer or small business and not the = IETF’er.    Part of our task it to remove = complexity from system not inject it.

 

Just because iMessage is cool doesn’t mean it’s poised to = take over the world.  

 

A network solution may not be possible but it’s the shortest = path to success in the short term.

 

From: = stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Eric Rescorla
Sent: Monday, July 01, 2013 9:38 = AM
To: DOLLY, MARTIN C
Cc: stir@ietf.org; Richard = Shockey; Henning Schulzrinne
Subject: Re: [stir] Out-of-band = vs. in-band

 

It = might help to clarify my position here...

 

From a technical perspective, most of the stuff on a = smartphone is an app,

including the dialer.

 

From a user's perspective, the dialer is something = built into the phone..

If = we build something that requires the user to replace their dialer = with

something they = download, that's not going to be very = successful.

 

From the perspective of what we can build, however. = since we know the

dialer = is just general purpose code running on the phone, and we = know

that downloadable = apps can do DB lookups as calls come in,

we know that there's no major technical obstacle to = the smartphone

vendor = building a dialer that does such lookups. This of course = does

not mean that they = will, but means that a design that depends = on

it is feasible = technically.

 

Hope that helps.

-Ekr

 

 

On Sun, Jun 30, 2013 at 1:32 PM, Eric Rescorla <ekr@rtfm.com> = wrote:

 

 

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

Eric,

 

My mother picks up her phone 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?

 

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 builtin

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

 

 

------=_NextPart_000_0116_01CE7654.F2A5B6C0-- From ekr@rtfm.com Mon Jul 1 09:23: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 0473D11E8144 for ; Mon, 1 Jul 2013 09:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.492 X-Spam-Level: X-Spam-Status: No, score=-101.492 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 4tRzRnLWh+hw for ; Mon, 1 Jul 2013 09:23:17 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id B2F1811E80E2 for ; Mon, 1 Jul 2013 09:23:16 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id l10so2976555qcy.4 for ; Mon, 01 Jul 2013 09:23:16 -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=+nFOqTltOvfxuJHnYdrsQHmeKZ+D0CD+q4CDRUtJZ6Y=; b=SXD0LX4i10vL/nsOs7D2TAJ9TYgD5DD311C8JdvcN2JvIS0yBy0vXWdHSMgB3FrgOH 8NJ/4SmhUUswPn91vIo1JbjpxHiz+Xwr1uTmnRZiOB5IOtfllgRfV56kpcObxkazYKwn uLl8S/04AGxrBBWC9D9fe1aUTwa+E+ZgrsySnZD/QWzmEAIswe9LcCLpo2YShdzvKmzI 6GCQs4KfSiLwfa3FiJRSXLhdxQ2fEA33NxFIigcU2aAHs5vkTXtW/FK0BSK/IIlPK7HP NJbWmRgub9LJZDBP3Z07hzUcL4hkj4J2tkzgpWBbH/BchaKS8fO6SrkQSg0Sb/ehRnfN oC9Q== X-Received: by 10.49.130.8 with SMTP id oa8mr33145613qeb.87.1372695796156; Mon, 01 Jul 2013 09:23:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.94.137 with HTTP; Mon, 1 Jul 2013 09:22:36 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <011501ce7676$79b756c0$6d260440$@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> <939661CC-A122-4B04-A18D-8E00C94E4452@att.com> <011501ce7676$79b756c0$6d260440$@shockey.us> From: Eric Rescorla Date: Mon, 1 Jul 2013 09:22:36 -0700 Message-ID: To: Richard Shockey Content-Type: multipart/alternative; boundary=047d7b873a0a50991904e075a56d X-Gm-Message-State: ALoCoQnK5x0D0EH2mCjACx309GIduhhlxxC7U+R8hwdAxsGaCZSJbrxNTVLX/CjlEJHzFpqeREm9 Cc: "stir@ietf.org" , "DOLLY, MARTIN C" , 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, 01 Jul 2013 16:23:27 -0000 --047d7b873a0a50991904e075a56d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Jul 1, 2013 at 9:17 AM, Richard Shockey wrote: > NO this does not help at all. > Well, it seems to have helped clarify things. > > Irrespective of what may or may not be possible on handsets it=92s > irrelevant to the problem.**** > > ** ** > > You ignore that nearly 50% or more of the voice minutes are probably > landline enterprise and residential. Where no solution is possible unless > its network based. This includes nearly all Enterprise Voice ( aka SIP > Trunking) and Digital voice over a broadband connection aka FIOS, uVerse > and other DSL derivatives in Europe and elsewhere. The data indicates th= at > SIP Trunking will pass T1 enabled circuits/sessions by 2016 in the US and > Canada. **** > > ** ** > > If a network based solution could be designed and implemented, and I thin= k > it=92s possible, then the handset problem goes away as well in VoLTE/IMS > operations and we know that CDMA and HSPA+ system which still use TDM > switching will be retired sooner rather than later. . I have zero > confidence that some crowd source reputation based system would work and > I=92m very skeptical on anything that would involve an E2E like system. = It > would be useful it some people try think like a normal consumer or small > business and not the IETF=92er. Part of our task it to remove complexi= ty > from system not inject it.**** > > ** ** > > Just because iMessage is cool doesn=92t mean it=92s poised to take over t= he > world. **** > > ** ** > > A network solution may not be possible but it=92s the shortest path to > success in the short term. **** > > ** ** > > > Yes, I recognize that this is your position. I disagree with this analysi= s for the reasons both Jon and I have laid out. If all I got was the 50% or so of calls that were on smartphones that would be a huge success. -Ekr --047d7b873a0a50991904e075a56d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Mon, Jul 1, 2013 at 9:17 AM, Richard Shockey &= lt;richard@shockey.= us> wrote:

NO this does = not help at all.


Well, it seems to have helped = clarify things.

=A0

=A0

Irrespective of wha= t may or may not be possible on handsets it=92s irrelevant to the problem.<= u>

=A0<= /p>

You ignore that nearly= 50% or more of the voice minutes are probably landline enterprise and resi= dential. Where no solution is possible unless its network based. This inclu= des nearly all Enterprise Voice ( aka SIP Trunking)=A0 and Digital voice ov= er a broadband connection aka FIOS, uVerse and other DSL derivatives in Eur= ope and elsewhere. =A0The data indicates that SIP Trunking will pass T1 ena= bled circuits/sessions by 2016 in the US and Canada. <= /p>

=A0<= /p>

If a network based sol= ution could be designed and implemented, and I think it=92s possible, then = the handset problem goes away as well in VoLTE/IMS operations and we know t= hat CDMA and HSPA+ system which still use TDM switching will be retired soo= ner rather than later.=A0 . I have zero confidence that some crowd source r= eputation based system would work and I=92m very skeptical on anything that= would involve an E2E like system. =A0=A0=A0It would be useful it some peop= le try think like a normal consumer or small business and not the IETF=92er= .=A0=A0=A0 Part of our task it to remove complexity from system not inject = it.

=A0<= /p>

Just because iMessage = is cool doesn=92t mean it=92s poised to take over the world. =A0<= /u>

=A0<= /p>

A network solution may= not be possible but it=92s the shortest path to success in the short term.=

=A0<= /p>


Yes, I reco= gnize that this is your position. I disagree with this analysis for the rea= sons
both Jon and I have laid out. If all I got was the 50% or so of calls = that were on smartphones
that would be a huge success.
=
-Ekr
=A0
--047d7b873a0a50991904e075a56d-- From hadriel.kaplan@oracle.com Mon Jul 1 09:58: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 F057E11E823E for ; Mon, 1 Jul 2013 09:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.453 X-Spam-Level: X-Spam-Status: No, score=-6.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2ttsCcSLgm1 for ; Mon, 1 Jul 2013 09:58:03 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id DA55011E823B for ; Mon, 1 Jul 2013 09:57:58 -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 r61GpZrn028234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Jul 2013 16:51:36 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 r61Gvsum000488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Jul 2013 16:57:55 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r61GvsvA000466; Mon, 1 Jul 2013 16:57:54 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Jul 2013 09:57: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: Mon, 1 Jul 2013 12:57:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <29BFD187-B99B-4432-8F93-1A0968207C9E@oracle.com> References: , <388DA498-47F5-4F4E-BA9F-B57773447C77@oracle.com> To: Henning Schulzrinne 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 , "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: Mon, 01 Jul 2013 16:58:09 -0000 Sure, but such caching schemes only work for the same protocol with the = same query string: either the same HTTP URL or the same DNS query key. = An HTTP URL isn't simply used to indicate the protocol being used or = what server to issue the HTTP request to - it indicates a full path, = with various embedded information in the URL that only has meaning to = the HTTP server. So ignoring the rfc4474 identity-info URL and changing = to a different protocol such as DNS is going to be tricky. As a very simple example of how this would be a problem: when a = certificate expires, the originator will need to use a new cert for = calls at some point. So they'd get a new cert and put it in their HTTP = server - but they can't remove their old one because of the cached = copies of it elsewhere, not to mention there would be SIP requests = in-flight during the cut-over. So they'd need some way to indicate, per = SIP request they sign, which cert they're using for each particular = request. With HTTP, they could do this: http://foo.com/sipcerts/newcert.cer Or maybe something like this: http://foo.com/sipcerts/callerid.cer?inst=3Dsd87gfbi The verifier can't simply ignore those URLs and switch to using DNS = queries locally. -hadriel On Jun 30, 2013, at 12:16 PM, Henning Schulzrinne = wrote: > We do some version of this in every web browser and DNS resolver: If = the data is locally cached, no protocol request is made, along with = other local caching mechanism where the HTTP or DNS request never = reaches the origin server named, including both transparent and explicit = (redirect) caching. >=20 > 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 interoperability (and probably doesn't even need a detailed = specification). As with all caching mechanisms, there is a trade-off = between extra querying and possibly stale data. >=20 > Henning >=20 > ________________________________________ > From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of = Hadriel Kaplan [hadriel.kaplan@oracle.com] > Sent: Saturday, June 29, 2013 4:18 AM > To: Peterson, Jon > Cc: fluffy@cisco.com; stir@ietf.org; Michael Hammer > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for = STIR) >=20 > On Jun 28, 2013, at 5:45 PM, "Peterson, Jon" = wrote: >=20 >>> 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. >=20 >=20 > 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. >=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 From richard@shockey.us Mon Jul 1 10:00: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 A476D21F9E39 for ; Mon, 1 Jul 2013 10:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.315 X-Spam-Level: X-Spam-Status: No, score=-100.315 tagged_above=-999 required=5 tests=[AWL=0.709, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 omQkRYWsqWFG for ; Mon, 1 Jul 2013 10:00:46 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 506C321F9E36 for ; Mon, 1 Jul 2013 10:00:46 -0700 (PDT) Received: (qmail 19348 invoked by uid 0); 1 Jul 2013 17:00:23 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.bluehost.com with SMTP; 1 Jul 2013 17:00:22 -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=EaEfgNstVerL8b6warPVj6Aw/+L1iqX9JIPLrOSj8Ec=; b=V1tzgH6+MYAbVK6s6lnS93059suhFVdqWC9mqPswQoadBveUtAk5pXCfKg7wkLNfrUMIR9NPx5Dy5UjKnfmGPtc2oQ24fvdsMPpKa6AGlx6P7AhtRujMXUw+uVxQFSfs; Received: from [72.66.111.124] (port=49816 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UthSe-0007qe-R1 for stir@ietf.org; Mon, 01 Jul 2013 11:00:21 -0600 From: "Richard Shockey" 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> <011501ce7676$79b756c0$6d260440$@shockey.us> In-Reply-To: Date: Mon, 1 Jul 2013 13:00:18 -0400 Message-ID: <013501ce767c$781e3170$685a9450$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0136_01CE765A.F10F0270" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFSz1HqEPsK2rOmM+sJgaXsYRJDIQI7uFAkAj6JaWgCF6RaiAKs8NY7AY4htgACFA+BuwE/ky+fAYPBB5cCAKnRJAFR8nnJAMFBynkCP03DuQH7I00NAlbZzeMBSmnMUwE/sJHpAU7ESzQCVYlorQJYaHZ1AekCGM4BR7KWlwJod/UGAXpmb2sCLshJawJPaVevAd9y16uYxUTC0A== 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] 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, 01 Jul 2013 17:00:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0136_01CE765A.F10F0270 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Mon, Jul 1, 2013 at 9:17 AM, Richard Shockey > wrote: NO this does not help at all. Well, it seems to have helped clarify things. Just because iMessage is cool doesn't mean it's poised to take over the world. A network solution may not be possible but it's the shortest path to success in the short term. Yes, I recognize that this is your position. I disagree with this analysis for the reasons both Jon and I have laid out. If all I got was the 50% or so of calls that were on smartphones that would be a huge success. [RS> ] Well you still ignore that any carrier using CDMA right now cannot deploy your proposed solution since it cannot do data and Voice at the same time. Verizon Sprint and Korea Telecom might have something to say about that. -Ekr ------=_NextPart_000_0136_01CE765A.F10F0270 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

 

On Mon, Jul 1, 2013 at 9:17 AM, Richard Shockey <richard@shockey.us> = wrote:

NO this does not help at all. =

 

Well, it seems to have helped clarify = things.

 

 

Just because iMessage is cool doesn’t mean it’s poised to = take over the world.  

 A network solution may not be possible but it’s the = shortest path to success in the short term.

 

Yes, I recognize that this is your position. I = disagree with this analysis for the reasons

both Jon and I have laid out. If all I got was the 50% = or so of calls that were on smartphones

that would be a huge success.

 

 

[RS> ]  Well you still ignore that any carrier using CDMA = right now cannot deploy your proposed solution since it cannot do data = and Voice at the same time. Verizon Sprint and Korea Telecom might have = something to say about that.

 

 

 

-Ekr

 

------=_NextPart_000_0136_01CE765A.F10F0270-- From ekr@rtfm.com Mon Jul 1 10:06: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 561A921F9B17 for ; Mon, 1 Jul 2013 10:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.509 X-Spam-Level: X-Spam-Status: No, score=-101.509 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 CgV39BLoNWxk for ; Mon, 1 Jul 2013 10:06:21 -0700 (PDT) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id 61B5A11E81A8 for ; Mon, 1 Jul 2013 10:06:21 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id n20so2221429qaj.13 for ; Mon, 01 Jul 2013 10:06: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=PsOGXU6l+52qdH3nAqxnj7ReHg43iaJ8/NJJe9gznTk=; b=dfPy+9GBzPP3WgufudkS0adsg3v6RUt92yuDRj8OGNRXDisBBq/Ny0pRPoK2SiBjUZ PCKU66/Hlg9XMpqpS76PPC9zHLrPJbnLLBDdGcEWR+vugzFBcNjtAv1CLfgBE2d70s0b 3WJ9Cue4KnUf8FY37sHgJsYf7iPdTddcwHNvMBN0L5PbFy4L+cw/L/FrnuiFqYo8CMLl /25mGKY9Ss/IHtdjkgJiPo/+Ht9z9sWGoiW/1RpbpGFPX9ykfSFPSi35fhbamrnU0EVo 8FsYc+K79uZusAYJnk/e+vpHOTlyuyiBN7VnCFr3dMsvHdLHklJLnayLIaGzq4+nEHmI E4qw== X-Received: by 10.224.36.199 with SMTP id u7mr32015629qad.113.1372698380864; Mon, 01 Jul 2013 10:06:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.94.137 with HTTP; Mon, 1 Jul 2013 10:05:40 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <013501ce767c$781e3170$685a9450$@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> <939661CC-A122-4B04-A18D-8E00C94E4452@att.com> <011501ce7676$79b756c0$6d260440$@shockey.us> <013501ce767c$781e3170$685a9450$@shockey.us> From: Eric Rescorla Date: Mon, 1 Jul 2013 10:05:40 -0700 Message-ID: To: Richard Shockey Content-Type: multipart/alternative; boundary=001a11c1bb7c601e3e04e0763ffc X-Gm-Message-State: ALoCoQlJ6404fRIqMhZ/+BsZTyesD5XXF0VaZpiu8bm+S0XQogeTwaji6LQQoX4mmEfgoJ5z5dXJ 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, 01 Jul 2013 17:06:27 -0000 --001a11c1bb7c601e3e04e0763ffc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Jul 1, 2013 at 10:00 AM, Richard Shockey wrote= : > ** ** > > ** ** > > ** ** > > On Mon, Jul 1, 2013 at 9:17 AM, Richard Shockey > wrote:**** > > NO this does not help at all. **** > > ** ** > > Well, it seems to have helped clarify things.**** > > ** ** > > **** > > Just because iMessage is cool doesn=92t mean it=92s poised to take over t= he > world. **** > > A network solution may not be possible but it=92s the shortest path to > success in the short term. **** > > **** > > Yes, I recognize that this is your position. I disagree with this analysi= s > for the reasons**** > > both Jon and I have laid out. If all I got was the 50% or so of calls tha= t > were on smartphones**** > > that would be a huge success.**** > > * * > > ** ** > > *[RS> ] Well you still ignore that any carrier using CDMA right now > cannot deploy your proposed solution since it cannot do data and Voice at > the same time. Verizon Sprint and Korea Telecom might have something to s= ay > about that.* > Well, I feel generally sad for people who have that kind of phone. That said, I would want to double check you were correct about the inference here, since this is at the point where the phone has an incoming call but before it's been answered. Is data possible in that period? -Ekr --001a11c1bb7c601e3e04e0763ffc Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Mon, Jul 1, 2013 at 10:00 AM, Richard Shockey = <richard@shockey= .us> wrote:

=A0=

=A0

=A0

On Mon, Jul 1, 2013 at 9:17 AM, Richard Shockey &l= t;richard@shockey.u= s> wrote:

N= O this does not help at all.

=A0

<= /div>

Well, it seems to have helped clarify thin= gs.

=A0

=A0

<= /div>

Just because iMessage is cool doesn=92t mean it=92s poise= d to take over the world. =A0

=A0A ne= twork solution may not be possible but it=92s the shortest path to success = in the short term.

=A0<= /p>

Yes, I recognize that this is your position. I disagree with this analysis = for the reasons

both Jon and I have laid out. If all I go= t was the 50% or so of calls that were on smartphones

that would be a huge = success.

=A0

= =A0

[RS> ]=A0 = Well you still ignore that any carrier using CDMA right now cannot deploy y= our proposed solution since it cannot do data and Voice at the same time. V= erizon Sprint and Korea Telecom might have something to say about that.


=
Well, I feel generally sad for people who have that ki= nd of phone.

That said, I would want t= o double check you were correct about the
inference here, since this is at the point where the phone has a= n
incoming call but before it's been answered. Is data = possible in
that period?

-Ekr

--001a11c1bb7c601e3e04e0763ffc-- From dhc@dcrocker.net Mon Jul 1 10:10: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 7942E11E8213 for ; Mon, 1 Jul 2013 10:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoUueAvAfN7l for ; Mon, 1 Jul 2013 10:10:19 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9634411E8208 for ; Mon, 1 Jul 2013 10:10:19 -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 r61HAF3d008443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Jul 2013 10:10:18 -0700 Message-ID: <51D1B7EC.1080801@dcrocker.net> Date: Mon, 01 Jul 2013 10:10:04 -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: Richard Shockey References: <51C4CE80.40701@dcrocker.net> <006401ce7424$1e7371d0$5b5a5570$@shockey.us> <939661CC-A122-4B04-A18D-8E00C94E4452@att.com> <011501ce7676$79b756c0$6d260440$@shockey.us> <013501ce767c$781e3170$685a9450$@shockey.us> In-Reply-To: <013501ce767c$781e3170$685a9450$@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, 01 Jul 2013 10:10:18 -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, 01 Jul 2013 17:10:24 -0000 On 7/1/2013 10:00 AM, Richard Shockey wrote: > Yes, I recognize that this is your position. I disagree with this > analysis for the reasons > > both Jon and I have laid out. If all I got was the 50% or so of calls > that were on smartphones that would be a huge success. That style of thinking is exactly what's getting in the way of productive discussion here. Taking highly specialized scenarios and then projecting best-case adoption and performance is an absolutely classic path towards failure when deploying new Internet infrastructure services. In this case, focusing on a design that can /at best/ cover only half of the affected population -- but is unlikely to come close to that, because life rarely reaches the ideal, and certainly not anytime soon -- is starting with a design failure. It's not that such scenarios cannot be made to work and it's not that they won't ever work. It's that it doesn't cover the population that is tasked for coverage and it doesn't /ever/ develop as planned. This group needs to define a few, basic scenarios that /must/ be covered and then needs to identify the critical adoption and use actions that will make it work. Whatever is designed then needs to to be easy to understand, have reasonable adoption and use incentives, and therefore seem likely to work. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hadriel.kaplan@oracle.com Mon Jul 1 10: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 0949911E8177 for ; Mon, 1 Jul 2013 10:27:50 -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 EB4m9+YbfKrn for ; Mon, 1 Jul 2013 10:27:44 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5107011E80E8 for ; Mon, 1 Jul 2013 10:27:42 -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 r61HLKoK028491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Jul 2013 17:21:21 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 r61HRd8r008883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Jul 2013 17:27:39 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 r61HRdKe018761; Mon, 1 Jul 2013 17:27:39 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Jul 2013 10:27:38 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Mon, 1 Jul 2013 13:27:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <58C87247-016B-4615-830F-8514239A91DF@oracle.com> 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> To: Eric Rescorla , 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] 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, 01 Jul 2013 17:27:50 -0000 I think people on this subject thread are talking past each other. Or = at least that's my impression from reading the emails this morning. I don't think anyone's saying it's theoretically nor technically = impossible to specify and implement an out-of-band solution that could = allow some portion of callers to prove their caller-id to some portion = of called-parties. Of course you could. So what? What does the technical possibility to achieve something have = to do with forming a successful IETF Working Group? It's certainly a necessary condition that something be possible, but = it's not a *sufficient* excuse for forming a WG, imo. Specifying = something in isolation, without getting the implementors and = users/operators of the specification involved, is a sure way to generate = more useless RFCs. It may be a fine thing for IRTF, but not IETF. At a minimum, I would expect to at least have multiple parties who = actually plan to implement and deploy such a solution, to be present in = the WG. I know there are cloud-based companies working on = source-identity stuff, but I don't see any of them are here. I don't = know what their requirements are. I don't even know that they *want* a = standard's based solution. After all, they can each write apps for = smart-phones already today, without our help. Instead, what I hear is the people who actually need to implement and = deploy a STIR solution saying they want an in-band solution. Why are we wasting their time? -hadriel On Jun 30, 2013, at 4:35 PM, Eric Rescorla wrote: > 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. >=20 > -Ekr From jon.peterson@neustar.biz Mon Jul 1 10: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 5D4B121F9A1B for ; Mon, 1 Jul 2013 10:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.154 X-Spam-Level: X-Spam-Status: No, score=-105.154 tagged_above=-999 required=5 tests=[AWL=-0.861, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 j29r1oA70eZG for ; Mon, 1 Jul 2013 10:53:40 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 94F6D11E81B0 for ; Mon, 1 Jul 2013 10:53:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1372701697; x=1688049085; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=l+c3yQYfaw nLuf/bP+7eBN9LZ+GR0fAhnWI2o2AyX9Q=; b=cMq28hS25E+ruxDKnmwS7+ssY/ Xm7EM8bXvD8y1a9Lkg+ZffB1aIEpabixOevlei6ke0naSu9aF3CFi2W3KNkA== Received: from ([10.31.58.69]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.27163655; Mon, 01 Jul 2013 14:01:36 -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, 1 Jul 2013 13:53:10 -0400 From: "Peterson, Jon" To: "dcrocker@bbiw.net" Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qTxOKj0KNUekSSEg+vw9zPGJlLiToAgAArZACAAAM/gP//liOAgAC3SgCAA+lFgA== Date: Mon, 1 Jul 2013 17:53:10 +0000 Message-ID: In-Reply-To: <51CE17A6.2090605@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.121] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: NZPT0e9jRE5Sh5eK5YpnEw== Content-Type: text/plain; charset="euc-kr" Content-ID: <21C2953D2EE7BB4595E935C228E36E51@neustar.biz> Content-Transfer-Encoding: base64 MIME-Version: 1.0 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 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 17:53:44 -0000 DQo+PkkgZG9uJ3QgdGhpbmsgSSd2ZSBoZWFyZCBhbnlvbmUgaGVyZSAoeWV0LA0KPj4gYW55d2F5 KSBwcm9wb3NpbmcgYW4gYWx0ZXJuYXRpdmUgYXJjaGl0ZWN0dXJlLCBqdXN0IGEgY2hhbmdlIHRv IHRoZQ0KPj4gZGlnZXN0LXN0cmluZyBhbmQgYW4gYWRkaXRpb24gdG8gdGhlIHR5cGVzIG9mIHNp Z25pbmcgYXV0aG9yaXR5Lg0KPg0KPkNob29zaW5nIGJldHdlZW4gcHVibGlzaGluZyBjcmVkZW50 aWFscyB2ZXJzdXMgcHVibGlzaGluZyBwdWJsaWMga2V5cyBpcw0KPmF0IGxlYXN0IG9uZSBleGFt cGxlIG9mIGNvbXBldGluZyBjaG9pY2VzIHRoYXQgYXJlIHF1aXRlIGJhc2ljIGluIHRoZQ0KPmRl c2lnbiBtb2RlbCBmb3IgdGhpcyBhdXRob3JpemF0aW9uIHZhbGlkYXRpb24gc2VydmljZS4NCj4N Cj5TbywgZm9yIGV4YW1wbGUsIHVzaW5nIGEgREtJTS1kZXJpdmVkIHNjaGVtZSBpcyBxdWl0ZSBh IGRpZmZlcmVudA0KPmFyY2hpdGVjdHVyZSBmcm9tIHRoZSBvbmUgeW91J3ZlIHByb3Bvc2VkLg0K DQpBY3R1YWxseSwgUkZDNDQ3NCBpcyB0b3RhbGx5IGFnbm9zdGljIHRvIGhvdyBjcmVkZW50aWFs cyBhcmUgYWNxdWlyZWQsIGFzDQpJJ3ZlIHNhaWQgc2V2ZXJhbCB0aW1lcyBpbiB0aGlzIHRocmVh ZC4gVGhlIFVSSSBpbiBJZGVudGl0eS1JbmZvIGlzIGFsd2F5cw0KanVzdCBhIGhpbnQsIFJGQzQ0 NzQgc2F5cyB5b3UgY2FuIGlnbm9yZSBpdCBpZiB5b3UgYWxyZWFkeSBoYXZlIGENCmNyZWRlbnRp YWwgb3IgaGF2ZSBhbiBhbHRlcm5hdGUgbWVhbnMgb2YgYWNxdWlyaW5nIGNyZWRlbnRpYWxzLiBJ J3ZlIGFsc28NCnBvaW50ZWQgb3V0IHRoYXQgSWRlbnRpdHktSW5mbyBjYW4gYWxyZWFkeSBwb2lu dCB0byB0aGUgRE5TLiBTbyBpdCdzIG5vdA0KY2xlYXIgdG8gbWUgaW4gd2hhdCBzZW5zZSBES0lN J3Mga2V5IGRlbGl2ZXJ5IGZhbGxzIG91dHNpZGUgdGhpcyBtb2RlbC4NCg0KPj4gVGhlIGNoYW5n ZXMgd2UgbmVlZCB0byBtYWtlIGluIFNUSVIgdG8gdGhlIGRpZ2VzdC1zdHJpbmcgYXJlLCB3aXRo IG9uZQ0KPj4gZXhjZXB0aW9uLCBjaGFuZ2VzIHdlIHdvdWxkIG1ha2UgcmVnYXJkbGVzcyBvZiB3 aGV0aGVyIG9yIG5vdCB0aGUgRnJvbQ0KPj4gaGVhZGVyIGZpZWxkIHZhbHVlIGNvbnRhaW5lZCBh IHRlbGVwaG9uZSBudW1iZXIuIFRoZXkgYXJlIGNoYW5nZXMgdGhhdA0KPj4gd2lsbCBtYWtlIHRo aXMgd29yayB3aXRoIGV4aXN0aW5nIGRlcGxveW1lbnRzLiBUaGUgb25lIGV4Y2VwdGlvbiBpcyB0 aGUNCj4+IGNhbm9uaWNhbGl6YXRpb24gYWxnb3JpdGhtIGZvciB0ZWxlcGhvbmUgbnVtYmVycyB3 ZSd2ZSBkaXNjdXNzZWQgb24gdGhlDQo+PiBsaXN0OiB0aGF0IHdvcmsgaXMgc3BlY2lmaWMgdG8g dGVsZXBob25lIG51bWJlcnMuDQo+DQo+VGhlIGV4cGVyaWVuY2Ugd2l0aCBjYW5vbmljYWxpemF0 aW9uIGFsZ29yaXRobXMgZm9yIERLSU0gLS0gYW5kIGl0LCB0b28sDQo+aGFkIHRvIGRlYWwgd2l0 aCBpbi10cmFuc2l0IG1vZGlmaWNhdGlvbnMgLS0gbWFrZXMgY2xlYXIgdGhhdCBpdCdzIGENCj50 b3BpYyB3aXRoIGNoYWxsZW5nZXMgYW5kIGNvbXByb21pc2VzLiAgKEhtbW0uICAiY29tcHJvbWlz ZXMiIG1pZ2h0IGJlIGENCj5wdW4sIGhlcmUuKQ0KDQpUaGUgdmFyaWV0eSBvZiBjYW5vbmljYWxp emF0aW9uIHVuZGVyIGRpc2N1c3Npb24gaGVyZSAob3ZlciBpbiB0aGF0ICJVUkkNCkZvcm1hdCIg dGhyZWFkKSwgd2hlcmUgdGhlIG9yaWdpbmF0b3IgYW5kIHRlcm1pbmF0b3IgbXVzdCBzeW50aGVz aXplDQppZGVudGljYWwgY29waWVzIG9mIGEgc3RyaW5nIHRoYXQgZG9lcyBub3QgYXBwZWFyIGlu IHRoZSBtZXNzYWdlIGl0c2VsZiwNCmhhcyBubyBjb3JvbGxhcnkgaW4gYW55IGVtYWlsIHByYWN0 aWNlIEknbSBhd2FyZSBvZi4NCg0KPj4gSWYgd2UncmUgZml4aW5nIHRoZSByZXN0DQo+PiBvZiB0 aGUgZGlnZXN0LXN0cmluZyBmb3IgdGhlIFROIGNhc2UsIHRob3VnaCwgd2Ugc2hvdWxkIGFsc28g Zml4IGl0IGZvcg0KPj4gdGhlIGdyZWVuZmllbGQgY2FzZS4gVGhlIGdyZWVuZmllbGQgY2FzZSBk b2Vzbqn2dCBpbnRyb2R1Y2UgYW55IG5ldw0KPj4gcmVxdWlyZW1lbnRzIGZvciB0aGlzLCBzYXku IEl0IHdvdWxkIG5vdCBzYXZlIHVzIGFueSB3b3JrIHRvIHRyZWF0IHRoaXMNCj4+YXMNCj4+IGEg c2VwYXJhdGUgZWZmb3J0IGZyb20gb2Jzb2xldGluZyB0aGUgZGlnZXN0LXN0cmluZyBvZiBSRkM0 NDc0Lg0KPg0KPkknbSBub3QgdW5kZXJzdGFuZGluZyBob3cgY29uY2VybiBmb3IgUkZDNDQ3NCBh ZmZlY3RzIHRoZSB0ZWNobmljYWwgd29yaw0KPm9uIHRoaXMuDQoNClRoaXMgaXMgYmFzaWNhbGx5 IGFuIGFkbWluaXN0cmF0aXZlIHF1ZXN0aW9uIGFib3V0IGhvdyB3ZSBzdGVlciBhbmQNCm9yZ2Fu aXplIHRoZSB3b3JrLg0KDQo+PiBUaGUgYWRkaXRpb24gb2YgYSBuZXcgY2F0ZWdvcnkgb2Ygc2ln bmluZyBhdXRob3JpdHkgZm9yIHRlbGVwaG9uZQ0KPj5udW1iZXJzDQo+PiBpc24ndCBldmVuIGEg d2lyZSBwcm90b2NvbCBjaGFuZ2UsIGFzIEkndmUgcHJldmlvdXNseSBwb2ludGVkIG91dC4NCj4N Cj4ibmV3IGNhdGVnb3J5IG9mIHNpZ25pbmcgYXV0aG9yaXR5Ij8gIFNvcnJ5IGZvciBteSBjb25m dXNpb24sIGJ1dCBJDQo+ZG9uJ3Qga25vdyB3aGF0IHRoYXQgbWVhbnMuDQoNClNpZ25lcnMgdGhh dCBoYXZlIGF1dGhvcml0eSBmb3IgdGVsZXBob25lIG51bWJlcnMuDQoNCj4+IElkZW50aXR5LUlu Zm8gaXMgYWxyZWFkeSBxdWl0ZSBmbGV4aWJsZSBpbiB0ZXJtcyBvZiB3aGF0IFVSSSB0eXBlcyBp dA0KPj4gc3VwcG9ydHMgKGluY2x1ZGluZyBwb3RlbnRpYWxseSBkbnMgVVJJcykuIFRoZSBuZXcg d29yayB0aGF0IG5lZWRzIHRvIGJlDQo+DQo+SSBtaXNzZWQgd2hlcmUgdGhlIEROUyBVUkkgKGRu czp4eHh4eCkgY29uc3RydWN0IG9mIFJGQyA0NTAxIGNhbWUgaW50bw0KPnRoZSBkaXNjdXNzaW9u IG9yIGhvdyBpdCdzIHJlbGV2YW50Lg0KDQpBcyBhIFVSSSBpbiBJZGVudGl0eS1JbmZvIChhZ2Fp biwgdGhpcyBoYXMgYmVlbiBkaXNjdXNzZWQgc2V2ZXJhbCB0aW1lcw0Kbm93KS4NCg0KPj4gZG9u ZSBoZXJlIGlzIG9uIGhvdyB3ZSBjb21wYXJlIHRoZSAoY2Fub25pY2FsaXplZCkgRnJvbSB0ZWxl cGhvbmUgbnVtYmVyDQo+PiB3aXRoIHRoZSBhdXRob3JpdHkgb2YgdGhlIHNpZ25lci4NCj4NCj4i Y29tcGFyZSB0aGUuLi5udW1iZXIgd2l0aCB0aGUgYXV0aG9yaXR5IG9mIHRoZSBzaWduZXIiPyAg QXBvbG9naWVzDQo+YWdhaW4gYnV0IEknbSBub3QgdW5kZXJzdGFuZGluZyB3aGF0IHRoYXQgbWVh bnMuICBIb3cgaXMgImNvbXBhcmlzb24NCj53aXRoIFthbl0gYXV0aG9yaXR5IiBsaWtlbHkgdG8g cGxheSBpbnRvIHZhbGlkYXRpb24/DQoNClRvIGFzY2VydGFpbiB0aGUgcmVmZXJlbmNlIGludGVn cml0eSBvZiB0aGUgaWRlbnRpdHkgd2l0aCB0aGUgYXV0aG9yaXR5IG9mDQp0aGUgc2lnbmF0dXJl Lg0KDQo+PiBCdXQgZXZlbiB0aGUgbG9naWMgdGhhdCBpbnNwZWN0cyB0aGUNCj4+PkZyb20gZmll bGQgdG8gZGV0ZXJtaW5lIGlmIGl0IGNvbnRhaW5zIGEgdGVsZXBob25lIG51bWJlciBuZWVkcyB0 byBiZQ0KPj4gY29nbml6YW50IG9mIHRoZSBleGlzdGVuY2Ugb2YgZ3JlZW5maWVsZCBpZGVudGlm aWVycywgYW5kIHRyeWluZyB0byBjYXN0DQo+PiB0aGlzIHN1Y2ggdGhhdCBpdCBvcGVyYXRlcyBp biBjb21wbGV0ZSBpc29sYXRpb24gZnJvbSB0aGUgd29ybGQgb2YNCj4+IGdyZWVuZmllbGQgU0lQ IFVSSXMgd2lsbCBub3QgYmUgY29uZHVjaXZlIHRvIGEgcm9idXN0IHNvbHV0aW9uLg0KPg0KPlNw ZWNpZnkgd2hhdCBpdCBpcyB0byBsb29rIGZvciBhbmQgdGhhdCBpdCBpcyB0byBpZ25vcmUgZXZl cnl0aGluZyBlbHNlLA0KPmFuZCB0aGluZ3MgZ2V0IHByZXR0eSBzaW1wbGUuICBJdCdzIGxpa2Ug aWdub3JpbmcgaGVhZGVyIGZpZWxkcyB0aGF0IHRoZQ0KPnByb2Nlc3NvciBkb2Vzbid0IGtub3cu ICBBbmQgaXQgaGFzIHRoZSBhZHZhbnRhZ2UgdGhhdCBpdCdzIGJvdGggcm9idXN0DQo+YW5kIHNp bXBsZS4NCg0KQmVpbmcgYWJsZSB0byBkaWZmZXJlbnRpYXRlIGEgdXNlciBwYXJ0IHRoYXQgaXMg YSBwaG9uZSBudW1iZXIgZnJvbSBhIHVzZXINCnBhcnQgdGhhdCBpcyBub3QgaXMgbm90IGVudGly ZWx5IHRyaXZpYWwsIGFzIGhhcyBiZWVuIHByZXZpb3VzbHkgZGlzY3Vzc2VkDQppbiB0aGlzIHRo cmVhZC4gQSB2ZXJpZmllciB0aGF0IHJlY2VpdmVzIGEgcmVxdWVzdCBuZWVkcyB0byBmaWd1cmUg b3V0IGlmDQp0aGUgdXNlciBwYXJ0IGlzIGEgdGVsZXBob25lIG51bWJlciBvciBub3QuIElkZWFs bHksIHRoZSB2ZXJpZmllciB3b3VsZA0KdW5kZXJzdGFuZCB0aGUgaGFuZGxpbmcgb2YgdGhlIGNh c2Ugd2hlcmUgaXQgaXMgbm90Lg0KDQo+QnkgdGhlIHdheSwgeW91IHNlZW0gdG8gYmUgdXNpbmcg J2dyZWVuZmllbGQiIGFzIGEgd2VsbC1yZWNvZ25pemVkDQo+cXVhbGlmaWVyLCBidXQgSSBjYW4n dCBmaW5kIGV4cGxhbmF0b3J5IHJlZmVyZW5jZSB0byBpdC4gIFBsZWFzZSBleHBsYWluLg0KDQpJ IG1lYW4gU0lQIFVSSXMgd2l0aCBhIHVzZXJAZG9tYWluIGZvcm1hdCwgd2hlcmUgdGhlIHVzZXIg cGFydCBpcyBub3QgYQ0KdGVsZXBob25lIG51bWJlci4NCg0KPj4gSSBoYXZlIGENCj4+IGhhcmQg dGltZSBzZWVpbmcgYW4gYXJndW1lbnQgdGhhdCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gZGVwbG95 DQo+PiB2ZXJpZmljYXRpb24gc2VydmljZXMgdGhhdCBjYW4gb25seSB1bmRlcnN0YW5kIHRlbGVw aG9uZSBudW1iZXJzLCBnaXZlbg0KPj4gdGhlIGVub3Jtb3VzIG92ZXJsYXAgaW4gZnVuY3Rpb25h bGl0eSB3aXRoIHVuZGVyc3RhbmRpbmcgbmF0aXZlIFNJUA0KPj5VUklzLA0KPj4gYW5kIHRoZSBm YWN0IHRoYXQgdGhlIHN0YW5kYXJkaXphdGlvbiB3b3JrIG9uIHRoYXQgaXMgYWxyZWFkeSBkb25l Lg0KPg0KPklmIHlvdSBzYWlkICJsYXJnZSBzY2FsZSBkZXBsb3ltZW50IGFuZCB1c2Ugd29yayB0 aGF0IGlzIGFscmVhZHkgZG9uZSIsDQo+dGhhdCBtaWdodCBiZSBtb3JlIHRlbGxpbmcuLi4NCj4N Cj5BcyBmb3IgdGhlIHJlZmVyZW5jZWQgb3ZlcmxhcCwgdGhhdCBib2RlcyB3ZWxsIGZvciBtYWtp bmcgdGhlIGxhdGVyLA0KPmluY3JlbWVudGFsIHdvcmsgdHJhY3RhYmxlLg0KDQpBZ2FpbiwgdGhp cyBpcyBhIHF1ZXN0aW9uIG9mIHdoZXRoZXIgZ3JlZW5maWVsZCBpZGVudGlmaWVycyBhcmUNCmlu Y3JlbWVudGFsIHdvcmsgYmV5b25kIFNUSVIsIG9yIGlmIFNUSVIgaXMgaW5jcmVtZW50YWwgd29y ayBiZXlvbmQNCmdyZWVuZmllbGQgaWRlbnRpZmllcnMuIEJ5IGhpc3RvcmljYWwgYWNjaWRlbnQs IGl0IHR1cm5zIG91dCB0byBiZSB0aGUNCmxhdHRlci4NCg0KSm9uIFBldGVyc29uDQpOZXVzdGFy LCBJbmMuDQoNCj4NCj5kLw0KPg0KPi0tIA0KPkRhdmUgQ3JvY2tlcg0KPkJyYW5kZW5idXJnIElu dGVybmV0V29ya2luZw0KPmJiaXcubmV0DQoNCg== From jon.peterson@neustar.biz Mon Jul 1 10:57: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 22E9A11E81B0 for ; Mon, 1 Jul 2013 10:57:32 -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.415, 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 qhC2tGPDKjUz for ; Mon, 1 Jul 2013 10:57:28 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id C8EC711E8197 for ; Mon, 1 Jul 2013 10:57:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1372701946; x=1688049085; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=VXi/VaByhk /Mz02p0gHnyLkNsmAnQ32C5hjGXiIhehk=; b=AW104eUlcUI88xMc0Lk0mNgOOR r45J8plRWfrsqGlrKD0gl1bi7uUjrvnP64av1GhwuGGvfNERusZ0t4jmVSIQ== Received: from ([10.31.58.71]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.27164258; Mon, 01 Jul 2013 14:05:45 -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, 1 Jul 2013 13:57:20 -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//+aqAAAJMP5AABqIi4A Date: Mon, 1 Jul 2013 17:57:19 +0000 Message-ID: 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: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.129.121] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: J3HMZzQQoB0F1s8Jdo/tQw== Content-Type: text/plain; charset="us-ascii" Content-ID: <072730CE44E74C40B194101EE2F322FD@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: Mon, 01 Jul 2013 17:57:32 -0000 On 6/29/13 1:18 AM, "Hadriel Kaplan" wrote: > >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. That has always been true in RFC4474, yes. See the language in Section 6, step 1: "SIP entities SHOULD discover this certificate by dereferencing the Identity-Info header, unless they have some more efficient implementation-specific way of acquiring certificates for that domain." The Identity-Info header is there to solve the credential discovery problem for environments where discovery is a problem. It provides "a" way to find the credential, not "the" way. That was always the intention here. As for whether it is an interop problem waiting to happen, the critical point here is that without "a" way to do it, yes, there would be interop problems. RFC4474 does have an MTI for Identity-Info, and yes it's worth considering whether it's right or if this should be adjusted somewhere. Jon Peterson Neustar, Inc. > >-hadriel > From richard@shockey.us Mon Jul 1 11:36: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 CB79611E820D for ; Mon, 1 Jul 2013 11:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.053 X-Spam-Level: X-Spam-Status: No, score=-101.053 tagged_above=-999 required=5 tests=[AWL=1.211, 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 k+5N7Tz0grJ1 for ; Mon, 1 Jul 2013 11:36:10 -0700 (PDT) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 2E23411E8125 for ; Mon, 1 Jul 2013 11:36:10 -0700 (PDT) Received: (qmail 5661 invoked by uid 0); 1 Jul 2013 18:35:47 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy13.unifiedlayer.com with SMTP; 1 Jul 2013 18:35:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=uLv+8I/BVMU3IFLJud8uBbGAB50rDUybjNf1SqbG+Uw=; b=S0LOtjyW3yfMfOuKl59DDe4EmIA8p7HnS8YJXjonVhPBoeXe7IN296USQJDEAyC139d5lBx4X5EcvD+uI8PLGE6Jyt5R8GBzhLhMNaMXqKIn/tAPF3zW6owhFFi6KRMA; Received: from [72.66.111.124] (port=50152 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Utix0-0004fo-An; Mon, 01 Jul 2013 12:35:46 -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> <006401ce7424$1e7371d0$5b5a5570$@shockey.us> <939661CC-A122-4B04-A18D-8E00C94E4452@att.com> <011501ce7676$79b756c0$6d260440$@shockey.us> <013501ce767c$781e3170$685a9450$@shockey.us> In-Reply-To: Date: Mon, 1 Jul 2013 14:35:44 -0400 Message-ID: <018301ce7689$ccc36e40$664a4ac0$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0184_01CE7668.45B4DB80" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFSz1HqEPsK2rOmM+sJgaXsYRJDIQI7uFAkAj6JaWgCF6RaiAKs8NY7AY4htgACFA+BuwE/ky+fAYPBB5cCAKnRJAFR8nnJAMFBynkCP03DuQH7I00NAlbZzeMBSmnMUwE/sJHpAU7ESzQB6QIYzgFHspaXAmh39QYBemZvawIuyElrAk9pV68B33LXqwHx+5pBAgpbOvuYyvPs0A== 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] 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, 01 Jul 2013 18:36:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0184_01CE7668.45B4DB80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit [RS> ] Well you still ignore that any carrier using CDMA right now cannot deploy your proposed solution since it cannot do data and Voice at the same time. Verizon Sprint and Korea Telecom might have something to say about that. Well, I feel generally sad for people who have that kind of phone. That said, I would want to double check you were correct about the inference here, since this is at the point where the phone has an incoming call but before it's been answered. Is data possible in that period? [RS> ] I doubt the interval is long enough. Frankly I don't know. But you should ask Apple among others :) http://bits.blogs.nytimes.com/2012/09/13/iphone-5-calls-data/?_r=0 -Ekr ------=_NextPart_000_0184_01CE7668.45B4DB80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
<= div>

 

[RS> ]  Well you still ignore that any carrier using CDMA = right now cannot deploy your proposed solution since it cannot do data = and Voice at the same time. Verizon Sprint and Korea Telecom might have = something to say about = that.

 

 

Well, I feel generally sad for people who have that = kind of phone.

 

That said, I would want to double check you were = correct about the

inference here, since this is at the point where the = phone has an

incoming call = but before it's been answered. Is data possible = in

that period?

 

 

[RS> ] I doubt the interval is long enough. Frankly I don’t = know. But you should ask Apple among others J 

 

http://bits.blogs.nytimes.com/2012/09/13/iphone-5-calls-data/?_r=3D0

 

 

-Ekr

 

------=_NextPart_000_0184_01CE7668.45B4DB80-- From jon.peterson@neustar.biz Mon Jul 1 11:36: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 66DF211E8227 for ; Mon, 1 Jul 2013 11:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.615 X-Spam-Level: X-Spam-Status: No, score=-105.615 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 UT-Sgc5o2V7b for ; Mon, 1 Jul 2013 11:36:26 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id CA64711E8125 for ; Mon, 1 Jul 2013 11:36:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1372703741; x=1688051963; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=Gknd9PXfRTR7mEHyLS996dSthrywYe6I0EoqaGIADM0=; b=JHptvLEpTasGM1OHII6iBsUXyzQyCHTdlkZ4yLsuPSh1+NP8eiZ9hfFKsRijej nHfPe9sxdPZZFXpUtZQNujUg== Received: from ([10.31.58.70]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.21684071; Mon, 01 Jul 2013 14:35:40 -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, 1 Jul 2013 14:36:20 -0400 From: "Peterson, Jon" To: Richard Shockey , 'Eric Rescorla' , "'DOLLY, MARTIN C'" Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObVQeiPo9mlqJ3kmapUg6mjJxlJk+y9aAgACHMgD//49rgIACHTwAgAPpuACAAI98gIAAArwAgAAJJQCAAMiFgIAAYW+AgAA/UICAAAVDgIAABX+AgAF0k4CAAx4NgIAAB9CAgAAC/wCAABpmgIAAAXSAgAM7o4CAAAEvgIAABGQAgAAMg4CAAAIOAIAAAeqAgAACSoCAAADwAIAAAy0AgAEeuYCAACxyAP//sXcA Date: Mon, 1 Jul 2013 18:36:20 +0000 Message-ID: In-Reply-To: <011501ce7676$79b756c0$6d260440$@shockey.us> 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.121] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 8WfzIumRgje9mfBYYsfiAw== Content-Type: multipart/alternative; boundary="_000_CDF7146E37F54jonpetersonneustarbiz_" 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: Mon, 01 Jul 2013 18:36:30 -0000 --_000_CDF7146E37F54jonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable You're studying the right trends here, but I'm not sure you're correctly as= sessing their salience to the out-of-band proposal. Sure, iMessage isn't poised to take over the world, it's just a texting fea= ture for iOS. It is however an existence proof that you can build out-of-ba= nd systems like this, that they can be built "into the dialer" more or less= , that they can rely on a centralized authority, that they can be transpare= nt to end users, and rolled out to millions. It seems that it can be operat= ed and deployed. I definitely agree that "landline" enterprise is responsible for a huge chu= nk of calls today. But how much of that is anything remotely like POTS? How= many of these deployments are, in fact, exactly the devices that Cisco wan= ted to enable VIPR for: islands of IP phones that are forced to lose valuab= le signaling by traversing the PSTN. Any STIR out-of-band solution should w= ork not just for smart phones, but for these enterprises as well. In what s= ense must a solution for enterprises be "only network-based?" Finally, how much residential landline deployment will be POTS in five year= s? We've both seen the charts that show how rapidly that market is diminish= ing. What's replacing it? Unfortunately, little by way of direct IP-to-IP c= ommunication, and far more calls being dropped to the PSTN. Again, this is = exactly where the out-of-band solution can help. We can argue about where t= he right place is to implement and operate it =96 and I don't think there's= any consensus about that yet =96 but we've heard strategies that would wor= k at endpoints (maybe ATAs) or in the network. I'm not sure where you see "crowd source reputation" in STIR, which propose= s to build just the identity part. When identity is trusted, certainly ther= e could be reputation systems that rely on that, but that's not in the prop= osed scope I don't think. Jon Peterson NeuStar, Inc. From: Richard Shockey > Date: Monday, July 1, 2013 9:17 AM To: Eric Rescorla >, "'DOLLY, MARTIN C'" = > Cc: "stir@ietf.org" >, 'Henning Schulzrinne' > Subject: Re: [stir] Out-of-band vs. in-band NO this does not help at all. Irrespective of what may or may not be possi= ble on handsets it=92s irrelevant to the problem. You ignore that nearly 50% or more of the voice minutes are probably landli= ne enterprise and residential. Where no solution is possible unless its net= work based. This includes nearly all Enterprise Voice ( aka SIP Trunking) = and Digital voice over a broadband connection aka FIOS, uVerse and other DS= L derivatives in Europe and elsewhere. The data indicates that SIP Trunkin= g will pass T1 enabled circuits/sessions by 2016 in the US and Canada. If a network based solution could be designed and implemented, and I think = it=92s possible, then the handset problem goes away as well in VoLTE/IMS op= erations and we know that CDMA and HSPA+ system which still use TDM switchi= ng will be retired sooner rather than later. . I have zero confidence that= some crowd source reputation based system would work and I=92m very skepti= cal on anything that would involve an E2E like system. It would be usefu= l it some people try think like a normal consumer or small business and not= the IETF=92er. Part of our task it to remove complexity from system not= inject it. Just because iMessage is cool doesn=92t mean it=92s poised to take over the= world. A network solution may not be possible but it=92s the shortest path to succ= ess in the short term. From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Eric Rescorla Sent: Monday, July 01, 2013 9:38 AM To: DOLLY, MARTIN C Cc: stir@ietf.org; Richard Shockey; Henning Schulzrin= ne Subject: Re: [stir] Out-of-band vs. in-band It might help to clarify my position here... >From a technical perspective, most of the stuff on a smartphone is an app, including the dialer. >From a user's perspective, the dialer is something built into the phone.. If we build something that requires the user to replace their dialer with something they download, that's not going to be very successful. >From the perspective of what we can build, however. since we know the dialer is just general purpose code running on the phone, and we know that downloadable apps can do DB lookups as calls come in, we know that there's no major technical obstacle to the smartphone vendor building a dialer that does such lookups. This of course does not mean that they will, but means that a design that depends on it is feasible technically. Hope that helps. -Ekr On Sun, Jun 30, 2013 at 1:32 PM, Eric Rescorla > wrote: 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 s= he has a smart phone. This is the user we have to protect=85 do you agree? 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 f= lavors, 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 featu= re to a program. Is that something you disagree with? -Ekr --_000_CDF7146E37F54jonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

You're studying the right trends here, but I'm not sure you're correct= ly assessing their salience to the out-of-band proposal.

Sure, iMessage isn't poised to take over the world, it's just a textin= g feature for iOS. It is however an existence proof that you can build out-= of-band systems like this, that they can be built "into the dialer&quo= t; more or less, that they can rely on a centralized authority, that they can be transparent to end users, and rolled out to mi= llions. It seems that it can be operated and deployed.

I definitely agree that "landline" enterprise is responsible= for a huge chunk of calls today. But how much of that is anything remotely= like POTS? How many of these deployments are, in fact, exactly the devices= that Cisco wanted to enable VIPR for: islands of IP phones that are forced to lose valuable signaling by traversing the = PSTN. Any STIR out-of-band solution should work not just for smart phones, = but for these enterprises as well. In what sense must a solution for enterp= rises be "only network-based?"

Finally, how much residential landline deployment will be POTS in five= years? We've both seen the charts that show how rapidly that market is dim= inishing. What's replacing it? Unfortunately, little by way of direct IP-to= -IP communication, and far more calls being dropped to the PSTN. Again, this is exactly where the out-of-b= and solution can help. We can argue about where the right place is to imple= ment and operate it =96 and I don't think there's any consensus about that = yet =96 but we've heard strategies that would work at endpoints (maybe ATAs) or in the network.

I'm not sure where you see "crowd source reputation" in STIR= , which proposes to build just the identity part. When identity is trusted,= certainly there could be reputation systems that rely on that, but that's = not in the proposed scope I don't think.

Jon Peterson
NeuStar, Inc.

From: Richard Shockey <richard@shockey.us>
Date: Monday, July 1, 2013 9:17 AM<= br> To: Eric Rescorla <ekr@rtfm.com>, "'DOLLY, MARTIN C'" <= md3135@att.com>
Cc: "stir@ietf.org" <stir@i= etf.org>, 'Henning Schulzrinne' <Henning.Schulzrinne@fcc.gov>
Subject: Re: [stir] Out-of-band vs.= in-band

NO this does not help at all. = ; Irrespective of what may or may not be possible on handsets it=92s irrele= vant to the problem.

 

You ignore that nearly 50% or more= of the voice minutes are probably landline enterprise and residential. Whe= re no solution is possible unless its network based. This includes nearly all Enterprise Voice ( aka SIP Trunkin= g)  and Digital voice over a broadband connection aka FIOS, uVerse and= other DSL derivatives in Europe and elsewhere.  The data indicates th= at SIP Trunking will pass T1 enabled circuits/sessions by 2016 in the US and Canada.

 

If a network based solution could = be designed and implemented, and I think it=92s possible, then the handset = problem goes away as well in VoLTE/IMS operations and we know that CDMA and HSPA+ system which still use TDM = switching will be retired sooner rather than later.  . I have zero con= fidence that some crowd source reputation based system would work and I=92m= very skeptical on anything that would involve an E2E like system.    It would be useful it some people tr= y think like a normal consumer or small business and not the IETF=92er.&nbs= p;   Part of our task it to remove complexity from system not inj= ect it.

 

Just because iMessage is cool does= n=92t mean it=92s poised to take over the world.  

 

A network solution may not be poss= ible but it=92s the shortest path to success in the short term.

 

From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Monday, July 01, 2013 9:38 AM
To: DOLLY, MARTIN C
Cc: stir@ietf.org; Richard Shoc= key; Henning Schulzrinne
Subject: Re: [stir] Out-of-band vs. in-band

 

It might help to clarify my position here...

 

From a technical perspective, most of the stuff on a= smartphone is an app,

including the dialer.

 

From a user's perspective, the dialer is something b= uilt into the phone..

If we build something that requires the user to repl= ace their dialer with

something they download, that's not going to be very= successful.

 

From the perspective of what we can build, however. = since we know the

dialer is just general purpose code running on the p= hone, and we know

that downloadable apps can do DB lookups as calls co= me in,

we know that there's no major technical obstacle to = the smartphone

vendor building a dialer that does such lookups. Thi= s of course does

not mean that they will, but means that a design tha= t depends on

it is feasible technically.

 

Hope that helps.

-Ekr

 

 

On Sun, Jun 30, 2013 at 1:32 PM, Eric Rescorla <<= a href=3D"mailto:ekr@rtfm.com" target=3D"_blank">ekr@rtfm.com> wrote= :

 

 

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

Eric,

 

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

 

I'm not sure you and I have the same definition of &= quot;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, app= s come in 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= particularly difficult about

the smartphone manufacturer adding this sort of func= tionality to the builtin

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

 

 

 --_000_CDF7146E37F54jonpetersonneustarbiz_-- From dhc@dcrocker.net Mon Jul 1 12:10: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 9302E11E8262 for ; Mon, 1 Jul 2013 12:10:48 -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 ikI1EQ4cR7lR for ; Mon, 1 Jul 2013 12:10:43 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 30A4711E8252 for ; Mon, 1 Jul 2013 12:10: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 r61JAdkP011329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Jul 2013 12:10:42 -0700 Message-ID: <51D1D424.8000003@dcrocker.net> Date: Mon, 01 Jul 2013 12:10:28 -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" , "stir@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 01 Jul 2013 12:10:43 -0700 (PDT) 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: Mon, 01 Jul 2013 19:10:48 -0000 Jon, On 7/1/2013 10:53 AM, Peterson, Jon wrote: >> So, for example, using a DKIM-derived scheme is quite a different >> architecture from the one you've proposed. > > Actually, RFC4474 is totally agnostic to how credentials are > acquired, as Using the word "credential" highlights the disconnect happening here. DKIM doesn't use credentials. But again, my core point was that we are already seeing quite a bit of technical debate across many aspects of the current, narrower topic. As for being agnostic, that's an example of the distraction that RFC4474 provides for the current discussion. Lots of detail, much of which is not relevant to the current topic, /and/ not enough detail to be a complete service. > I've said several times in this thread. The URI in Identity-Info is > always just a hint, RFC4474 says you can ignore it if you already > have a I don't understand how that's relevant to my note. To the extent that you are citing the presence of even more choice, that's exactly the problem. There's more than enough to debate and specify, within the narrow confines of the very specific problem that's been posed here. It does not need the additional baggage of an un-deployed, old specification that is both broad and -- as you've just highlighted as 'agnostic' -- incomplete. >> 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.) > > The variety of canonicalization under discussion here (over in that > "URI Format" thread), where the originator and terminator must > synthesize identical copies of a string that does not appear in the > message itself, has no corollary in any email practice I'm aware of. So the current situation does not involve challenges and compromises? That was, after all, all that I said about the experience with DKIM canonicalization. Your insisting that the current situation has more variety -- and presumably therefore more challenges -- actually emphasizes nicely the point I was making, which is that the current effort has more than enough work to do, by staying strictly within the confines of the current task. >>> 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. > > This is basically an administrative question about how we steer and > organize the work. I have no idea what that response means. I cited a question of relevance to technical work and you somehow converted that to an 'administrative' concern, whatever that means. >>> 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. > > Signers that have authority for telephone numbers. ack. Just to be clear, since you cite 'addition of a new' category, who was the 'old' category of signing authority and what was being signed? >>> 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. > > As a URI in Identity-Info (again, this has been discussed several > times now). Jon, I looked and didn't find a reference to the DNS URI in the current documents and don't recall any in the mailing list discussion. I'm asking for a pointer that is more precise than "it's been discussed before". >>> 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? > > To ascertain the reference integrity of the identity with the > authority of the signature. Sorry, I'm still confused. Perhaps you merely mean verify authorization to use the number -- that is, that the signature proves authorization? >>> 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. > > Being able to differentiate a user part that is a phone number from a > user part that is not is not entirely trivial, as has been previously > discussed in this thread. A verifier that receives a request needs to > figure out if the user part is a telephone number or not. Ideally, > the verifier would understand the handling of the case where it is > not. 1. To the extent that ascertaining the telephone number is really a heuristic, it's unlikely the service will work globally -- heuristics aren't deterministic and therefore they fail sometimes; to the extent that there is a deterministic algorithm, that's a hassle, but it can work. 2. As for your 'ideally' sentence, happily that's out of scope for this work. >> 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 mean SIP URIs with a user@domain format, where the user part is not > a telephone number. oh. (Is that documented anywhere?) >>> 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. > > Again, this is a question of whether greenfield identifiers are > incremental work beyond STIR, or if STIR is incremental work beyond > greenfield identifiers. By historical accident, it turns out to be > the latter. You mean the work that hasn't gained deployment 6 years after standardization? Sometimes baggage is a boat anchor. On 7/1/2013 10:57 AM, Peterson, Jon wrote: >> So are you saying that verifiers can basically just ignore the HTTP URL? >> I hadn't noticed that exception before in RFC 4474. ... > That has always been true in RFC4474, yes. See the language in > Section 6, step 1: "SIP entities SHOULD discover this certificate by That's rather less casual a normative statement that was implied by your comment here. Deviating from a 'should' is supposed to be exceptional and based on very high levels of specialized knowledge. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From md3135@att.com Mon Jul 1 12:34: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 6179D11E811B for ; Mon, 1 Jul 2013 12:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.242 X-Spam-Level: X-Spam-Status: No, score=-4.242 tagged_above=-999 required=5 tests=[AWL=2.356, 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 onDkeYS1i2pO for ; Mon, 1 Jul 2013 12:34:08 -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 D8AC811E822D for ; Mon, 1 Jul 2013 12:33:59 -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 7a9d1d15.0.7200721.00-430.20073803.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 01 Jul 2013 19:33:59 +0000 (UTC) X-MXL-Hash: 51d1d9a7243726b9-9e6d83d710b72e75f4f794f31544a3675131ceb9 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 r61JXxLP022688 for ; Mon, 1 Jul 2013 15:33:59 -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 r61JXqCA022541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 1 Jul 2013 15:33:55 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by mlpi408.sfdc.sbc.com (RSA Interceptor) for ; Mon, 1 Jul 2013 19:33:40 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; Mon, 1 Jul 2013 15:33:50 -0400 From: "DOLLY, MARTIN C" To: "stir@ietf.org" Thread-Topic: Charter Thread-Index: Ac52kd9zmQmJF9jyQri70Ma4cCE7Qw== Date: Mon, 1 Jul 2013 19:33:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.81.102] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E83656021D8EB1MISOUT7MSGUSR9I_" 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: [=nRjNO9GAj70A:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=u9ZQ21AiHSFLlqHnHEcA:9 a=Cj] X-AnalysisOut: [uIK1q_8ugA:10 a=qM39cor4HRgA:10 a=Hz7IrDYlS0cA:10 a=6zCas9] X-AnalysisOut: [uticUY0AFnELQA:9 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=DV2] X-AnalysisOut: [FbbhnbVGzR82D:21] Subject: [stir] Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 01 Jul 2013 19:34:16 -0000 --_000_E42CCDDA6722744CB241677169E83656021D8EB1MISOUT7MSGUSR9I_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings, Where are we at with the charter? And who has the power of the pen? Are charter updates reflecting the list consensus? Martin Dolly Lead Member Technical Staff Core & Government/Regulatory Standards AT&T Labs md3135@att.com +1-609-903-3360 --_000_E42CCDDA6722744CB241677169E83656021D8EB1MISOUT7MSGUSR9I_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Greetings,
 
Where are we at with the charter? And who has the power of the pen?
 
Are charter updates reflecting the list consensus?
 
Martin Dolly
Lead Member Technical Staff
Core & Government/Regulatory Standards
AT&T La= bs
md3135@att.com
+1-609-903-3360
 
 
 
 --_000_E42CCDDA6722744CB241677169E83656021D8EB1MISOUT7MSGUSR9I_-- From richard@shockey.us Mon Jul 1 12: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 4B5C811E824C for ; Mon, 1 Jul 2013 12:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.226 X-Spam-Level: X-Spam-Status: No, score=-101.226 tagged_above=-999 required=5 tests=[AWL=1.038, 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 0KvmmhFdlZnA for ; Mon, 1 Jul 2013 12:34:22 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 8A7F021F9993 for ; Mon, 1 Jul 2013 12:34:09 -0700 (PDT) Received: (qmail 21691 invoked by uid 0); 1 Jul 2013 19:33:47 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.bluehost.com with SMTP; 1 Jul 2013 19:33:47 -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=UDW1zwrXE0FGuNVMsautkqGbNRVMbPsLcsszzXmzucM=; b=NBNmpE85MOV9hJ1oZz7dwESbJXFit9OAl0AUWy2am1ZUKXb1xKYSkPlAMVBj7AGNag2BpfGQfMyzfhwqdW4oAZU/GdzBWLaYOxzHFniEjwutCXqslWpwFmW1xm8+ICxG; Received: from [72.66.111.124] (port=50973 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Utjr8-0004Aj-Qp; Mon, 01 Jul 2013 13:33:47 -0600 From: "Richard Shockey" To: "'Peterson, Jon'" , "'Eric Rescorla'" , "'DOLLY, MARTIN C'" References: <011501ce7676$79b756c0$6d260440$@shockey.us> In-Reply-To: Date: Mon, 1 Jul 2013 15:33:44 -0400 Message-ID: <01bc01ce7691$e73f8bc0$b5bea340$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BD_01CE7670.602F9970" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHDOB5LhoeiGRMhSvO1W6HvXA0cAplmqWxA 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] 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, 01 Jul 2013 19:34:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01BD_01CE7670.602F9970 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Monday, July 01, 2013 2:36 PM To: Richard Shockey; 'Eric Rescorla'; 'DOLLY, MARTIN C' Cc: stir@ietf.org; 'Henning Schulzrinne' Subject: Re: [stir] Out-of-band vs. in-band You're studying the right trends here, but I'm not sure you're correctly assessing their salience to the out-of-band proposal. Sure, iMessage isn't poised to take over the world, it's just a texting feature for iOS. It is however an existence proof that you can build out-of-band systems like this, that they can be built "into the dialer" more or less, that they can rely on a centralized authority, that they can be transparent to end users, and rolled out to millions. It seems that it can be operated and deployed. [RS> ] Fine if you have HSPA LTE devices on GSM networks. We will have to agree to disagree about this. But you are falling into the trap that Dave Crocker pointed out earlier today. I definitely agree that "landline" enterprise is responsible for a huge chunk of calls today. But how much of that is anything remotely like POTS? RS> well at least 90% since TDM is the default interconnection network. SIP Interconnection is progressing nicely and some carriers have been able to specifically segment their SIP from TDM traffic to permit SIP end to end in network. You know all of this. How many of these deployments are, in fact, exactly the devices that Cisco wanted to enable VIPR for: islands of IP phones that are forced to lose valuable signaling by traversing the PSTN. Any STIR out-of-band solution should work not just for smart phones, but for these enterprises as well. In what sense must a solution for enterprises be "only network-based?" RS> VIPR was DOA from the start. PLEASE let's not go over that again. Its as useless as rehashing e164.arpa. My point is still a network based, in band solution has the best shortest path to immediate deployment and is the best overall given PSTN Transition as it is evolving. If people want to work on out of band ..fine, but not until a design for in band can be articulated. I have total confidence that there will be no carrier investment in existing SS7 TDM networks now and in the foreseeable future. Finally, how much residential landline deployment will be POTS in five years? RS> Reasonable question but the real question is how does resident landline evolve in an all IP world. Those black phones will be B2BUA forever. Putting my Wall Street analyst hat on you have to remember wireless in NA and EU is at full saturation. There is no growth in those markets. The largest threat to landline right now are the fascists running the Walt Disney Company who jack up ESPN rates to the point where families are forced into a decision to choose between NFL and a phone. The data also indicates some resurgence in landline as new household formation w/ young children puts a premium on E911 reliability of the landline vs mobile. In addition there is the expectation that what you think of as landline voice only evolves into something more interesting where the TV is really the phone and full SIP based UC based on all SIP interconnection is possible. You are falling into the other trap of extrapolating some data points to a conclusion where technology may enable a different outcome. As JM Keynes said "in the long run we are all dead" We've both seen the charts that show how rapidly that market is diminishing. What's replacing it? RS> The data is misleading since it relies on regulatory data that looks at "lines" vs "numbers utilized" . Of course landline phones are declining especially in key demographics but it is not as bad as people think. Just as Skype has not really damaged the interconnected voice markets. Only eroded its margins. The same is playing out in SMS. The fractured silos of IM/SIMPLE etc only enhanced the value of the crappy SMS service. WhatsAPP etc are still E.164 based for a reason. Universal reachability actually works and people pay for what works. As a side bar this is the reason I don't have a lot of confidence WEBRTC is really going to be the New New thing. Unfortunately, little by way of direct IP-to-IP communication, and far more calls being dropped to the PSTN. RS> Well again I have already shown that there is far more SIP 2 SIP communication now in deployment than people realize and that is going to accelerate. Again, this is exactly where the out-of-band solution can help. We can argue about where the right place is to implement and operate it - and I don't think there's any consensus about that yet - but we've heard strategies that would work at endpoints (maybe ATAs) or in the network. RS> EKR's proposal .. no way. Too many endpoints would never be able to access the data given the need to deploy at least one _deployable_ solution in a reasonable time frame. RS> That said now that you have had your daily dose of market reality we can return you to your regularly schedule program... ------=_NextPart_000_01BD_01CE7670.602F9970 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: = stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Peterson, Jon
Sent: Monday, July 01, 2013 2:36 = PM
To: Richard Shockey; 'Eric Rescorla'; 'DOLLY, MARTIN = C'
Cc: stir@ietf.org; 'Henning Schulzrinne'
Subject: = Re: [stir] Out-of-band vs. in-band

 

 

You're studying the right trends here, but I'm not sure you're = correctly assessing their salience to the out-of-band = proposal.

 

Sure, iMessage isn't poised to take over the world, it's just a texting = feature for iOS. It is however an existence proof that you can build = out-of-band systems like this, that they can be built "into the = dialer" more or less, that they can rely on a centralized = authority, that they can be transparent to end users, and rolled out to = millions. It seems that it can be operated and = deployed.

 

[RS> ] Fine if you have HSPA LTE devices on GSM networks.  We = will have to agree to disagree about this. But you are falling into the = trap that Dave Crocker pointed out earlier today.

 

I definitely agree that "landline" enterprise is responsible = for a huge chunk of calls today. But how much of that is anything = remotely like POTS?

 

RS> well at least 90% since TDM is the default interconnection = network.  SIP Interconnection is progressing nicely and some = carriers have been able to specifically segment their SIP from TDM = traffic to permit SIP end to end in network. You know all of this. =

 

How many of these deployments are, in fact, exactly the devices that = Cisco wanted to enable VIPR for: islands of IP phones that are forced to = lose valuable signaling by traversing the PSTN. Any STIR out-of-band = solution should work not just for smart phones, but for these = enterprises as well. In what sense must a solution for enterprises be = "only network-based?"

 

RS> VIPR was DOA from the start.   PLEASE let’s not = go over that again.  Its as useless as rehashing e164.arpa. =  My point is still a network based, in band solution has the best = shortest path to immediate deployment and is the best overall given PSTN = Transition as it is evolving.  If people want to work on out of = band ..fine, but not until a design for in band can be articulated. =  I have total confidence that there will be no carrier investment = in existing SS7 TDM networks now and in the foreseeable future. =

 

 

 

Finally, how much residential landline deployment will be POTS in five = years?

 

RS> Reasonable question but the real question is how does resident = landline evolve in an all IP world.  Those black phones will be = B2BUA forever. Putting my Wall Street analyst hat on you have to = remember wireless in NA and EU is at full saturation.  There is no = growth in those markets.  The largest threat to landline right now = are the fascists running the Walt Disney  Company who jack up ESPN = rates to the point where families are forced into a decision to choose = between NFL and a phone.  The data also indicates some resurgence = in landline as new household formation w/ young children puts a premium = on E911 reliability of the landline vs mobile.  In addition there = is the expectation that what you think of as landline voice only evolves = into something more interesting where the TV is really the phone and = full SIP based UC based on all SIP interconnection is possible.  = You are falling into the other trap of extrapolating some data points to = a conclusion where technology may  enable a different = outcome.  As JM Keynes said “in the long run we are all = dead”

 

We've both seen the charts that show how rapidly that market is = diminishing. What's replacing it?

 

RS> The data is misleading since it relies on regulatory data that = looks at “lines” vs “numbers utilized” .  =  Of course landline phones are declining especially in key = demographics but it is not as bad as people think.  Just as Skype = has not really damaged the interconnected voice markets. Only eroded its = margins.  The same is playing out in SMS.  The fractured silos = of IM/SIMPLE etc only enhanced the value of the crappy SMS service. = WhatsAPP etc are still E.164 based for a reason. Universal reachability = actually works and people pay for what works.  As a side bar this = is the reason I don’t have a lot of confidence WEBRTC is really = going to be the New New thing.   

 

Unfortunately, little by way of direct IP-to-IP communication, and far = more calls being dropped to the PSTN.

 

RS> Well again I have already shown that there is far more SIP 2 SIP = communication now in deployment than people realize and that is going to = accelerate.

 

Again, this is exactly where the out-of-band solution can help. We can = argue about where the right place is to implement and operate it – = and I don't think there's any consensus about that yet – but we've = heard strategies that would work at endpoints (maybe ATAs) or in the = network.

 

RS>  EKR’s proposal .. no way.  Too many endpoints = would never be able to access the data given the need to deploy at least = one _deployable_ solution in a reasonable time frame.  =  

 

RS> That said now that you have had your daily dose of market = reality we can return you to your regularly schedule = program…..

 

 

------=_NextPart_000_01BD_01CE7670.602F9970-- From dhc@dcrocker.net Mon Jul 1 12:42: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 6688211E8271 for ; Mon, 1 Jul 2013 12:42:03 -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 2WMQQiOvRHFl for ; Mon, 1 Jul 2013 12:41:58 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E2C4911E825A for ; Mon, 1 Jul 2013 12:41:58 -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 r61JfrBF011850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Jul 2013 12:41:56 -0700 Message-ID: <51D1DB76.2030901@dcrocker.net> Date: Mon, 01 Jul 2013 12:41:42 -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: "DOLLY, MARTIN C" 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, 01 Jul 2013 12:41:56 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] 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, 01 Jul 2013 19:42:03 -0000 On 7/1/2013 12:33 PM, DOLLY, MARTIN C wrote: > Greetings, > Where are we at with the charter? And who has the power of the pen? > Are charter updates reflecting the list consensus? Yeah, we should try to close this. Thanks for raising it. I've assumed that I should fold in revisions and re-issue, but I raised some questions that I don't think got resolved. For convenience, here are the items I think are still open: > Subject: Re: [stir] Revised charter text for STIR > Date: Thu, 27 Jun 2013 16:43:29 -0700 > From: Dave Crocker ... >>> 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. Keep/Drop?? >> 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. OK to change to this? >>> 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. I'm still unfed. Anyone have a sentence to offer that will satisfy this suggestion? >>> 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. To confirm, I think this reduces to removing all references except the 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. } Use the new text I suggest? If not, someone needs to offer an alternative that folks like better. >>> - 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. H E L P! I don't know what to replace this with. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Mon Jul 1 12:45: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 076F911E827F for ; Mon, 1 Jul 2013 12:45:19 -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 cDImeWep+LYq for ; Mon, 1 Jul 2013 12:45:14 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1D70D11E825C for ; Mon, 1 Jul 2013 12:45:13 -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 r61Jj0X3011918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Jul 2013 12:45:10 -0700 Message-ID: <51D1DC32.1080308@dcrocker.net> Date: Mon, 01 Jul 2013 12:44:50 -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: Richard Shockey References: <011501ce7676$79b756c0$6d260440$@shockey.us> <01bc01ce7691$e73f8bc0$b5bea340$@shockey.us> In-Reply-To: <01bc01ce7691$e73f8bc0$b5bea340$@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, 01 Jul 2013 12:45:10 -0700 (PDT) Cc: stir@ietf.org, 'Eric Rescorla' , "'DOLLY, MARTIN C'" , "'Peterson, Jon'" , '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: Mon, 01 Jul 2013 19:45:19 -0000 On 7/1/2013 12:33 PM, Richard Shockey wrote: > You're studying the right trends here, but I'm not sure you're correctly > assessing their salience to the out-of-band proposal. Do we really want to keep discussing the out-of-band topic. The more we spend talking about it, a) the less we spend on the in-band one, and b) the more it looks like we want to include it in the initial work. If the group wants to focus on a single, narrow deliverable as its initial effort, it needs to focus on that signle, narrow deliverable... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From timothy.dwight@verizon.com Mon Jul 1 13:05: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 017F411E8217 for ; Mon, 1 Jul 2013 13:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xqp8n4dBxpiF for ; Mon, 1 Jul 2013 13:04:53 -0700 (PDT) Received: from omzsmtpe01.verizonbusiness.com (omzsmtpe01.verizonbusiness.com [199.249.25.210]) by ietfa.amsl.com (Postfix) with ESMTP id 304F211E81A1 for ; Mon, 1 Jul 2013 13:04:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by omzsmtpe01.verizonbusiness.com with ESMTP; 01 Jul 2013 20:04:51 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.87,975,1363132800"; d="scan'208,217";a="499976402" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi02.verizon.com with ESMTP; 01 Jul 2013 20:04:51 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Mon, 1 Jul 2013 16:04:51 -0400 To: Richard Shockey , 'Eric Rescorla' Date: Mon, 1 Jul 2013 16:04:50 -0400 Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQFSz1HqEPsK2rOmM+sJgaXsYRJDIQI7uFAkAj6JaWgCF6RaiAKs8NY7AY4htgACFA+BuwE/ky+fAYPBB5cCAKnRJAFR8nnJAMFBynkCP03DuQH7I00NAlbZzeMBSmnMUwE/sJHpAU7ESzQB6QIYzgFHspaXAmh39QYBemZvawIuyElrAk9pV68B33LXqwHx+5pBAgpbOvuYyvPs0IAABYmQ Message-ID: <2B0F677F0B95454297753F58D4A07FA30127F611E0@FHDP1LUMXC7V31.us.one.verizon.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> <939661CC-A122-4B04-A18D-8E00C94E4452@att.com> <011501ce7676$79b756c0$6d260440$@shockey.us> <013501ce767c$781e3170$685a9450$@shockey.us> <018301ce7689$ccc36e40$664a4ac0$@shockey.us> In-Reply-To: <018301ce7689$ccc36e40$664a4ac0$@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2B0F677F0B95454297753F58D4A07FA30127F611E0FHDP1LUMXC7V3_" 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, 01 Jul 2013 20:05:00 -0000 --_000_2B0F677F0B95454297753F58D4A07FA30127F611E0FHDP1LUMXC7V3_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rich, Eric, CDMA radios use spread spectrum technology. They can receive from multiple= sources, each of which is encoded using its own pseudo-random code. The r= adio has to "lock" to one input source (at a time) because it needs that co= de in order to recover the data. If the 'data' source is e.g., the Internet, and the alerting source is the = voice network, a single radio couldn't receive them both at the same time. Conventional (3G) CDMA phones are single radio systems. I think that's wha= t Rich is referring to. Technology changes fast in the mobile world, though. I'm tempted to say "j= ust assume VoLTE", which will of course support simultaneous voice and data= , and which should be widely available in the timeframe that this (or any) = WG can produce an RFC. But I wouldn't swear that the rise of VoLTE means t= he demise of 3G. Landline replacement services based on 3G technology, for= example, are gaining traction. Tim From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Ric= hard Shockey Sent: Monday, July 01, 2013 1:36 PM To: 'Eric Rescorla' Cc: stir@ietf.org Subject: Re: [stir] Out-of-band vs. in-band [RS> ] Well you still ignore that any carrier using CDMA right now cannot = deploy your proposed solution since it cannot do data and Voice at the same= time. Verizon Sprint and Korea Telecom might have something to say about t= hat. Well, I feel generally sad for people who have that kind of phone. That said, I would want to double check you were correct about the inference here, since this is at the point where the phone has an incoming call but before it's been answered. Is data possible in that period? [RS> ] I doubt the interval is long enough. Frankly I don't know. But you s= hould ask Apple among others :) http://bits.blogs.nytimes.com/2012/09/13/iphone-5-calls-data/?_r=3D0 -Ekr --_000_2B0F677F0B95454297753F58D4A07FA30127F611E0FHDP1LUMXC7V3_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Rich, Eric,

 

CDMA radios use sp= read spectrum technology.  They can receive from multiple sources, eac= h of which is encoded using its own pseudo-random code.  The radio has= to “lock” to one input source (at a time) because it needs tha= t code in order to recover the data.

=  

If the ‘data’ source is e.g.,= the Internet, and the alerting source is the voice network, a single radio= couldn’t receive them both at the same time.

 

Conventional (3G) CDMA phon= es are single radio systems.  I think that’s what Rich is referr= ing to. 

 

=

Technology changes fast in the mobile world, though.  IR= 17;m tempted to say “just assume VoLTE”, which will of course s= upport simultaneous voice and data, and which should be widely available in= the timeframe that this (or any) WG can produce an RFC.  But I wouldn= ’t swear that the rise of VoLTE means the demise of 3G.  Landlin= e replacement services based on 3G technology, for example, are gaining tra= ction.

 

Tim

 

 

 

From: stir-bounces@ietf.org [mailto:stir-bounc= es@ietf.org] On Behalf Of Richard Shockey
Sent: Monday, Ju= ly 01, 2013 1:36 PM
To: 'Eric Rescorla'
Cc: stir@ietf.o= rg
Subject: Re: [stir] Out-of-band vs. in-band<= /p>

 

 

[RS> ]  Well you still ignor= e that any carrier using CDMA right now cannot deploy your proposed solutio= n since it cannot do data and Voice at the same time. Verizon Sprint and Ko= rea Telecom might have something to say about that.

 

 

Well, I feel generally sad for people = who have that kind of phone.

=  

That said, I would wan= t to double check you were correct about the

inference here, since this is at the point where the phone = has an

incoming call but befo= re it's been answered. Is data possible in

that period?<= /p>

 

 

= [RS> ] I doubt the interval is long enough. Frankly I don&#= 8217;t know. But you should ask Apple among others J<= /i> 

 

http://bits.blogs.nytimes.com/2012/09/13/iphone-5-calls-da= ta/?_r=3D0

 

 <= /p>

-Ekr

 

= --_000_2B0F677F0B95454297753F58D4A07FA30127F611E0FHDP1LUMXC7V3_-- From Henning.Schulzrinne@fcc.gov Mon Jul 1 13:24: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 0381511E8248 for ; Mon, 1 Jul 2013 13:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.872 X-Spam-Level: X-Spam-Status: No, score=-0.872 tagged_above=-999 required=5 tests=[AWL=1.727, 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 e48tYgVmqGmC for ; Mon, 1 Jul 2013 13:24:32 -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 E3E4921F9FF1 for ; Mon, 1 Jul 2013 13:24:22 -0700 (PDT) Message-ID: X-CheckPoint: {51D1E575-29-D2C987A5-FFFF} From: Henning Schulzrinne To: "'dcrocker@bbiw.net'" , Richard Shockey Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObffB01fXrRHtXUWe5nyT4KMtCplA/mcAgARfFAD//9WzZYAARyoA///B17GAAQ/TgIAAYW+AgAA/UICAAAVDgIAABX+AgAF0k4CAAx4NgIAAB9CAgAAC/wCAABpmgIAAAXSAgAL2fjWAAEZUgP//wDsbAAoVkYD//73B+4AARjaAgAACS4CAAADvAIAAAy0AgAEeuYCAACxzAIAAJtEAgAAQCQCAAAMaAIAAQIdw Date: Mon, 1 Jul 2013 20:24:20 +0000 References: <011501ce7676$79b756c0$6d260440$@shockey.us> <01bc01ce7691$e73f8bc0$b5bea340$@shockey.us> <51D1DC32.1080308@dcrocker.net> In-Reply-To: <51D1DC32.1080308@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" , 'Eric Rescorla' , "'DOLLY, MARTIN C'" , "'Peterson, Jon'" 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, 01 Jul 2013 20:24:37 -0000 I'm getting a bit worried that the in-band/out-of-band description sets up = an artificial division that presumes certain implementation choices or part= icular proposals. Particularly given some of the discussion about DNS-based= retrievals of certificates and/or public keys, there may well be options t= hat query databases, regardless of whether the identifying information is d= elivered by SIP or some non-SIP mechanism. In both cases, we seem to agree that three pieces of information arrive at = the callee or an entity (carrier) acting on its behalf: the calling number,= the called number and the time of call origination. These are, with quibbl= es we have labored through, available regardless of how the call reaches it= s destination. We also seem to agree that there is a certificate or public key that's boun= d by one (per country) or possibly more (if web) trusted entities to a numb= er and its assignees, in either "in-band" or "out-of-band" discussion. If we suppose a database (for Hadriel, DNS), that maps the number to an aut= horized database, the basic query is very similar: "hey, authorized databas= e, what's your public key/cert for this number" vs. "hey, authorized databa= se, where's your signed fragment".=20 In the latter case, the piece of data retrieved could be some version of th= e same signed block that would be attached to signaling ("in-band"), i.e., = a signed version of the (logical) From, To and Date. It could even look tex= tually like 4474(bis), if we wanted to. Thus, this seems more like a variat= ion of the transport mechanism than a fundamentally different model. In tha= t way, the non-SIP delivery can organically build on the SIP delivery to b= ypass non-IP hops. The database can well be operated by gateway providers, = i.e., just before the call leaves SIP land. In both cases, we have to solve the "find database for number/call" problem= , where we seem to have both explicit ("here's the URL in the header") and = implicit (DNS) models as proposals. Thus, maybe we can avoid the unproductive in-band/out-of-band distinction a= nd see if there's an overarching model that essentially starts with the sam= e identity-signing model, and considers three ways, in decreasing attachmen= t strength to the call: (1) cert is attached to the call, as a MIME multipart (as in 4474) (2) cert/PK is referenced via a URL or implicitly by number (again, similar= to 4474, plus the DNS-style proposals) (3) fragment is implicitly referenced, which in turn then uses (1) or (2) t= o get the cert/PK In the telephony space, we already have this model in CNAM, with multiple c= ompeting databases providing number-to-text lookup. The charter presumably wouldn't want to get into this level of detail, but = it may be sufficient to simply mention that both cert and call information = can be delivered in various ways. I have no objection to starting with the = simplest cases (#1 and #2), while keeping the larger picture in mind. This = avoids, I hope, the need to create two global infrastructures that Dave is = worried about. I also don't see the models as competing - we have had multiple signaling p= rotocols in telephony for decades, and, because the overall model is reason= ably uniform, this works well enough. This may be more of a problem of "The= (SIP) future is already here - it's just not very evenly distributed." On a separate note, I do see the attraction of a race - if (say) smartphone= users can block robocalls, but landline users are inundated with them, the= latter may well be incented to get with the program to keep their customer= s. -----Original Message----- From: Dave Crocker [mailto:dhc@dcrocker.net]=20 Sent: Monday, July 01, 2013 3:45 PM To: Richard Shockey Cc: 'Peterson, Jon'; 'Eric Rescorla'; 'DOLLY, MARTIN C'; stir@ietf.org; Hen= ning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band On 7/1/2013 12:33 PM, Richard Shockey wrote: > You're studying the right trends here, but I'm not sure you're=20 > correctly assessing their salience to the out-of-band proposal. Do we really want to keep discussing the out-of-band topic. The more we sp= end talking about it, a) the less we spend on the in-band one, and b) the m= ore it looks like we want to include it in the initial work. If the group wants to focus on a single, narrow deliverable as its initial = effort, it needs to focus on that signle, narrow deliverable... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hadriel.kaplan@oracle.com Mon Jul 1 23: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 E5DC511E826E for ; Mon, 1 Jul 2013 23:14:03 -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.126, 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 meq-5wBaPxDR for ; Mon, 1 Jul 2013 23:13:57 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 69CDC11E8289 for ; Mon, 1 Jul 2013 23:13:57 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r626DU2K023636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Jul 2013 06:13:32 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 r626DP63015518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Jul 2013 06:13:25 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 r626DPTs007426; Tue, 2 Jul 2013 06:13:25 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-182-249.vpn.oracle.com (/10.154.182.249) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Jul 2013 23:13: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: Date: Tue, 2 Jul 2013 02:13:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <520DE022-7E21-4B31-82E1-D332A2A94E63@oracle.com> References: <011501ce7676$79b756c0$6d260440$@shockey.us> <01bc01ce7691$e73f8bc0$b5bea340$@shockey.us> <51D1DC32.1080308@dcrocker.net> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: 'Eric Rescorla' , "'Peterson, Jon'" , "'DOLLY, MARTIN C'" , Richard Shockey , "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, 02 Jul 2013 06:14:04 -0000 On Jul 1, 2013, at 4:24 PM, Henning Schulzrinne = wrote: > We also seem to agree that there is a certificate or public key that's = bound by one (per country) or possibly more (if web) trusted entities to = a number and its assignees, in either "in-band" or "out-of-band" = discussion. >=20 > If we suppose a database (for Hadriel, DNS), that maps the number to = an authorized database, the basic query is very similar: "hey, = authorized database, what's your public key/cert for this number" vs. = "hey, authorized database, where's your signed fragment".=20 Are we talking about someday being on The Public DNS, or just for a = restricted-access one? Unfortunately for The Public DNS, an E.164 node in the DNS redirecting = to a specific carrier's database reveals that the E.164 belongs to the = carrier. Someday that might be ok, but not anytime soon. That's why the DNS idea only put a public-key in the E.164 node, with no = information identifying the carrier. -hadriel From Henning.Schulzrinne@fcc.gov Tue Jul 2 10:34: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 3B0C121F8FC4 for ; Tue, 2 Jul 2013 10:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.045 X-Spam-Level: X-Spam-Status: No, score=-1.045 tagged_above=-999 required=5 tests=[AWL=1.554, 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 eM9+KpNOk11Y for ; Tue, 2 Jul 2013 10:34:27 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id F1F9521F8F9E for ; Tue, 2 Jul 2013 10:34:26 -0700 (PDT) Message-ID: X-CheckPoint: {51D30F20-42-D2C987A5-FFFF} From: Henning Schulzrinne To: 'Hadriel Kaplan' Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObffB01fXrRHtXUWe5nyT4KMtCplA/mcAgARfFAD//9WzZYAARyoA///B17GAAQ/TgIAAYW+AgAA/UICAAAVDgIAABX+AgAF0k4CAAx4NgIAAB9CAgAAC/wCAABpmgIAAAXSAgAL2fjWAAEZUgP//wDsbAAoVkYD//73B+4AARjaAgAACS4CAAADvAIAAAy0AgAEeuYCAACxzAIAAJtEAgAAQCQCAAAMaAIAAQIdwgABvF4D//4YzQA== Date: Tue, 2 Jul 2013 17:34:23 +0000 References: <011501ce7676$79b756c0$6d260440$@shockey.us> <01bc01ce7691$e73f8bc0$b5bea340$@shockey.us> <51D1DC32.1080308@dcrocker.net> <520DE022-7E21-4B31-82E1-D332A2A94E63@oracle.com> In-Reply-To: <520DE022-7E21-4B31-82E1-D332A2A94E63@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: 'Eric Rescorla' , "'Peterson, Jon'" , "'DOLLY, MARTIN C'" , Richard Shockey , "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, 02 Jul 2013 17:34:32 -0000 This is probably an operational detail, but the database could well be oper= ated by a third party or multiple third parties, just like CNAM databases. = You could even have the same number appear in multiple databases, if additi= onal obscurity is desired. For reasons mentioned earlier by others, I suspect that this would be priva= te DNS (or servers) regardless of the number visibility issue, but that doe= sn't seem like something we need to prescribe. -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com]=20 Sent: Tuesday, July 02, 2013 2:13 AM To: Henning Schulzrinne Cc: 'dcrocker@bbiw.net'; Richard Shockey; stir@ietf.org; 'Eric Rescorla'; '= DOLLY, MARTIN C'; 'Peterson, Jon' Subject: Re: [stir] Out-of-band vs. in-band On Jul 1, 2013, at 4:24 PM, Henning Schulzrinne wrote: > We also seem to agree that there is a certificate or public key that's bo= und by one (per country) or possibly more (if web) trusted entities to a nu= mber and its assignees, in either "in-band" or "out-of-band" discussion. >=20 > If we suppose a database (for Hadriel, DNS), that maps the number to an a= uthorized database, the basic query is very similar: "hey, authorized datab= ase, what's your public key/cert for this number" vs. "hey, authorized data= base, where's your signed fragment".=20 Are we talking about someday being on The Public DNS, or just for a restric= ted-access one? Unfortunately for The Public DNS, an E.164 node in the DNS redirecting to a= specific carrier's database reveals that the E.164 belongs to the carrier.= Someday that might be ok, but not anytime soon. That's why the DNS idea only put a public-key in the E.164 node, with no in= formation identifying the carrier. -hadriel From timothy.dwight@verizon.com Tue Jul 2 10:44: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 B7A2F21F9935 for ; Tue, 2 Jul 2013 10:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, 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 sfkzmQEnf2B3 for ; Tue, 2 Jul 2013 10:44:34 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3E65D21F8D0D for ; Tue, 2 Jul 2013 10:44:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe01.verizon.com with ESMTP; 02 Jul 2013 17:44:26 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.87,982,1363132800"; d="scan'208";a="501544320" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi03.verizon.com with ESMTP; 02 Jul 2013 17:44:26 +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, 2 Jul 2013 13:44:20 -0400 To: Henning Schulzrinne , 'Hadriel Kaplan' Date: Tue, 2 Jul 2013 13:44:19 -0400 Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObffB01fXrRHtXUWe5nyT4KMtCplA/mcAgARfFAD//9WzZYAARyoA///B17GAAQ/TgIAAYW+AgAA/UICAAAVDgIAABX+AgAF0k4CAAx4NgIAAB9CAgAAC/wCAABpmgIAAAXSAgAL2fjWAAEZUgP//wDsbAAoVkYD//73B+4AARjaAgAACS4CAAADvAIAAAy0AgAEeuYCAACxzAIAAJtEAgAAQCQCAAAMaAIAAQIdwgABvF4D//4YzQP//CVtQ Message-ID: <2B0F677F0B95454297753F58D4A07FA30127F61718@FHDP1LUMXC7V31.us.one.verizon.com> References: <011501ce7676$79b756c0$6d260440$@shockey.us> <01bc01ce7691$e73f8bc0$b5bea340$@shockey.us> <51D1DC32.1080308@dcrocker.net> <520DE022-7E21-4B31-82E1-D332A2A94E63@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Eric Rescorla' , "'Peterson, Jon'" , "'DOLLY, MARTIN C'" , Richard Shockey , "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, 02 Jul 2013 17:44:39 -0000 Henning, Small clarification: (As I know you know) CNAM databases are not queried b= y the end user, they are queried by the terminating network. The end user = can neither query the CNAM database nor cause such a query to be performed = (other than through subscription in a service that includes calling party p= resentation). I agree that such a database could be operated by a 3rd part= y, but at least with respect to how and by whom it is accessed, it would be= different. Tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hen= ning Schulzrinne Sent: Tuesday, July 02, 2013 12:34 PM To: 'Hadriel Kaplan' Cc: 'Eric Rescorla'; 'Peterson, Jon'; 'DOLLY, MARTIN C'; Richard Shockey; s= tir@ietf.org; 'dcrocker@bbiw.net' Subject: Re: [stir] Out-of-band vs. in-band This is probably an operational detail, but the database could well be oper= ated by a third party or multiple third parties, just like CNAM databases. = You could even have the same number appear in multiple databases, if additi= onal obscurity is desired. For reasons mentioned earlier by others, I suspect that this would be priva= te DNS (or servers) regardless of the number visibility issue, but that doe= sn't seem like something we need to prescribe. -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com]=20 Sent: Tuesday, July 02, 2013 2:13 AM To: Henning Schulzrinne Cc: 'dcrocker@bbiw.net'; Richard Shockey; stir@ietf.org; 'Eric Rescorla'; '= DOLLY, MARTIN C'; 'Peterson, Jon' Subject: Re: [stir] Out-of-band vs. in-band On Jul 1, 2013, at 4:24 PM, Henning Schulzrinne wrote: > We also seem to agree that there is a certificate or public key that's bo= und by one (per country) or possibly more (if web) trusted entities to a nu= mber and its assignees, in either "in-band" or "out-of-band" discussion. >=20 > If we suppose a database (for Hadriel, DNS), that maps the number to an a= uthorized database, the basic query is very similar: "hey, authorized datab= ase, what's your public key/cert for this number" vs. "hey, authorized data= base, where's your signed fragment".=20 Are we talking about someday being on The Public DNS, or just for a restric= ted-access one? Unfortunately for The Public DNS, an E.164 node in the DNS redirecting to a= specific carrier's database reveals that the E.164 belongs to the carrier.= Someday that might be ok, but not anytime soon. That's why the DNS idea only put a public-key in the E.164 node, with no in= formation identifying the carrier. -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From Henning.Schulzrinne@fcc.gov Tue Jul 2 10:57: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 03DDC11E80D5 for ; Tue, 2 Jul 2013 10:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[AWL=1.413, 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 PxbVRkGCF3uA for ; Tue, 2 Jul 2013 10:57:31 -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 7FC3311E80AD for ; Tue, 2 Jul 2013 10:57:30 -0700 (PDT) Message-ID: X-CheckPoint: {51D31488-78-D2C987A5-1FFFF} From: Henning Schulzrinne To: "'Dwight, Timothy M (Tim)'" Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObffB01fXrRHtXUWe5nyT4KMtCplA/mcAgARfFAD//9WzZYAARyoA///B17GAAQ/TgIAAYW+AgAA/UICAAAVDgIAABX+AgAF0k4CAAx4NgIAAB9CAgAAC/wCAABpmgIAAAXSAgAL2fjWAAEZUgP//wDsbAAoVkYD//73B+4AARjaAgAACS4CAAADvAIAAAy0AgAEeuYCAACxzAIAAJtEAgAAQCQCAAAMaAIAAQIdwgABvF4D//4YzQP//CVtQ//4Q/BA= Date: Tue, 2 Jul 2013 17:57:28 +0000 References: <011501ce7676$79b756c0$6d260440$@shockey.us> <01bc01ce7691$e73f8bc0$b5bea340$@shockey.us> <51D1DC32.1080308@dcrocker.net> <520DE022-7E21-4B31-82E1-D332A2A94E63@oracle.com> <2B0F677F0B95454297753F58D4A07FA30127F61718@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA30127F61718@FHDP1LUMXC7V31.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] 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, 02 Jul 2013 17:57:38 -0000 Thanks for emphasizing this. The current CNAM-style model would indeed only= apply to validation by the terminating carrier, but the basic model of hav= ing multiple intermediaries that are not carriers offer database access ser= vices seems to be more general. (In the CNAM case, it's probably less a tec= hnical reason, but rather that their business model of dip charges doesn't = really work for consumer access. You could imagine various intermediary mod= els - the app vendor contracts with the database provider and pays for bulk= access based on their subscription or advertising revenue, for example.) Vaguely related: On the government side, we make numerous entity-related it= ems available to the public via HTTP APIs (see http://www.fcc.gov/developer= s). NPAC provides a number-related API for law enforcement (http://www.npac= .com/the-npac/access/law-enforcement-agencies-psaps). -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com]=20 Sent: Tuesday, July 02, 2013 1:44 PM To: Henning Schulzrinne; 'Hadriel Kaplan' Cc: 'Eric Rescorla'; 'Peterson, Jon'; 'DOLLY, MARTIN C'; Richard Shockey; s= tir@ietf.org; 'dcrocker@bbiw.net' Subject: RE: [stir] Out-of-band vs. in-band Henning, Small clarification: (As I know you know) CNAM databases are not queried b= y the end user, they are queried by the terminating network. The end user = can neither query the CNAM database nor cause such a query to be performed = (other than through subscription in a service that includes calling party p= resentation). I agree that such a database could be operated by a 3rd part= y, but at least with respect to how and by whom it is accessed, it would be= different. Tim From timothy.dwight@verizon.com Tue Jul 2 11:30: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 9F69821F9A7A for ; Tue, 2 Jul 2013 11:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 8keggvWekVyU for ; Tue, 2 Jul 2013 11:30:37 -0700 (PDT) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3B821F9829 for ; Tue, 2 Jul 2013 11:30:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by omzsmtpe03.verizonbusiness.com with ESMTP; 02 Jul 2013 18:30:34 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.87,982,1363132800"; d="scan'208";a="500667918" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi02.verizon.com with ESMTP; 02 Jul 2013 18:30:30 +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, 2 Jul 2013 14:30:30 -0400 To: Henning Schulzrinne Date: Tue, 2 Jul 2013 14:30:29 -0400 Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObffB01fXrRHtXUWe5nyT4KMtCplA/mcAgARfFAD//9WzZYAARyoA///B17GAAQ/TgIAAYW+AgAA/UICAAAVDgIAABX+AgAF0k4CAAx4NgIAAB9CAgAAC/wCAABpmgIAAAXSAgAL2fjWAAEZUgP//wDsbAAoVkYD//73B+4AARjaAgAACS4CAAADvAIAAAy0AgAEeuYCAACxzAIAAJtEAgAAQCQCAAAMaAIAAQIdwgABvF4D//4YzQP//CVtQ//4Q/BD//BZxoA== Message-ID: <2B0F677F0B95454297753F58D4A07FA30127F61785@FHDP1LUMXC7V31.us.one.verizon.com> References: <011501ce7676$79b756c0$6d260440$@shockey.us> <01bc01ce7691$e73f8bc0$b5bea340$@shockey.us> <51D1DC32.1080308@dcrocker.net> <520DE022-7E21-4B31-82E1-D332A2A94E63@oracle.com> <2B0F677F0B95454297753F58D4A07FA30127F61718@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] 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, 02 Jul 2013 18:30:42 -0000 Agreed. The abstraction of an API would let us resolve a number of issues,= e.g., privacy and security of the underlying databases. tim=20 -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Tuesday, July 02, 2013 12:57 PM To: Dwight, Timothy M (Tim) Cc: stir@ietf.org Subject: RE: [stir] Out-of-band vs. in-band Thanks for emphasizing this. The current CNAM-style model would indeed only= apply to validation by the terminating carrier, but the basic model of hav= ing multiple intermediaries that are not carriers offer database access ser= vices seems to be more general. (In the CNAM case, it's probably less a tec= hnical reason, but rather that their business model of dip charges doesn't = really work for consumer access. You could imagine various intermediary mod= els - the app vendor contracts with the database provider and pays for bulk= access based on their subscription or advertising revenue, for example.) Vaguely related: On the government side, we make numerous entity-related it= ems available to the public via HTTP APIs (see http://www.fcc.gov/developer= s). NPAC provides a number-related API for law enforcement (http://www.npac= .com/the-npac/access/law-enforcement-agencies-psaps). -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com]=20 Sent: Tuesday, July 02, 2013 1:44 PM To: Henning Schulzrinne; 'Hadriel Kaplan' Cc: 'Eric Rescorla'; 'Peterson, Jon'; 'DOLLY, MARTIN C'; Richard Shockey; s= tir@ietf.org; 'dcrocker@bbiw.net' Subject: RE: [stir] Out-of-band vs. in-band Henning, Small clarification: (As I know you know) CNAM databases are not queried b= y the end user, they are queried by the terminating network. The end user = can neither query the CNAM database nor cause such a query to be performed = (other than through subscription in a service that includes calling party p= resentation). I agree that such a database could be operated by a 3rd part= y, but at least with respect to how and by whom it is accessed, it would be= different. Tim From hadriel.kaplan@oracle.com Tue Jul 2 15:13:51 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCA611E8107 for ; Tue, 2 Jul 2013 15:13: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 Suw+BDGm7Am4 for ; Tue, 2 Jul 2013 15:13:44 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id AD3B521F9829 for ; Tue, 2 Jul 2013 15:13: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 r62MDf2G014294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Jul 2013 22:13:42 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 r62MDek8020363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Jul 2013 22:13:41 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 r62MDekT003723; Tue, 2 Jul 2013 22:13:40 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Jul 2013 15:13: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: Date: Tue, 2 Jul 2013 18:13:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <011501ce7676$79b756c0$6d260440$@shockey.us> <01bc01ce7691$e73f8bc0$b5bea340$@shockey.us> <51D1DC32.1080308@dcrocker.net> <520DE022-7E21-4B31-82E1-D332A2A94E63@oracle.com> <2B0F677F0B95454297753F58D4A07FA30127F61718@FHDP1LUMXC7V31.us.one.verizon.com> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "stir@ietf.org" , "'Dwight, Timothy M \(Tim\)'" 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, 02 Jul 2013 22:13:51 -0000 I'm not in the business of providing smart-phone apps, but ISTM most of = the successful ones are free. They're often provided for free by the = company that provides the "database" or service (for lack of a better = term to describe the stuff on the Internet-side). The actual money = comes from other sources. In this caller-id verification case, I would assume the money for such a = "database" service either comes from callers who would be willing to pay = (e.g., banks, airlines, etc.), or from the carriers. So why would the "database" service even *want* a standard to follow? = They'll make the app themselves and give it out for free, and they'll = decide how the app gets its info and what features it needs to have and = so on. They'll likely want to provide far more than a simple caller-id. = For example they would want to provide a calling name, website, email = address, and other contact-card info; maybe even a picture or brand = logo/icon. We don't know what they'd want, and such a company wouldn't = want to wait for a standard to tell them what/how. Standards are only necessary and useful if more than one = manufacturer/service/vendor needs and wants to interoperate with = another. So unless you get multiple of these database providers to = participate in the IETF, and tell us what they want and how they want = it, I don't see the point of repeating the ATOCA working group in STIR. -hadriel On Jul 2, 2013, at 1:57 PM, Henning Schulzrinne = wrote: > Thanks for emphasizing this. The current CNAM-style model would indeed = only apply to validation by the terminating carrier, but the basic model = of having multiple intermediaries that are not carriers offer database = access services seems to be more general. (In the CNAM case, it's = probably less a technical reason, but rather that their business model = of dip charges doesn't really work for consumer access. You could = imagine various intermediary models - the app vendor contracts with the = database provider and pays for bulk access based on their subscription = or advertising revenue, for example.) From br@brianrosen.net Wed Jul 3 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 BEB4E11E80D9 for ; Wed, 3 Jul 2013 06:50:34 -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 nX6dNZj4Mpwh for ; Wed, 3 Jul 2013 06:50:29 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 5232F11E8145 for ; Wed, 3 Jul 2013 06:50:23 -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=7gou3pHctORY2gIoauEIDBLm4lHC9qe17zbiV6zCrcA=; b=E79Gwvnl4FDvshEvYePTmvRYE9E541x6eZMxJjsxTo/p9Mmwl0XtyfYeGVmfCJjn5kKvLKex7gnyK5W+anNysTdnUlm7NaAtNGbv0m0Vvg3RZre5nvmnprrAcMOjzMy7Lh2U4NFNB4Jf1LRTIXnEOyhwGeRrJPDQtGhP4wuKxkw=; Received: from neustargw.va.neustar.com ([209.173.53.233]:49493 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UuNRt-0005vI-VH; Wed, 03 Jul 2013 09:50:22 -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: <51CE17A6.2090605@dcrocker.net> Date: Wed, 3 Jul 2013 09:50:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> References: <51CE17A6.2090605@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: "fluffy@cisco.com" , Michael Hammer , "hadriel.kaplan@oracle.com" , "Peterson, Jon" , "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: Wed, 03 Jul 2013 13:50:36 -0000 Catching up (I was out for a week) On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: > 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.) e.164s are much more constrained than the email address issues DKIM has = to deal with. We could have challenges with local dial plans, and we've = been discussing those issues, but the easy way out on those is that they = may not be covered if both ends don't understand the dial plan the same = way. So far, while we have one issue I'm concerned with (verifier not being = able to extract a canonical e.164 from the content of "From"), I don't = think the DKIM experience is particularly relevant. Brian From timothy.dwight@verizon.com Wed Jul 3 06:54: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 6D70321F9A16 for ; Wed, 3 Jul 2013 06:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 E9YyXeuQ+pHA for ; Wed, 3 Jul 2013 06:54:23 -0700 (PDT) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) by ietfa.amsl.com (Postfix) with ESMTP id DBB4421F9ABC for ; Wed, 3 Jul 2013 06:54:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by omzsmtpe03.verizonbusiness.com with ESMTP; 03 Jul 2013 13:54:21 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.87,988,1363132800"; d="scan'208";a="501206123" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi02.verizon.com with ESMTP; 03 Jul 2013 13:54:19 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Wed, 3 Jul 2013 09:54:07 -0400 To: Hadriel Kaplan , Henning Schulzrinne Date: Wed, 3 Jul 2013 09:54:04 -0400 Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: Ac53cXImyfl7X8sAQSmsW2NDlT0RgwAfOwCw Message-ID: <2B0F677F0B95454297753F58D4A07FA30127F61B26@FHDP1LUMXC7V31.us.one.verizon.com> References: <011501ce7676$79b756c0$6d260440$@shockey.us> <01bc01ce7691$e73f8bc0$b5bea340$@shockey.us> <51D1DC32.1080308@dcrocker.net> <520DE022-7E21-4B31-82E1-D332A2A94E63@oracle.com> <2B0F677F0B95454297753F58D4A07FA30127F61718@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] 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, 03 Jul 2013 13:54:28 -0000 Hadriel, I thought there was from the outset some notion that compliance would be ma= de compulsory (by regulators). I assume that's part of what motivates stan= dardization. I'm not sure the invocation of this functionality has to be in an "app", by= the way. ISTM it could also be provided by the device OEM as part of the = standard dialer. The latter is more easily achieved if the API is standard= ized. Both options may be viable of course. For example some OEMs might provide = this functionality in some smart phones, whereas users of older phones migh= t need to download the functionality in the form of an app. I do agree that it would be difficult at this stage to standardize a "fancy= " app, that provided the type of additional information about the caller yo= u list below. IMHO if we attempt to standardize any API it should be a "mi= nimalist" one that only supports calling party verification. This would no= t of course preclude 3rd parties from wrapping that API in one of their own= and augmenting the information provided to the user. tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Had= riel Kaplan Sent: Tuesday, July 02, 2013 5:14 PM To: Henning Schulzrinne Cc: stir@ietf.org; Dwight, Timothy M (Tim) Subject: Re: [stir] Out-of-band vs. in-band I'm not in the business of providing smart-phone apps, but ISTM most of the= successful ones are free. They're often provided for free by the company = that provides the "database" or service (for lack of a better term to descr= ibe the stuff on the Internet-side). The actual money comes from other sou= rces. In this caller-id verification case, I would assume the money for such a "d= atabase" service either comes from callers who would be willing to pay (e.g= ., banks, airlines, etc.), or from the carriers. So why would the "database" service even *want* a standard to follow? They= 'll make the app themselves and give it out for free, and they'll decide ho= w the app gets its info and what features it needs to have and so on. They= 'll likely want to provide far more than a simple caller-id. For example t= hey would want to provide a calling name, website, email address, and other= contact-card info; maybe even a picture or brand logo/icon. We don't know= what they'd want, and such a company wouldn't want to wait for a standard = to tell them what/how. Standards are only necessary and useful if more than one manufacturer/servi= ce/vendor needs and wants to interoperate with another. So unless you get = multiple of these database providers to participate in the IETF, and tell u= s what they want and how they want it, I don't see the point of repeating t= he ATOCA working group in STIR. -hadriel On Jul 2, 2013, at 1:57 PM, Henning Schulzrinne wrote: > Thanks for emphasizing this. The current CNAM-style model would indeed on= ly apply to validation by the terminating carrier, but the basic model of h= aving multiple intermediaries that are not carriers offer database access s= ervices seems to be more general. (In the CNAM case, it's probably less a t= echnical reason, but rather that their business model of dip charges doesn'= t really work for consumer access. You could imagine various intermediary m= odels - the app vendor contracts with the database provider and pays for bu= lk access based on their subscription or advertising revenue, for example.) _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From dhc@dcrocker.net Wed Jul 3 07:10: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 C531D21F99DB for ; Wed, 3 Jul 2013 07:10: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=[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 GQWOC-j5ns1g for ; Wed, 3 Jul 2013 07:10:40 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDE521F8493 for ; Wed, 3 Jul 2013 07:10:36 -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 r63EAVEp025448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Jul 2013 07:10:35 -0700 Message-ID: <51D430CA.2030300@dcrocker.net> Date: Wed, 03 Jul 2013 07:10:18 -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: Brian Rosen References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> In-Reply-To: <622DD31F-896F-4352-B811-7AFA0083758D@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]); Wed, 03 Jul 2013 07:10:35 -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: Wed, 03 Jul 2013 14:10:45 -0000 On 7/3/2013 6:50 AM, Brian Rosen wrote: > Catching up (I was out for a week) > On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: > >> 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.) > e.164s are much more constrained than the email address issues DKIM has to deal with. We could have challenges with local dial plans, and we've been discussing those issues, but the easy way out on those is that they may not be covered if both ends don't understand the dial plan the same way. > > So far, while we have one issue I'm concerned with (verifier not being able to extract a canonical e.164 from the content of "From"), I don't think the DKIM experience is particularly relevant. Brian, Thanks. Good to hear. I assume there is a document that specifies all of the variations that will be encountered and how to deterministically and successfully transform them into the single, canonical representation? Absent that, this topic remains a likely source of non-interoperability. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From br@brianrosen.net Wed Jul 3 07:23: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 2860C21F9C1E for ; Wed, 3 Jul 2013 07:23:05 -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 1FAkRbrkqaxV for ; Wed, 3 Jul 2013 07:23:00 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 7C44521F9CD7 for ; Wed, 3 Jul 2013 07:23: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=is8n0DnwZnwtIN3VKKLY97vg8HiHm5FwCN3IDuAs1JA=; b=LHg9SsYe3npT0hMqY3QPaxbPhF4SG0UjQsALr+viKAa8AdID8yuCm8pq5Jivuj2chH9qgd6h/tpLPrRZWhhIQ2jpNoFqYBw77Iqa49vGdVrBvr7YVgoDEUngEDVy+mJiL23f5AIt1fUiMQ6VQziHBgNEMbhjJGAS/60kyoUy6SM=; Received: from neustargw.va.neustar.com ([209.173.53.233]:53269 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UuNxT-0004Rx-Qy; Wed, 03 Jul 2013 10:22:59 -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: <51D430CA.2030300@dcrocker.net> Date: Wed, 3 Jul 2013 10:22:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@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" 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: Wed, 03 Jul 2013 14:23:05 -0000 There are a lot of local variations out there, but they all have the = property that in order to route them, you need to be able to figure out = at least the "left" part of the e.164 is, and the right part has to pass = unscathed in order to work. Since everyone, and I mean everyone, = dealing with these systems knows what e.164s are, and how they work, I = don't think it's necessary, or even possible to describe all of the = various ways the strings might appear and what to do with them. All we need say is that in order to work, the header contents has to be = able to have the canonical e.164 extracted with no knowledge at the = validator, and validations can occur anywhere in the call path. We'll = dress up that text a lot I am sure, but the notion that we could write, = or need a document describing all possible variations of how telephone = numbers may appear and how to extract the e.164 in each of them seems to = me to be silly. It may be possible to specify an algorithm however. Brian On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: > On 7/3/2013 6:50 AM, Brian Rosen wrote: >> Catching up (I was out for a week) >> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>=20 >>> 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.) >> e.164s are much more constrained than the email address issues DKIM = has to deal with. We could have challenges with local dial plans, and = we've been discussing those issues, but the easy way out on those is = that they may not be covered if both ends don't understand the dial plan = the same way. >>=20 >> So far, while we have one issue I'm concerned with (verifier not = being able to extract a canonical e.164 from the content of "From"), I = don't think the DKIM experience is particularly relevant. >=20 >=20 > Brian, >=20 > Thanks. Good to hear. >=20 > I assume there is a document that specifies all of the variations that = will be encountered and how to deterministically and successfully = transform them into the single, canonical representation? >=20 > Absent that, this topic remains a likely source of = non-interoperability. >=20 > d/ >=20 >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net From timothy.dwight@verizon.com Wed Jul 3 07:39:11 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEDB21F9C89 for ; Wed, 3 Jul 2013 07:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Bo+IhHWol4ap for ; Wed, 3 Jul 2013 07:39:06 -0700 (PDT) Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9A821F9C86 for ; Wed, 3 Jul 2013 07:39:05 -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; 03 Jul 2013 14:39:04 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.87,988,1363132800"; d="scan'208";a="501254106" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi02.verizon.com with ESMTP; 03 Jul 2013 14:39:03 +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, 3 Jul 2013 10:39:03 -0400 To: Brian Rosen , "dcrocker@bbiw.net" Date: Wed, 3 Jul 2013 10:39:01 -0400 Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: Ac53+QlsH5oHR+hsRJyUrLugVTktgQAAEBHQ Message-ID: <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] 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: Wed, 03 Jul 2013 14:39:11 -0000 Could someone provide a few examples? I have to say I find this thread har= d to follow. I trust the individuals making the arguments to be knowledgea= ble and honest, but personally I have little experience with this "FROM hea= der manipulation" that I'm told is so rampant. =20 The only example I can think of is the "SIP trunking" use case I raised pre= viously (user part of URI in FROM and/or TO header may be significant only = within the dial plan of the associated Enterprise) which was ruled out of s= cope for this activity. So I'm puzzled, what use cases there are that (a) = are in scope for this exercise, and (b) involve manipulation of the user pa= rt of the URI in the FROM header. Apologies in advance if this is obvious to everyone else and I'm the only o= ne who doesn't "get it". Thanks, Tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Bri= an Rosen Sent: Wednesday, July 03, 2013 9:23 AM To: dcrocker@bbiw.net Cc: stir@ietf.org Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) There are a lot of local variations out there, but they all have the proper= ty that in order to route them, you need to be able to figure out at least = the "left" part of the e.164 is, and the right part has to pass unscathed i= n order to work. Since everyone, and I mean everyone, dealing with these s= ystems knows what e.164s are, and how they work, I don't think it's necessa= ry, or even possible to describe all of the various ways the strings might = appear and what to do with them. All we need say is that in order to work, the header contents has to be abl= e to have the canonical e.164 extracted with no knowledge at the validator,= and validations can occur anywhere in the call path. We'll dress up that = text a lot I am sure, but the notion that we could write, or need a documen= t describing all possible variations of how telephone numbers may appear an= d how to extract the e.164 in each of them seems to me to be silly. It may be possible to specify an algorithm however. Brian On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: > On 7/3/2013 6:50 AM, Brian Rosen wrote: >> Catching up (I was out for a week) >> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>=20 >>> The experience with canonicalization algorithms for DKIM -- and it, too= , had to deal with in-transit modifications -- makes clear that it's a topi= c with challenges and compromises. (Hmmm. "compromises" might be a pun, h= ere.) >> e.164s are much more constrained than the email address issues DKIM has = to deal with. We could have challenges with local dial plans, and we've be= en discussing those issues, but the easy way out on those is that they may = not be covered if both ends don't understand the dial plan the same way. >>=20 >> So far, while we have one issue I'm concerned with (verifier not being a= ble to extract a canonical e.164 from the content of "From"), I don't think= the DKIM experience is particularly relevant. >=20 >=20 > Brian, >=20 > Thanks. Good to hear. >=20 > I assume there is a document that specifies all of the variations that wi= ll be encountered and how to deterministically and successfully transform t= hem into the single, canonical representation? >=20 > Absent that, this topic remains a likely source of non-interoperability. >=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 oej@edvina.net Wed Jul 3 07:44:48 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE92421F9AEC for ; Wed, 3 Jul 2013 07:44:48 -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 f6rN-bJsqJAm for ; Wed, 3 Jul 2013 07:44:48 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 57A7611E817E for ; Wed, 3 Jul 2013 07:44:46 -0700 (PDT) Received: from [192.168.40.15] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 0074793C2A1; Wed, 3 Jul 2013 14:44:44 +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: <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> Date: Wed, 3 Jul 2013 16:44:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <43DFEF36-0A7F-410E-A0A9-854A42BF82C1@edvina.net> References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> To: "Dwight, Timothy M \(Tim\)" X-Mailer: Apple Mail (2.1508) Cc: "stir@ietf.org" , "Olle E. Johansson" , "dcrocker@bbiw.net" , Brian Rosen 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: Wed, 03 Jul 2013 14:44:49 -0000 3 jul 2013 kl. 16:39 skrev "Dwight, Timothy M \(Tim\)" = : > Could someone provide a few examples? I have to say I find this = thread hard to follow. I trust the individuals making the arguments to = be knowledgeable and honest, but personally I have little experience = with this "FROM header manipulation" that I'm told is so rampant. =20 >=20 > The only example I can think of is the "SIP trunking" use case I = raised previously (user part of URI in FROM and/or TO header may be = significant only within the dial plan of the associated Enterprise) = which was ruled out of scope for this activity. So I'm puzzled, what = use cases there are that (a) are in scope for this exercise, and (b) = involve manipulation of the user part of the URI in the FROM header. >=20 > Apologies in advance if this is obvious to everyone else and I'm the = only one who doesn't "get it". RFC 3966 on the Tel URI got some good reading. http://tools.ietf.org/html/rfc3966#section-5.1.4 Think of it as "anything that starts with a country code". In every = platform I have installed, we have those algorithms. /O >=20 > Thanks, >=20 > Tim >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Brian Rosen > Sent: Wednesday, July 03, 2013 9:23 AM > To: dcrocker@bbiw.net > Cc: stir@ietf.org > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for = STIR) >=20 > There are a lot of local variations out there, but they all have the = property that in order to route them, you need to be able to figure out = at least the "left" part of the e.164 is, and the right part has to pass = unscathed in order to work. Since everyone, and I mean everyone, = dealing with these systems knows what e.164s are, and how they work, I = don't think it's necessary, or even possible to describe all of the = various ways the strings might appear and what to do with them. >=20 > All we need say is that in order to work, the header contents has to = be able to have the canonical e.164 extracted with no knowledge at the = validator, and validations can occur anywhere in the call path. We'll = dress up that text a lot I am sure, but the notion that we could write, = or need a document describing all possible variations of how telephone = numbers may appear and how to extract the e.164 in each of them seems to = me to be silly. >=20 > It may be possible to specify an algorithm however. >=20 > Brian >=20 > On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >=20 >> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>> Catching up (I was out for a week) >>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>=20 >>>> 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.) >>> e.164s are much more constrained than the email address issues DKIM = has to deal with. We could have challenges with local dial plans, and = we've been discussing those issues, but the easy way out on those is = that they may not be covered if both ends don't understand the dial plan = the same way. >>>=20 >>> So far, while we have one issue I'm concerned with (verifier not = being able to extract a canonical e.164 from the content of "From"), I = don't think the DKIM experience is particularly relevant. >>=20 >>=20 >> Brian, >>=20 >> Thanks. Good to hear. >>=20 >> I assume there is a document that specifies all of the variations = that will be encountered and how to deterministically and successfully = transform them into the single, canonical representation? >>=20 >> Absent that, this topic remains a likely source of = non-interoperability. >>=20 >> d/ >>=20 >>=20 >> --=20 >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From br@brianrosen.net Wed Jul 3 07:54: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 3309A11E81CF for ; Wed, 3 Jul 2013 07:54:55 -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 myv0Jzjv9BnD for ; Wed, 3 Jul 2013 07:54:51 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id C07B511E81C8 for ; Wed, 3 Jul 2013 07:54:50 -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=nuJwLDFyzVULmJJA5mST2zJ/EpIXBqP/CtQIIwxboWY=; b=aNsvDbq5nSr7/UWHFDDmbci6JcfbVnqVPMSmQkLtJ+kSW9P2uLz7Ty9GJZhUqMuei4vNvhEKEFHY0lpyK7qv1ajKipLAlZOopHVwE5r+8BnRKJycBm/QHBMfuljGv7QAuiPnnaZfRslEozoo1Zlx0evpNNXBOxStAH9B4i9Dyuk=; Received: from neustargw.va.neustar.com ([209.173.53.233]:52644 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UuOSH-0003SR-IC; Wed, 03 Jul 2013 10:54:49 -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: <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> Date: Wed, 3 Jul 2013 10:54:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@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" , "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: Wed, 03 Jul 2013 14:54:55 -0000 The =46rom problem is lack of country codes, and maybe worse. Consider = these possible From: contents=20 5551212 2025551212 12025551212 +12025551212 and of course all the variations with parens, spaces, hyphens, commas, = periods, etc. Although the first is getting really rare, I think it still happens The problem with these is when they appear in =46rom on an international = call - the first 2 are the real problems. They would have to be = rewritten. With To:, you get the variations with dial 9/8/... in enterprise = systems, and the 011 style prefix=20 Brian On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" = wrote: > Could someone provide a few examples? I have to say I find this = thread hard to follow. I trust the individuals making the arguments to = be knowledgeable and honest, but personally I have little experience = with this "FROM header manipulation" that I'm told is so rampant. =20 >=20 > The only example I can think of is the "SIP trunking" use case I = raised previously (user part of URI in FROM and/or TO header may be = significant only within the dial plan of the associated Enterprise) = which was ruled out of scope for this activity. So I'm puzzled, what = use cases there are that (a) are in scope for this exercise, and (b) = involve manipulation of the user part of the URI in the FROM header. >=20 > Apologies in advance if this is obvious to everyone else and I'm the = only one who doesn't "get it". >=20 > Thanks, >=20 > Tim >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Brian Rosen > Sent: Wednesday, July 03, 2013 9:23 AM > To: dcrocker@bbiw.net > Cc: stir@ietf.org > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for = STIR) >=20 > There are a lot of local variations out there, but they all have the = property that in order to route them, you need to be able to figure out = at least the "left" part of the e.164 is, and the right part has to pass = unscathed in order to work. Since everyone, and I mean everyone, = dealing with these systems knows what e.164s are, and how they work, I = don't think it's necessary, or even possible to describe all of the = various ways the strings might appear and what to do with them. >=20 > All we need say is that in order to work, the header contents has to = be able to have the canonical e.164 extracted with no knowledge at the = validator, and validations can occur anywhere in the call path. We'll = dress up that text a lot I am sure, but the notion that we could write, = or need a document describing all possible variations of how telephone = numbers may appear and how to extract the e.164 in each of them seems to = me to be silly. >=20 > It may be possible to specify an algorithm however. >=20 > Brian >=20 > On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >=20 >> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>> Catching up (I was out for a week) >>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>=20 >>>> 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.) >>> e.164s are much more constrained than the email address issues DKIM = has to deal with. We could have challenges with local dial plans, and = we've been discussing those issues, but the easy way out on those is = that they may not be covered if both ends don't understand the dial plan = the same way. >>>=20 >>> So far, while we have one issue I'm concerned with (verifier not = being able to extract a canonical e.164 from the content of "From"), I = don't think the DKIM experience is particularly relevant. >>=20 >>=20 >> Brian, >>=20 >> Thanks. Good to hear. >>=20 >> I assume there is a document that specifies all of the variations = that will be encountered and how to deterministically and successfully = transform them into the single, canonical representation? >>=20 >> Absent that, this topic remains a likely source of = non-interoperability. >>=20 >> d/ >>=20 >>=20 >> --=20 >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From york@isoc.org Wed Jul 3 07:58: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 CAD0C11E81C4 for ; Wed, 3 Jul 2013 07:58:19 -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 DLScGtMISbHh for ; Wed, 3 Jul 2013 07:58:15 -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 9D86011E81B4 for ; Wed, 3 Jul 2013 07:58:15 -0700 (PDT) Received: from BLUPR06MB067.namprd06.prod.outlook.com (10.242.187.146) by BLUPR06MB067.namprd06.prod.outlook.com (10.242.187.146) with Microsoft SMTP Server (TLS) id 15.0.702.21; Wed, 3 Jul 2013 14:58:14 +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, 3 Jul 2013 14:58:14 +0000 From: Dan York To: "Dwight, Timothy M (Tim)" , Brian Rosen , "dcrocker@bbiw.net" Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qYL+LLrStPTUyYM8Bezww2T5lLRiwAgAArZACAAAM/gIAAC30AgABB8ACABz9yAIAABZQAgAADigCAAAR8gP//wk4A Date: Wed, 3 Jul 2013 14:58:14 +0000 Message-ID: In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3012801EBF3@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.255.101.4] x-forefront-prvs: 0896BFCE6C x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(377454003)(479174003)(199002)(24454002)(76786001)(53806001)(81542001)(46102001)(15202345003)(47736001)(50986001)(74706001)(76482001)(79102001)(47976001)(74662001)(59766001)(76796001)(74366001)(31966008)(47446002)(56816003)(83072001)(56776001)(16406001)(81342001)(69226001)(49866001)(54316002)(77096001)(77982001)(65816001)(63696002)(74876001)(54356001)(4396001)(36756003)(76176001)(74502001)(51856001)(80022001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB067; 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: "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: Wed, 03 Jul 2013 14:58:19 -0000 Tim, On 7/3/13 10:39 AM, "Dwight, Timothy M (Tim)" wrote: >Could someone provide a few examples? I have to say I find this thread >hard to follow. I trust the individuals making the arguments to be >knowledgeable and honest, but personally I have little experience with >this "FROM header manipulation" that I'm told is so rampant. Hadriel wrote up a draft on this a few years back that identifies a couple of instances where this occurs: http://tools.ietf.org/html/draft-kaplan-sip-uris-change-00 He wrote that up back in 2008 when we were having an earlier debate about how we could improve RFC 4474. Dan From philippe.fouquart@orange.com Wed Jul 3 08:08: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 86E0411E81CB for ; Wed, 3 Jul 2013 08:08:13 -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 8zRA8Pe5TW5q for ; Wed, 3 Jul 2013 08:08:09 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3098611E81D3 for ; Wed, 3 Jul 2013 08:08:09 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id F08EE22D08F; Wed, 3 Jul 2013 17:08:07 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id C4CC64C056; Wed, 3 Jul 2013 17:08:07 +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, 3 Jul 2013 17:08:07 +0200 From: To: Brian Rosen , "Dwight, Timothy M (Tim)" Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qYQbRBguG1BUWXYgpbqGpqHZlLJKUAgAArZACAAAM/gIAAC30AgABB8ACABz9yAIAABZQAgAADigCAAAR8gIAABGkAgAAj5tA= Date: Wed, 3 Jul 2013 15:08:07 +0000 Message-ID: <6435_1372864087_51D43E57_6435_5254_8_B5939C6860701C49AA39C5DA5189448B0B2905@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@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.7.3.132720 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: Wed, 03 Jul 2013 15:08:17 -0000 I agree, I'm not sure I would go as far as calling the idea of defining all= possible variations "silly" but if, as I understand it, the idea was (at l= east) to come up with an algorithm/mapping to describe how a CLI expressed = in the dialing plan (or the national portion of the E.164 number) can be co= nverted into a full E.164 form for example, I think this would indeed be ov= erly ambitious.=20 For example, I regularly deal with a public dialling plan that requires abo= ut 20 if/then/else clauses on the value of the national Subscriber Number t= o do just that. And that's only for one (arguably quite complex yet closed)= national dialling plan. There are more than 200 of these on the planet, ea= ch of which potentially has its own national variations and change over tim= e. 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 Bri= an Rosen Sent: Wednesday, July 03, 2013 4:55 PM To: Dwight, Timothy M (Tim) Cc: stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) The From problem is lack of country codes, and maybe worse. Consider these= possible From: contents=20 5551212 2025551212 12025551212 +12025551212 and of course all the variations with parens, spaces, hyphens, commas, peri= ods, etc. Although the first is getting really rare, I think it still happens The problem with these is when they appear in From on an international call= - the first 2 are the real problems. They would have to be rewritten. With To:, you get the variations with dial 9/8/... in enterprise systems, a= nd the 011 style prefix=20 Brian On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" wrote: > Could someone provide a few examples? I have to say I find this thread h= ard to follow. I trust the individuals making the arguments to be knowledg= eable and honest, but personally I have little experience with this "FROM h= eader manipulation" that I'm told is so rampant.=20=20 >=20 > The only example I can think of is the "SIP trunking" use case I raised p= reviously (user part of URI in FROM and/or TO header may be significant onl= y within the dial plan of the associated Enterprise) which was ruled out of= scope for this activity. So I'm puzzled, what use cases there are that (a= ) are in scope for this exercise, and (b) involve manipulation of the user = part of the URI in the FROM header. >=20 > Apologies in advance if this is obvious to everyone else and I'm the only= one who doesn't "get it". >=20 > Thanks, >=20 > Tim >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of B= rian Rosen > Sent: Wednesday, July 03, 2013 9:23 AM > To: dcrocker@bbiw.net > Cc: stir@ietf.org > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) >=20 > There are a lot of local variations out there, but they all have the prop= erty that in order to route them, you need to be able to figure out at leas= t the "left" part of the e.164 is, and the right part has to pass unscathed= in order to work. Since everyone, and I mean everyone, dealing with these= systems knows what e.164s are, and how they work, I don't think it's neces= sary, or even possible to describe all of the various ways the strings migh= t appear and what to do with them. >=20 > All we need say is that in order to work, the header contents has to be a= ble to have the canonical e.164 extracted with no knowledge at the validato= r, and validations can occur anywhere in the call path. We'll dress up tha= t text a lot I am sure, but the notion that we could write, or need a docum= ent describing all possible variations of how telephone numbers may appear = and how to extract the e.164 in each of them seems to me to be silly. >=20 > It may be possible to specify an algorithm however. >=20 > Brian >=20 > On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >=20 >> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>> Catching up (I was out for a week) >>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>=20 >>>> The experience with canonicalization algorithms for DKIM -- and it, to= o, had to deal with in-transit modifications -- makes clear that it's a top= ic with challenges and compromises. (Hmmm. "compromises" might be a pun, = here.) >>> e.164s are much more constrained than the email address issues DKIM has= to deal with. We could have challenges with local dial plans, and we've b= een discussing those issues, but the easy way out on those is that they may= not be covered if both ends don't understand the dial plan the same way. >>>=20 >>> So far, while we have one issue I'm concerned with (verifier not being = able to extract a canonical e.164 from the content of "From"), I don't thin= k the DKIM experience is particularly relevant. >>=20 >>=20 >> Brian, >>=20 >> Thanks. Good to hear. >>=20 >> I assume there is a document that specifies all of the variations that w= ill be encountered and how to deterministically and successfully transform = them into the single, canonical representation? >>=20 >> Absent that, this topic remains a likely source of non-interoperability. >>=20 >> d/ >>=20 >>=20 >> --=20 >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ___________________________________________________________________________= ______________________________________________ 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 michael.hammer@yaanatech.com Wed Jul 3 08:13: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 C705F11E81BA for ; Wed, 3 Jul 2013 08:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.317, 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 G1IobudwXBNF for ; Wed, 3 Jul 2013 08:13: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 B83F511E81B4 for ; Wed, 3 Jul 2013 08:13:41 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Wed, 3 Jul 2013 08:13:41 -0700 From: Michael Hammer To: "br@brianrosen.net" , "timothy.dwight@verizon.com" Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qWRsjPKQFYKEy7+8dmUhlONZlLu4UAgAArZAD//42y0IAAgQkAgABB8ACABz9zAIAABZQAgAADigCAAAR8gIAABGkA//+NhfA= Date: Wed, 3 Jul 2013 15:13:40 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.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.96] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0082_01CE77DE.5EEBF490" 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: Wed, 03 Jul 2013 15:13:45 -0000 ------=_NextPart_000_0082_01CE77DE.5EEBF490 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit All, It helps to read E.164. It is a string of digits, max 15, no other characters, with CC, NDC, and SN. (There are variations on the names for those parts, but the concept is the same.) If you provide a specification that unambiguously delimits that, you are golden. Do not inject confusion by introducing dialing sting prefixes. Do not inject confusion by introducing trunking indicators. Do not inject confusion by introducing methods to group digits. If you want the phone number to get anywhere globally, you need to know how to generate the E.164. Any domain worth its salt knows how to go from a local representation to a canonical one. (And there are local representation secret sauce folks who know how to do that.) Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Wednesday, July 03, 2013 10:55 AM To: Dwight, Timothy M (Tim) Cc: stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) The From problem is lack of country codes, and maybe worse. Consider these possible From: contents 5551212 2025551212 12025551212 +12025551212 and of course all the variations with parens, spaces, hyphens, commas, periods, etc. Although the first is getting really rare, I think it still happens The problem with these is when they appear in From on an international call - the first 2 are the real problems. They would have to be rewritten. With To:, you get the variations with dial 9/8/... in enterprise systems, and the 011 style prefix Brian On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" wrote: > Could someone provide a few examples? I have to say I find this thread hard to follow. I trust the individuals making the arguments to be knowledgeable and honest, but personally I have little experience with this "FROM header manipulation" that I'm told is so rampant. > > The only example I can think of is the "SIP trunking" use case I raised previously (user part of URI in FROM and/or TO header may be significant only within the dial plan of the associated Enterprise) which was ruled out of scope for this activity. So I'm puzzled, what use cases there are that (a) are in scope for this exercise, and (b) involve manipulation of the user part of the URI in the FROM header. > > Apologies in advance if this is obvious to everyone else and I'm the only one who doesn't "get it". > > Thanks, > > Tim > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen > Sent: Wednesday, July 03, 2013 9:23 AM > To: dcrocker@bbiw.net > Cc: stir@ietf.org > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) > > There are a lot of local variations out there, but they all have the property that in order to route them, you need to be able to figure out at least the "left" part of the e.164 is, and the right part has to pass unscathed in order to work. Since everyone, and I mean everyone, dealing with these systems knows what e.164s are, and how they work, I don't think it's necessary, or even possible to describe all of the various ways the strings might appear and what to do with them. > > All we need say is that in order to work, the header contents has to be able to have the canonical e.164 extracted with no knowledge at the validator, and validations can occur anywhere in the call path. We'll dress up that text a lot I am sure, but the notion that we could write, or need a document describing all possible variations of how telephone numbers may appear and how to extract the e.164 in each of them seems to me to be silly. > > It may be possible to specify an algorithm however. > > Brian > > On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: > >> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>> Catching up (I was out for a week) >>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>> >>>> 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.) >>> e.164s are much more constrained than the email address issues DKIM has to deal with. We could have challenges with local dial plans, and we've been discussing those issues, but the easy way out on those is that they may not be covered if both ends don't understand the dial plan the same way. >>> >>> So far, while we have one issue I'm concerned with (verifier not being able to extract a canonical e.164 from the content of "From"), I don't think the DKIM experience is particularly relevant. >> >> >> Brian, >> >> Thanks. Good to hear. >> >> I assume there is a document that specifies all of the variations that will be encountered and how to deterministically and successfully transform them into the single, canonical representation? >> >> Absent that, this topic remains a likely source of non-interoperability. >> >> 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 ------=_NextPart_000_0082_01CE77DE.5EEBF490 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcw MzE1MTMzOVowIwYJKoZIhvcNAQkEMRYEFEcIoG1xCB8Y3a0DnUQko1FGSVg/MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAE+mDndAKnqvTDpL9DT5hdFc8AHOYVQPyOujvKf5C 5rXmfKEijW60fYDmDfHMphArktknEJEMYBgBoo63aGMSRvUc7WL/wE6n8+qsOEhe1SZUIWCAN1tQ pILrAeE9AB+FTcxDCcfsZ1jzLvuy3pmmgbJE1ZistSb7EKepA6WipHcF4f2TFQ/bFsVFl2j85zW9 GihzPznxMT6gwMqW/M2+5Z1/6hSMV5LyKc15bOMmAYV0pkJnX+w1hRH4E6DTR7i5NmomTBzeElIM gbN3S7v6OqtMRZ+CtxbPiwEkaDQNxajuN1pJf1eBJQSg5AGT2E8D7SXT0j3AIHeZ4DZze7hskQAA AAAAAA== ------=_NextPart_000_0082_01CE77DE.5EEBF490-- From br@brianrosen.net Wed Jul 3 08:19: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 ABF6311E81D0 for ; Wed, 3 Jul 2013 08:19:02 -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 wwCn5A2vpQk0 for ; Wed, 3 Jul 2013 08:18:58 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD8611E81DC for ; Wed, 3 Jul 2013 08:18:56 -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=QaRnFzyIrTfxHQO4jWC5ywM3NOCy8JixaInppT2aAcc=; b=cRNYtnfCEvxtfMARDDougMfi3TY3YZGgHlgl1GPak+QUn9PjrgbDA0wjL06GtOy8a3pSKCJWsQqzN0a28Ew3uHSLOOJOUqupmZ0kWetqCcpks2vvgMYPBlAPE81ZXii4LyYaHgA7t2rnH0P3BauEokAEsdlx+Rby4YfP2g8ryPA=; Received: from neustargw.va.neustar.com ([209.173.53.233]:46099 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UuOpb-0001mS-LD; Wed, 03 Jul 2013 11:18:55 -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: <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> Date: Wed, 3 Jul 2013 11:18:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> To: Michael Hammer 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" , "timothy.dwight@verizon.com" , "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: Wed, 03 Jul 2013 15:19:02 -0000 Sure, but you get that the To has to go through rewrite to get it = routed, but the =46rom doesn't. It's all well and good to wave your hands and say "all SIP UAs must put = full e.164s in From" but it doesn't happen, and it's not going to = happen. Today, rewrites of =46rom happen, but not always to e.164s. We're = either going to have to have those rewrites occur always to an e.164, = include a full e.164 in a new header, or use P-A-I and require it be a = full e.164 (or a combination). Brian On Jul 3, 2013, at 11:13 AM, Michael Hammer = wrote: > All, >=20 > It helps to read E.164. > It is a string of digits, max 15, no other characters, with CC, NDC, = and SN. > (There are variations on the names for those parts, but the concept is = the > same.) > If you provide a specification that unambiguously delimits that, you = are > golden. >=20 > Do not inject confusion by introducing dialing sting prefixes. > Do not inject confusion by introducing trunking indicators. > Do not inject confusion by introducing methods to group digits. >=20 > If you want the phone number to get anywhere globally, you need to = know how > to generate the E.164. > Any domain worth its salt knows how to go from a local representation = to a > canonical one. > (And there are local representation secret sauce folks who know how to = do > that.) >=20 > Mike >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of > Brian Rosen > Sent: Wednesday, July 03, 2013 10:55 AM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org; dcrocker@bbiw.net > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for = STIR) >=20 > The =46rom problem is lack of country codes, and maybe worse. = Consider these > possible From: contents=20 > 5551212 > 2025551212 > 12025551212 > +12025551212 > and of course all the variations with parens, spaces, hyphens, commas, > periods, etc. >=20 > Although the first is getting really rare, I think it still happens >=20 > The problem with these is when they appear in =46rom on an = international call > - the first 2 are the real problems. They would have to be rewritten. >=20 > With To:, you get the variations with dial 9/8/... in enterprise = systems, > and the 011 style prefix=20 >=20 > Brian >=20 >=20 >=20 > On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" > wrote: >=20 >> Could someone provide a few examples? I have to say I find this = thread > hard to follow. I trust the individuals making the arguments to be > knowledgeable and honest, but personally I have little experience with = this > "FROM header manipulation" that I'm told is so rampant. =20 >>=20 >> The only example I can think of is the "SIP trunking" use case I = raised > previously (user part of URI in FROM and/or TO header may be = significant > only within the dial plan of the associated Enterprise) which was = ruled out > of scope for this activity. So I'm puzzled, what use cases there are = that > (a) are in scope for this exercise, and (b) involve manipulation of = the user > part of the URI in the FROM header. >>=20 >> Apologies in advance if this is obvious to everyone else and I'm the = only > one who doesn't "get it". >>=20 >> Thanks, >>=20 >> Tim >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of > Brian Rosen >> Sent: Wednesday, July 03, 2013 9:23 AM >> To: dcrocker@bbiw.net >> Cc: stir@ietf.org >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for = STIR) >>=20 >> There are a lot of local variations out there, but they all have the > property that in order to route them, you need to be able to figure = out at > least the "left" part of the e.164 is, and the right part has to pass > unscathed in order to work. Since everyone, and I mean everyone, = dealing > with these systems knows what e.164s are, and how they work, I don't = think > it's necessary, or even possible to describe all of the various ways = the > strings might appear and what to do with them. >>=20 >> All we need say is that in order to work, the header contents has to = be > able to have the canonical e.164 extracted with no knowledge at the > validator, and validations can occur anywhere in the call path. We'll = dress > up that text a lot I am sure, but the notion that we could write, or = need a > document describing all possible variations of how telephone numbers = may > appear and how to extract the e.164 in each of them seems to me to be = silly. >>=20 >> It may be possible to specify an algorithm however. >>=20 >> Brian >>=20 >> On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >>=20 >>> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>>> Catching up (I was out for a week) >>>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>>=20 >>>>> 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.) >>>> e.164s are much more constrained than the email address issues DKIM = has > to deal with. We could have challenges with local dial plans, and = we've > been discussing those issues, but the easy way out on those is that = they may > not be covered if both ends don't understand the dial plan the same = way. >>>>=20 >>>> So far, while we have one issue I'm concerned with (verifier not = being > able to extract a canonical e.164 from the content of "From"), I don't = think > the DKIM experience is particularly relevant. >>>=20 >>>=20 >>> Brian, >>>=20 >>> Thanks. Good to hear. >>>=20 >>> I assume there is a document that specifies all of the variations = that > will be encountered and how to deterministically and successfully = transform > them into the single, canonical representation? >>>=20 >>> Absent that, this topic remains a likely source of = non-interoperability. >>>=20 >>> d/ >>>=20 >>>=20 >>> --=20 >>> Dave Crocker >>> Brandenburg InternetWorking >>> bbiw.net >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From Henning.Schulzrinne@fcc.gov Wed Jul 3 08:19: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 69DFC11E81DE for ; Wed, 3 Jul 2013 08:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.304 X-Spam-Level: X-Spam-Status: No, score=-1.304 tagged_above=-999 required=5 tests=[AWL=1.295, 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 wzyRCysWrUAn for ; Wed, 3 Jul 2013 08:19:06 -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 DD07211E81D9 for ; Wed, 3 Jul 2013 08:19:03 -0700 (PDT) Message-ID: X-CheckPoint: {51D440C7-3B-D2C987A5-1FFFF} From: Henning Schulzrinne To: "'philippe.fouquart@orange.com'" , Brian Rosen , "Dwight, Timothy M (Tim)" Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qfju36ah9Ux0e2HxhSF1PQN5lLiToAgAArZACAAAM/gIAAC30AgABB8ACABz9yAIAABZQAgAADigCAAAR8gIAABGkAgAADuID//76roA== Date: Wed, 3 Jul 2013 15:18:30 +0000 References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <6435_1372864087_51D43E57_6435_5254_8_B5939C6860701C49AA39C5DA5189448B0B2905@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <6435_1372864087_51D43E57_6435_5254_8_B5939C6860701C49AA39C5DA5189448B0B2905@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: "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: Wed, 03 Jul 2013 15:19:10 -0000 The advantage we have is that the conversion of the From is done close to t= he origin, i.e., by somebody with local knowledge, even if it requires algo= rithms that are country-specific. For the reasons mentioned several times (= CNAM, SS7, intercarrier compensation, voicemail, 911 ALI for wireless, etc.= ), this seems to work well enough in practice, even without a formal standa= rd beyond E.164. I have no objection to describing common cases, but I don'= t think this is a major concern for interoperability as long as everyone ag= rees what the canonical form is. Only the canonical form matters for intero= perability, i.e., the receiver doesn't have to understand in detail how it = was arrived at and how much programmer sweat was involved. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of phi= lippe.fouquart@orange.com Sent: Wednesday, July 03, 2013 11:08 AM To: Brian Rosen; Dwight, Timothy M (Tim) Cc: stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) I agree, I'm not sure I would go as far as calling the idea of defining all= possible variations "silly" but if, as I understand it, the idea was (at l= east) to come up with an algorithm/mapping to describe how a CLI expressed = in the dialing plan (or the national portion of the E.164 number) can be co= nverted into a full E.164 form for example, I think this would indeed be ov= erly ambitious.=20 For example, I regularly deal with a public dialling plan that requires abo= ut 20 if/then/else clauses on the value of the national Subscriber Number t= o do just that. And that's only for one (arguably quite complex yet closed)= national dialling plan. There are more than 200 of these on the planet, ea= ch of which potentially has its own national variations and change over tim= e. 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 Bri= an Rosen Sent: Wednesday, July 03, 2013 4:55 PM To: Dwight, Timothy M (Tim) Cc: stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) The From problem is lack of country codes, and maybe worse. Consider these= possible From: contents 5551212 2025551212 12025551212 +12025551212 and of course all the variations with parens, spaces, hyphens, commas, peri= ods, etc. Although the first is getting really rare, I think it still happens The problem with these is when they appear in From on an international call= - the first 2 are the real problems. They would have to be rewritten. With To:, you get the variations with dial 9/8/... in enterprise systems, a= nd the 011 style prefix=20 Brian On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" wrote: > Could someone provide a few examples? I have to say I find this thread h= ard to follow. I trust the individuals making the arguments to be knowledg= eable and honest, but personally I have little experience with this "FROM h= eader manipulation" that I'm told is so rampant. =20 >=20 > The only example I can think of is the "SIP trunking" use case I raised p= reviously (user part of URI in FROM and/or TO header may be significant onl= y within the dial plan of the associated Enterprise) which was ruled out of= scope for this activity. So I'm puzzled, what use cases there are that (a= ) are in scope for this exercise, and (b) involve manipulation of the user = part of the URI in the FROM header. >=20 > Apologies in advance if this is obvious to everyone else and I'm the only= one who doesn't "get it". >=20 > Thanks, >=20 > Tim >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 > Of Brian Rosen > Sent: Wednesday, July 03, 2013 9:23 AM > To: dcrocker@bbiw.net > Cc: stir@ietf.org > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for=20 > STIR) >=20 > There are a lot of local variations out there, but they all have the prop= erty that in order to route them, you need to be able to figure out at leas= t the "left" part of the e.164 is, and the right part has to pass unscathed= in order to work. Since everyone, and I mean everyone, dealing with these= systems knows what e.164s are, and how they work, I don't think it's neces= sary, or even possible to describe all of the various ways the strings migh= t appear and what to do with them. >=20 > All we need say is that in order to work, the header contents has to be a= ble to have the canonical e.164 extracted with no knowledge at the validato= r, and validations can occur anywhere in the call path. We'll dress up tha= t text a lot I am sure, but the notion that we could write, or need a docum= ent describing all possible variations of how telephone numbers may appear = and how to extract the e.164 in each of them seems to me to be silly. >=20 > It may be possible to specify an algorithm however. >=20 > Brian >=20 > On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >=20 >> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>> Catching up (I was out for a week) >>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>=20 >>>> The experience with canonicalization algorithms for DKIM -- and it,=20 >>>> too, had to deal with in-transit modifications -- makes clear that=20 >>>> it's a topic with challenges and compromises. (Hmmm. =20 >>>> "compromises" might be a pun, here.) >>> e.164s are much more constrained than the email address issues DKIM has= to deal with. We could have challenges with local dial plans, and we've b= een discussing those issues, but the easy way out on those is that they may= not be covered if both ends don't understand the dial plan the same way. >>>=20 >>> So far, while we have one issue I'm concerned with (verifier not being = able to extract a canonical e.164 from the content of "From"), I don't thin= k the DKIM experience is particularly relevant. >>=20 >>=20 >> Brian, >>=20 >> Thanks. Good to hear. >>=20 >> I assume there is a document that specifies all of the variations that w= ill be encountered and how to deterministically and successfully transform = them into the single, canonical representation? >>=20 >> Absent that, this topic remains a likely source of non-interoperability. >>=20 >> d/ >>=20 >>=20 >> -- >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ___________________________________________________________________________= ______________________________________________ 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 From michael.hammer@yaanatech.com Wed Jul 3 08:20: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 8A54B11E81C1 for ; Wed, 3 Jul 2013 08:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.271, 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 jNfSVQjJBKQP for ; Wed, 3 Jul 2013 08:20:04 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id C78B621F997A for ; Wed, 3 Jul 2013 08:19: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; Wed, 3 Jul 2013 08:19:57 -0700 From: Michael Hammer To: "philippe.fouquart@orange.com" , "br@brianrosen.net" , "timothy.dwight@verizon.com" Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qWRsjPKQFYKEy7+8dmUhlONZlLu4UAgAArZAD//42y0IAAgQkAgABB8ACABz9zAIAABZQAgAADigCAAAR8gIAABGkAgAADuID//41lAA== Date: Wed, 3 Jul 2013 15:19:56 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC10F2B@EX2K10MB1.corp.yaanatech.com> References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <6435_1372864087_51D43E57_6435_5254_8_B5939C6860701C49AA39C5DA5189448B0B2905@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <6435_1372864087_51D43E57_6435_5254_8_B5939C6860701C49AA39C5DA5189448B0B2905@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: [10.17.100.96] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0092_01CE77DF.3F624420" 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: Wed, 03 Jul 2013 15:20:08 -0000 ------=_NextPart_000_0092_01CE77DF.3F624420 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I don't think we need to define all the variations. I don't think we need to define how to do the mapping. We only need to define that the value used for validation be an E.164 number. Then those systems can figure out how to convert. After all, we need to define an interoperable spec, not someone's implementation. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of philippe.fouquart@orange.com Sent: Wednesday, July 03, 2013 11:08 AM To: Brian Rosen; Dwight, Timothy M (Tim) Cc: stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) I agree, I'm not sure I would go as far as calling the idea of defining all possible variations "silly" but if, as I understand it, the idea was (at least) to come up with an algorithm/mapping to describe how a CLI expressed in the dialing plan (or the national portion of the E.164 number) can be converted into a full E.164 form for example, I think this would indeed be overly ambitious. For example, I regularly deal with a public dialling plan that requires about 20 if/then/else clauses on the value of the national Subscriber Number to do just that. And that's only for one (arguably quite complex yet closed) national dialling plan. There are more than 200 of these on the planet, each of which potentially has its own national variations and change over time. 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 Brian Rosen Sent: Wednesday, July 03, 2013 4:55 PM To: Dwight, Timothy M (Tim) Cc: stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) The From problem is lack of country codes, and maybe worse. Consider these possible From: contents 5551212 2025551212 12025551212 +12025551212 and of course all the variations with parens, spaces, hyphens, commas, periods, etc. Although the first is getting really rare, I think it still happens The problem with these is when they appear in From on an international call - the first 2 are the real problems. They would have to be rewritten. With To:, you get the variations with dial 9/8/... in enterprise systems, and the 011 style prefix Brian On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" wrote: > Could someone provide a few examples? I have to say I find this thread hard to follow. I trust the individuals making the arguments to be knowledgeable and honest, but personally I have little experience with this "FROM header manipulation" that I'm told is so rampant. > > The only example I can think of is the "SIP trunking" use case I raised previously (user part of URI in FROM and/or TO header may be significant only within the dial plan of the associated Enterprise) which was ruled out of scope for this activity. So I'm puzzled, what use cases there are that (a) are in scope for this exercise, and (b) involve manipulation of the user part of the URI in the FROM header. > > Apologies in advance if this is obvious to everyone else and I'm the only one who doesn't "get it". > > Thanks, > > Tim > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: Wednesday, July 03, 2013 9:23 AM > To: dcrocker@bbiw.net > Cc: stir@ietf.org > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for > STIR) > > There are a lot of local variations out there, but they all have the property that in order to route them, you need to be able to figure out at least the "left" part of the e.164 is, and the right part has to pass unscathed in order to work. Since everyone, and I mean everyone, dealing with these systems knows what e.164s are, and how they work, I don't think it's necessary, or even possible to describe all of the various ways the strings might appear and what to do with them. > > All we need say is that in order to work, the header contents has to be able to have the canonical e.164 extracted with no knowledge at the validator, and validations can occur anywhere in the call path. We'll dress up that text a lot I am sure, but the notion that we could write, or need a document describing all possible variations of how telephone numbers may appear and how to extract the e.164 in each of them seems to me to be silly. > > It may be possible to specify an algorithm however. > > Brian > > On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: > >> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>> Catching up (I was out for a week) >>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>> >>>> 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.) >>> e.164s are much more constrained than the email address issues DKIM has to deal with. We could have challenges with local dial plans, and we've been discussing those issues, but the easy way out on those is that they may not be covered if both ends don't understand the dial plan the same way. >>> >>> So far, while we have one issue I'm concerned with (verifier not being able to extract a canonical e.164 from the content of "From"), I don't think the DKIM experience is particularly relevant. >> >> >> Brian, >> >> Thanks. Good to hear. >> >> I assume there is a document that specifies all of the variations that will be encountered and how to deterministically and successfully transform them into the single, canonical representation? >> >> Absent that, this topic remains a likely source of non-interoperability. >> >> 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 ____________________________________________________________________________ _____________________________________________ 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_0092_01CE77DF.3F624420 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcw MzE1MTk1NlowIwYJKoZIhvcNAQkEMRYEFJwmkotiCCawebo65uTQSIy1FlYGMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAXG3lb7dxFBYsgw3Y/asMsP6aqym+LDnKhRXCHKDV PPLC/wPflqL1z3E3AsgHJg4yWt7hO7Gc/fAmfUQb79ogxHhObddCJ+YvicjGLTgNBbPQnslRgmN1 042iNdlDWMt+Pd7kWKe3OMaFGlSulP40RGkU6BuiarBOdhUWtKXhds9qCqn6dRM/nh8pFdFnOTLd yS0rfgw/LfxesKKzmhLGS4imLD5T5zcqaxU/wQ72yQnbVFD9eGpxaURddZGcM2kJ0JduyURWLaHm ow6jvpYim6aRFApIrGAx793H000/v6Htx9fNr8ENng0+Eifh5VuvjAzaMb99gbLqVPzufcdMHwAA AAAAAA== ------=_NextPart_000_0092_01CE77DF.3F624420-- From michael.hammer@yaanatech.com Wed Jul 3 08:22: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 019ED21F9C54 for ; Wed, 3 Jul 2013 08:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnCA-4cVUr+t for ; Wed, 3 Jul 2013 08:22:28 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 0536521F9C0E for ; Wed, 3 Jul 2013 08:22:28 -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, 3 Jul 2013 08:22:27 -0700 From: Michael Hammer To: "br@brianrosen.net" Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qWRsjPKQFYKEy7+8dmUhlONZlLu4UAgAArZAD//42y0IAAgQkAgABB8ACABz9zAIAABZQAgAADigCAAAR8gIAABGkA//+NhfCAAHktAP//i4pg Date: Wed, 3 Jul 2013 15:22:27 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> In-Reply-To: <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.96] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00A3_01CE77DF.98D48540" MIME-Version: 1.0 Cc: "stir@ietf.org" , "timothy.dwight@verizon.com" , "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: Wed, 03 Jul 2013 15:22:32 -0000 ------=_NextPart_000_00A3_01CE77DF.98D48540 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Then that tells me From is the wrong answer. Mike -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, July 03, 2013 11:19 AM To: Michael Hammer Cc: timothy.dwight@verizon.com; stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Sure, but you get that the To has to go through rewrite to get it routed, but the From doesn't. It's all well and good to wave your hands and say "all SIP UAs must put full e.164s in From" but it doesn't happen, and it's not going to happen. Today, rewrites of From happen, but not always to e.164s. We're either going to have to have those rewrites occur always to an e.164, include a full e.164 in a new header, or use P-A-I and require it be a full e.164 (or a combination). Brian On Jul 3, 2013, at 11:13 AM, Michael Hammer wrote: > All, > > It helps to read E.164. > It is a string of digits, max 15, no other characters, with CC, NDC, and SN. > (There are variations on the names for those parts, but the concept is > the > same.) > If you provide a specification that unambiguously delimits that, you > are golden. > > Do not inject confusion by introducing dialing sting prefixes. > Do not inject confusion by introducing trunking indicators. > Do not inject confusion by introducing methods to group digits. > > If you want the phone number to get anywhere globally, you need to > know how to generate the E.164. > Any domain worth its salt knows how to go from a local representation > to a canonical one. > (And there are local representation secret sauce folks who know how to > do > that.) > > Mike > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: Wednesday, July 03, 2013 10:55 AM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org; dcrocker@bbiw.net > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for > STIR) > > The From problem is lack of country codes, and maybe worse. Consider > these possible From: contents > 5551212 > 2025551212 > 12025551212 > +12025551212 > and of course all the variations with parens, spaces, hyphens, commas, > periods, etc. > > Although the first is getting really rare, I think it still happens > > The problem with these is when they appear in From on an international > call > - the first 2 are the real problems. They would have to be rewritten. > > With To:, you get the variations with dial 9/8/... in enterprise > systems, and the 011 style prefix > > Brian > > > > On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" > wrote: > >> Could someone provide a few examples? I have to say I find this >> thread > hard to follow. I trust the individuals making the arguments to be > knowledgeable and honest, but personally I have little experience with > this "FROM header manipulation" that I'm told is so rampant. >> >> The only example I can think of is the "SIP trunking" use case I >> raised > previously (user part of URI in FROM and/or TO header may be > significant only within the dial plan of the associated Enterprise) > which was ruled out of scope for this activity. So I'm puzzled, what > use cases there are that > (a) are in scope for this exercise, and (b) involve manipulation of > the user part of the URI in the FROM header. >> >> Apologies in advance if this is obvious to everyone else and I'm the >> only > one who doesn't "get it". >> >> Thanks, >> >> Tim >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of > Brian Rosen >> Sent: Wednesday, July 03, 2013 9:23 AM >> To: dcrocker@bbiw.net >> Cc: stir@ietf.org >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for >> STIR) >> >> There are a lot of local variations out there, but they all have the > property that in order to route them, you need to be able to figure > out at least the "left" part of the e.164 is, and the right part has > to pass unscathed in order to work. Since everyone, and I mean > everyone, dealing with these systems knows what e.164s are, and how > they work, I don't think it's necessary, or even possible to describe > all of the various ways the strings might appear and what to do with them. >> >> All we need say is that in order to work, the header contents has to >> be > able to have the canonical e.164 extracted with no knowledge at the > validator, and validations can occur anywhere in the call path. We'll > dress up that text a lot I am sure, but the notion that we could > write, or need a document describing all possible variations of how > telephone numbers may appear and how to extract the e.164 in each of them seems to me to be silly. >> >> It may be possible to specify an algorithm however. >> >> Brian >> >> On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >> >>> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>>> Catching up (I was out for a week) >>>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>> >>>>> 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.) >>>> e.164s are much more constrained than the email address issues DKIM >>>> has > to deal with. We could have challenges with local dial plans, and > we've been discussing those issues, but the easy way out on those is > that they may not be covered if both ends don't understand the dial plan the same way. >>>> >>>> So far, while we have one issue I'm concerned with (verifier not >>>> being > able to extract a canonical e.164 from the content of "From"), I don't > think the DKIM experience is particularly relevant. >>> >>> >>> Brian, >>> >>> Thanks. Good to hear. >>> >>> I assume there is a document that specifies all of the variations >>> that > will be encountered and how to deterministically and successfully > transform them into the single, canonical representation? >>> >>> Absent that, this topic remains a likely source of non-interoperability. >>> >>> 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_00A3_01CE77DF.98D48540 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcw MzE1MjIyNlowIwYJKoZIhvcNAQkEMRYEFGNEFYzzBW4Y46Kt8AgHDe97mF4rMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAYilBYH9XPWGLpfiM+CplNk1y0N/HYFF0vyQk9H9V A1ZQ8vFGjJAw65yCsz7D4I6cMb/AX655g4rTIap3Vy91oQp/AbaisRxhtwmysFHUswrgGJWUfOZk b0wBMZJodw4mPc/rcamGEScX5CmXQlcVyaukmympMOpdIDKCacPEKDlTiSSJayEOTNQaL/Vu6piF aHtIVexTxFtuXDG0QveUYXBGo+FZ5CqOMRH9Xqv1FfaCo7VAsDaUM3b0nIVZzWu4TGtfN7xXBN3M 0Z+TZO4hHApXqLF9CU5OAHwG9aLGR9Zy7Vmt8Xo9qU9vIccljw6SG/fEQeEjfj6AnOIhFYr//AAA AAAAAA== ------=_NextPart_000_00A3_01CE77DF.98D48540-- From oej@edvina.net Wed Jul 3 08:31: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 975FC11E81DD for ; Wed, 3 Jul 2013 08:31: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=[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 ld0R+88sAERx for ; Wed, 3 Jul 2013 08:31:10 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA6B11E81E0 for ; Wed, 3 Jul 2013 08:31:09 -0700 (PDT) Received: from [192.168.40.15] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 9D97793C1AF; Wed, 3 Jul 2013 15:31:02 +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: <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> Date: Wed, 3 Jul 2013 17:31:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9929DF00-4B86-409A-A18C-BED3C52FFEA9@edvina.net> References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1508) Cc: "dcrocker@bbiw.net" , "stir@ietf.org" , "Olle E. Johansson" , "timothy.dwight@verizon.com" , "br@brianrosen.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: Wed, 03 Jul 2013 15:31:11 -0000 3 jul 2013 kl. 17:22 skrev Michael Hammer = : > Then that tells me =46rom is the wrong answer. Or that having the UA sign anything is the wrong answer. I think the UA in most cases has no idea on the E.164, it might be = configured as "steve's phone" or "74747". There is a session boarder where the SIP = call leaves one domain and enters another where the E.164 needs to be in = place and be verified/certified/something-ified. /O >=20 > Mike >=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Wednesday, July 03, 2013 11:19 AM > To: Michael Hammer > Cc: timothy.dwight@verizon.com; stir@ietf.org; dcrocker@bbiw.net > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for = STIR) >=20 > Sure, but you get that the To has to go through rewrite to get it = routed, > but the =46rom doesn't. >=20 > It's all well and good to wave your hands and say "all SIP UAs must = put full > e.164s in From" but it doesn't happen, and it's not going to happen. >=20 > Today, rewrites of =46rom happen, but not always to e.164s. We're = either > going to have to have those rewrites occur always to an e.164, include = a > full e.164 in a new header, or use P-A-I and require it be a full = e.164 (or > a combination). >=20 > Brian >=20 > On Jul 3, 2013, at 11:13 AM, Michael Hammer = > wrote: >=20 >> All, >>=20 >> It helps to read E.164. >> It is a string of digits, max 15, no other characters, with CC, NDC, = and > SN. >> (There are variations on the names for those parts, but the concept = is=20 >> the >> same.) >> If you provide a specification that unambiguously delimits that, you=20= >> are golden. >>=20 >> Do not inject confusion by introducing dialing sting prefixes. >> Do not inject confusion by introducing trunking indicators. >> Do not inject confusion by introducing methods to group digits. >>=20 >> If you want the phone number to get anywhere globally, you need to=20 >> know how to generate the E.164. >> Any domain worth its salt knows how to go from a local representation=20= >> to a canonical one. >> (And there are local representation secret sauce folks who know how = to=20 >> do >> that.) >>=20 >> Mike >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20= >> Of Brian Rosen >> Sent: Wednesday, July 03, 2013 10:55 AM >> To: Dwight, Timothy M (Tim) >> Cc: stir@ietf.org; dcrocker@bbiw.net >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for=20= >> STIR) >>=20 >> The =46rom problem is lack of country codes, and maybe worse. = Consider=20 >> these possible From: contents >> 5551212 >> 2025551212 >> 12025551212 >> +12025551212 >> and of course all the variations with parens, spaces, hyphens, = commas,=20 >> periods, etc. >>=20 >> Although the first is getting really rare, I think it still happens >>=20 >> The problem with these is when they appear in =46rom on an = international=20 >> call >> - the first 2 are the real problems. They would have to be = rewritten. >>=20 >> With To:, you get the variations with dial 9/8/... in enterprise=20 >> systems, and the 011 style prefix >>=20 >> Brian >>=20 >>=20 >>=20 >> On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" >> wrote: >>=20 >>> Could someone provide a few examples? I have to say I find this=20 >>> thread >> hard to follow. I trust the individuals making the arguments to be=20= >> knowledgeable and honest, but personally I have little experience = with=20 >> this "FROM header manipulation" that I'm told is so rampant. >>>=20 >>> The only example I can think of is the "SIP trunking" use case I=20 >>> raised >> previously (user part of URI in FROM and/or TO header may be=20 >> significant only within the dial plan of the associated Enterprise)=20= >> which was ruled out of scope for this activity. So I'm puzzled, what=20= >> use cases there are that >> (a) are in scope for this exercise, and (b) involve manipulation of=20= >> the user part of the URI in the FROM header. >>>=20 >>> Apologies in advance if this is obvious to everyone else and I'm the=20= >>> only >> one who doesn't "get it". >>>=20 >>> Thanks, >>>=20 >>> Tim >>>=20 >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20= >>> Of >> Brian Rosen >>> Sent: Wednesday, July 03, 2013 9:23 AM >>> To: dcrocker@bbiw.net >>> Cc: stir@ietf.org >>> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for=20= >>> STIR) >>>=20 >>> There are a lot of local variations out there, but they all have the >> property that in order to route them, you need to be able to figure=20= >> out at least the "left" part of the e.164 is, and the right part has=20= >> to pass unscathed in order to work. Since everyone, and I mean=20 >> everyone, dealing with these systems knows what e.164s are, and how=20= >> they work, I don't think it's necessary, or even possible to describe=20= >> all of the various ways the strings might appear and what to do with = them. >>>=20 >>> All we need say is that in order to work, the header contents has to=20= >>> be >> able to have the canonical e.164 extracted with no knowledge at the=20= >> validator, and validations can occur anywhere in the call path. = We'll=20 >> dress up that text a lot I am sure, but the notion that we could=20 >> write, or need a document describing all possible variations of how=20= >> telephone numbers may appear and how to extract the e.164 in each of = them > seems to me to be silly. >>>=20 >>> It may be possible to specify an algorithm however. >>>=20 >>> Brian >>>=20 >>> On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >>>=20 >>>> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>>>> Catching up (I was out for a week) >>>>> On Jun 28, 2013, at 7:09 PM, Dave Crocker = wrote: >>>>>=20 >>>>>> The experience with canonicalization algorithms for DKIM -- and=20= >>>>>> it, >> too, had to deal with in-transit modifications -- makes clear that=20 >> it's a topic with challenges and compromises. (Hmmm. "compromises"=20= >> might be a pun, here.) >>>>> e.164s are much more constrained than the email address issues = DKIM=20 >>>>> has >> to deal with. We could have challenges with local dial plans, and=20 >> we've been discussing those issues, but the easy way out on those is=20= >> that they may not be covered if both ends don't understand the dial = plan > the same way. >>>>>=20 >>>>> So far, while we have one issue I'm concerned with (verifier not=20= >>>>> being >> able to extract a canonical e.164 from the content of "From"), I = don't=20 >> think the DKIM experience is particularly relevant. >>>>=20 >>>>=20 >>>> Brian, >>>>=20 >>>> Thanks. Good to hear. >>>>=20 >>>> I assume there is a document that specifies all of the variations=20= >>>> that >> will be encountered and how to deterministically and successfully=20 >> transform them into the single, canonical representation? >>>>=20 >>>> Absent that, this topic remains a likely source of = non-interoperability. >>>>=20 >>>> d/ >>>>=20 >>>>=20 >>>> -- >>>> Dave Crocker >>>> Brandenburg InternetWorking >>>> bbiw.net >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> _______________________________________________ >> 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 Wed Jul 3 08:36: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 42FAD11E81E3 for ; Wed, 3 Jul 2013 08:36:15 -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 2zuA6nchkjc1 for ; Wed, 3 Jul 2013 08:36:11 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id DB8DA11E81CA for ; Wed, 3 Jul 2013 08:36: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=drsXuPoSuqf8DUqlJrxadx0t4Q7yNTxgSMECbXQ2mk4=; b=F8m2oBOV+A1bJqVJgG7K3UksL0Ou31yNe38+SZyAdSTccY09tzgBJwq+Lay5AKcyrkZnkIyc1bfv6safvWwwDo/dXmPfoRwqVj2d6ykbFRBG/lJko+FPpwotEpnTxZ7qxxCtfDFNAcDFA3EcBnh1HBPLZHIuYLvwEFqk7Bxoc00=; Received: from neustargw.va.neustar.com ([209.173.53.233]:56625 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UuP6G-000723-Rv; Wed, 03 Jul 2013 11:36:08 -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: <9929DF00-4B86-409A-A18C-BED3C52FFEA9@edvina.net> Date: Wed, 3 Jul 2013 11:36:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> <9929DF00-4B86-409A-A18C-BED3C52FFEA9@edvina.net> To: "Olle E. Johansson" 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" , Michael Hammer , "timothy.dwight@verizon.com" , "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: Wed, 03 Jul 2013 15:36:15 -0000 Leaving aside whether the UA signs, the UA creates the From. It may well be true that the PBX or SP on the origination can determine = the e.164 of =46rom given the string the UA put in there to sign. The = problem isn't there. The problem is when the call gets to the = termination side and is being verified. The verifier has to be able to = extract the e.164 from the string. If the variations are small enough, or a rewrite happens in the = origination, we're okay. If not, we have to do something else. Brian On Jul 3, 2013, at 11:31 AM, "Olle E. Johansson" wrote: >=20 > 3 jul 2013 kl. 17:22 skrev Michael Hammer = : >=20 >> Then that tells me =46rom is the wrong answer. > Or that having the UA sign anything is the wrong answer. >=20 > I think the UA in most cases has no idea on the E.164, it might be = configured > as "steve's phone" or "74747". There is a session boarder where the = SIP call > leaves one domain and enters another where the E.164 needs to be in = place > and be verified/certified/something-ified. >=20 > /O >>=20 >> Mike >>=20 >>=20 >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net]=20 >> Sent: Wednesday, July 03, 2013 11:19 AM >> To: Michael Hammer >> Cc: timothy.dwight@verizon.com; stir@ietf.org; dcrocker@bbiw.net >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for = STIR) >>=20 >> Sure, but you get that the To has to go through rewrite to get it = routed, >> but the =46rom doesn't. >>=20 >> It's all well and good to wave your hands and say "all SIP UAs must = put full >> e.164s in From" but it doesn't happen, and it's not going to happen. >>=20 >> Today, rewrites of =46rom happen, but not always to e.164s. We're = either >> going to have to have those rewrites occur always to an e.164, = include a >> full e.164 in a new header, or use P-A-I and require it be a full = e.164 (or >> a combination). >>=20 >> Brian >>=20 >> On Jul 3, 2013, at 11:13 AM, Michael Hammer = >> wrote: >>=20 >>> All, >>>=20 >>> It helps to read E.164. >>> It is a string of digits, max 15, no other characters, with CC, NDC, = and >> SN. >>> (There are variations on the names for those parts, but the concept = is=20 >>> the >>> same.) >>> If you provide a specification that unambiguously delimits that, you=20= >>> are golden. >>>=20 >>> Do not inject confusion by introducing dialing sting prefixes. >>> Do not inject confusion by introducing trunking indicators. >>> Do not inject confusion by introducing methods to group digits. >>>=20 >>> If you want the phone number to get anywhere globally, you need to=20= >>> know how to generate the E.164. >>> Any domain worth its salt knows how to go from a local = representation=20 >>> to a canonical one. >>> (And there are local representation secret sauce folks who know how = to=20 >>> do >>> that.) >>>=20 >>> Mike >>>=20 >>>=20 >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20= >>> Of Brian Rosen >>> Sent: Wednesday, July 03, 2013 10:55 AM >>> To: Dwight, Timothy M (Tim) >>> Cc: stir@ietf.org; dcrocker@bbiw.net >>> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for=20= >>> STIR) >>>=20 >>> The =46rom problem is lack of country codes, and maybe worse. = Consider=20 >>> these possible From: contents >>> 5551212 >>> 2025551212 >>> 12025551212 >>> +12025551212 >>> and of course all the variations with parens, spaces, hyphens, = commas,=20 >>> periods, etc. >>>=20 >>> Although the first is getting really rare, I think it still happens >>>=20 >>> The problem with these is when they appear in =46rom on an = international=20 >>> call >>> - the first 2 are the real problems. They would have to be = rewritten. >>>=20 >>> With To:, you get the variations with dial 9/8/... in enterprise=20 >>> systems, and the 011 style prefix >>>=20 >>> Brian >>>=20 >>>=20 >>>=20 >>> On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" >>> wrote: >>>=20 >>>> Could someone provide a few examples? I have to say I find this=20 >>>> thread >>> hard to follow. I trust the individuals making the arguments to be=20= >>> knowledgeable and honest, but personally I have little experience = with=20 >>> this "FROM header manipulation" that I'm told is so rampant. >>>>=20 >>>> The only example I can think of is the "SIP trunking" use case I=20 >>>> raised >>> previously (user part of URI in FROM and/or TO header may be=20 >>> significant only within the dial plan of the associated Enterprise)=20= >>> which was ruled out of scope for this activity. So I'm puzzled, = what=20 >>> use cases there are that >>> (a) are in scope for this exercise, and (b) involve manipulation of=20= >>> the user part of the URI in the FROM header. >>>>=20 >>>> Apologies in advance if this is obvious to everyone else and I'm = the=20 >>>> only >>> one who doesn't "get it". >>>>=20 >>>> Thanks, >>>>=20 >>>> Tim >>>>=20 >>>> -----Original Message----- >>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = Behalf=20 >>>> Of >>> Brian Rosen >>>> Sent: Wednesday, July 03, 2013 9:23 AM >>>> To: dcrocker@bbiw.net >>>> Cc: stir@ietf.org >>>> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text = for=20 >>>> STIR) >>>>=20 >>>> There are a lot of local variations out there, but they all have = the >>> property that in order to route them, you need to be able to figure=20= >>> out at least the "left" part of the e.164 is, and the right part has=20= >>> to pass unscathed in order to work. Since everyone, and I mean=20 >>> everyone, dealing with these systems knows what e.164s are, and how=20= >>> they work, I don't think it's necessary, or even possible to = describe=20 >>> all of the various ways the strings might appear and what to do with = them. >>>>=20 >>>> All we need say is that in order to work, the header contents has = to=20 >>>> be >>> able to have the canonical e.164 extracted with no knowledge at the=20= >>> validator, and validations can occur anywhere in the call path. = We'll=20 >>> dress up that text a lot I am sure, but the notion that we could=20 >>> write, or need a document describing all possible variations of how=20= >>> telephone numbers may appear and how to extract the e.164 in each of = them >> seems to me to be silly. >>>>=20 >>>> It may be possible to specify an algorithm however. >>>>=20 >>>> Brian >>>>=20 >>>> On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >>>>=20 >>>>> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>>>>> Catching up (I was out for a week) >>>>>> On Jun 28, 2013, at 7:09 PM, Dave Crocker = wrote: >>>>>>=20 >>>>>>> The experience with canonicalization algorithms for DKIM -- and=20= >>>>>>> it, >>> too, had to deal with in-transit modifications -- makes clear that=20= >>> it's a topic with challenges and compromises. (Hmmm. "compromises"=20= >>> might be a pun, here.) >>>>>> e.164s are much more constrained than the email address issues = DKIM=20 >>>>>> has >>> to deal with. We could have challenges with local dial plans, and=20= >>> we've been discussing those issues, but the easy way out on those is=20= >>> that they may not be covered if both ends don't understand the dial = plan >> the same way. >>>>>>=20 >>>>>> So far, while we have one issue I'm concerned with (verifier not=20= >>>>>> being >>> able to extract a canonical e.164 from the content of "From"), I = don't=20 >>> think the DKIM experience is particularly relevant. >>>>>=20 >>>>>=20 >>>>> Brian, >>>>>=20 >>>>> Thanks. Good to hear. >>>>>=20 >>>>> I assume there is a document that specifies all of the variations=20= >>>>> that >>> will be encountered and how to deterministically and successfully=20 >>> transform them into the single, canonical representation? >>>>>=20 >>>>> Absent that, this topic remains a likely source of = non-interoperability. >>>>>=20 >>>>> d/ >>>>>=20 >>>>>=20 >>>>> -- >>>>> Dave Crocker >>>>> Brandenburg InternetWorking >>>>> bbiw.net >>>>=20 >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>> _______________________________________________ >>> 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 Henning.Schulzrinne@fcc.gov Wed Jul 3 08:37:45 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3C811E81CA for ; Wed, 3 Jul 2013 08:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.404 X-Spam-Level: X-Spam-Status: No, score=-1.404 tagged_above=-999 required=5 tests=[AWL=1.195, 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 1FiLHaOrYCQd for ; Wed, 3 Jul 2013 08:37:41 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 370DB11E81EC for ; Wed, 3 Jul 2013 08:37:41 -0700 (PDT) Message-ID: X-CheckPoint: {51D44544-52-D2C987A5-1FFFF} From: Henning Schulzrinne To: 'Michael Hammer' , "br@brianrosen.net" Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qfju36ah9Ux0e2HxhSF1PQN5lLiToAgAArZACAAAM/gIAAC30AgABB8ACABz9yAIAABZQAgAADigCAAAR8gIAABGkAgAAFRQCAAAFtAIAAAQiA//+/2HA= Date: Wed, 3 Jul 2013 15:37:39 +0000 References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "timothy.dwight@verizon.com" , "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: Wed, 03 Jul 2013 15:37:45 -0000 We're retreading the same territory, but I don't think anybody is talking a= bout rewriting From. The process is Identity =3D Hash-and-sign(convert-to-E.164(From)) As long as the receiver can perform the same operation and get the same res= ult, this works. For the reasons now repeated several times, receivers do s= eem to be able to make sense of inter-provider From information, as they us= e it mechanically for a variety of purposes. I just don't see the real problem - if From (and their SS7 kin) didn't work= , callerID would fail altogether. It obviously doesn't, for almost all call= s. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Mic= hael Hammer Sent: Wednesday, July 03, 2013 11:22 AM To: br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Then that tells me From is the wrong answer. Mike -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, July 03, 2013 11:19 AM To: Michael Hammer Cc: timothy.dwight@verizon.com; stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Sure, but you get that the To has to go through rewrite to get it routed, b= ut the From doesn't. It's all well and good to wave your hands and say "all SIP UAs must put ful= l e.164s in From" but it doesn't happen, and it's not going to happen. Today, rewrites of From happen, but not always to e.164s. We're either goi= ng to have to have those rewrites occur always to an e.164, include a full = e.164 in a new header, or use P-A-I and require it be a full e.164 (or a co= mbination). Brian On Jul 3, 2013, at 11:13 AM, Michael Hammer wrote: > All, >=20 > It helps to read E.164. > It is a string of digits, max 15, no other characters, with CC, NDC,=20 > and SN. > (There are variations on the names for those parts, but the concept is=20 > the > same.) > If you provide a specification that unambiguously delimits that, you=20 > are golden. >=20 > Do not inject confusion by introducing dialing sting prefixes. > Do not inject confusion by introducing trunking indicators. > Do not inject confusion by introducing methods to group digits. >=20 > If you want the phone number to get anywhere globally, you need to=20 > know how to generate the E.164. > Any domain worth its salt knows how to go from a local representation=20 > to a canonical one. > (And there are local representation secret sauce folks who know how to=20 > do > that.) >=20 > Mike >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 > Of Brian Rosen > Sent: Wednesday, July 03, 2013 10:55 AM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org; dcrocker@bbiw.net > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for > STIR) >=20 > The From problem is lack of country codes, and maybe worse. Consider=20 > these possible From: contents > 5551212 > 2025551212 > 12025551212 > +12025551212 > and of course all the variations with parens, spaces, hyphens, commas,=20 > periods, etc. >=20 > Although the first is getting really rare, I think it still happens >=20 > The problem with these is when they appear in From on an international=20 > call > - the first 2 are the real problems. They would have to be rewritten. >=20 > With To:, you get the variations with dial 9/8/... in enterprise=20 > systems, and the 011 style prefix >=20 > Brian >=20 >=20 >=20 > On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" > wrote: >=20 >> Could someone provide a few examples? I have to say I find this=20 >> thread > hard to follow. I trust the individuals making the arguments to be=20 > knowledgeable and honest, but personally I have little experience with=20 > this "FROM header manipulation" that I'm told is so rampant. >>=20 >> The only example I can think of is the "SIP trunking" use case I=20 >> raised > previously (user part of URI in FROM and/or TO header may be=20 > significant only within the dial plan of the associated Enterprise)=20 > which was ruled out of scope for this activity. So I'm puzzled, what=20 > use cases there are that > (a) are in scope for this exercise, and (b) involve manipulation of=20 > the user part of the URI in the FROM header. >>=20 >> Apologies in advance if this is obvious to everyone else and I'm the=20 >> only > one who doesn't "get it". >>=20 >> Thanks, >>=20 >> Tim >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of > Brian Rosen >> Sent: Wednesday, July 03, 2013 9:23 AM >> To: dcrocker@bbiw.net >> Cc: stir@ietf.org >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for >> STIR) >>=20 >> There are a lot of local variations out there, but they all have the > property that in order to route them, you need to be able to figure=20 > out at least the "left" part of the e.164 is, and the right part has=20 > to pass unscathed in order to work. Since everyone, and I mean=20 > everyone, dealing with these systems knows what e.164s are, and how=20 > they work, I don't think it's necessary, or even possible to describe=20 > all of the various ways the strings might appear and what to do with them= . >>=20 >> All we need say is that in order to work, the header contents has to=20 >> be > able to have the canonical e.164 extracted with no knowledge at the=20 > validator, and validations can occur anywhere in the call path. We'll=20 > dress up that text a lot I am sure, but the notion that we could=20 > write, or need a document describing all possible variations of how=20 > telephone numbers may appear and how to extract the e.164 in each of=20 > them seems to me to be silly. >>=20 >> It may be possible to specify an algorithm however. >>=20 >> Brian >>=20 >> On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >>=20 >>> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>>> Catching up (I was out for a week) >>>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>>=20 >>>>> The experience with canonicalization algorithms for DKIM -- and=20 >>>>> it, > too, had to deal with in-transit modifications -- makes clear that=20 > it's a topic with challenges and compromises. (Hmmm. "compromises" > might be a pun, here.) >>>> e.164s are much more constrained than the email address issues DKIM=20 >>>> has > to deal with. We could have challenges with local dial plans, and=20 > we've been discussing those issues, but the easy way out on those is=20 > that they may not be covered if both ends don't understand the dial=20 > plan the same way. >>>>=20 >>>> So far, while we have one issue I'm concerned with (verifier not=20 >>>> being > able to extract a canonical e.164 from the content of "From"), I don't=20 > think the DKIM experience is particularly relevant. >>>=20 >>>=20 >>> Brian, >>>=20 >>> Thanks. Good to hear. >>>=20 >>> I assume there is a document that specifies all of the variations=20 >>> that > will be encountered and how to deterministically and successfully=20 > transform them into the single, canonical representation? >>>=20 >>> Absent that, this topic remains a likely source of non-interoperability= . >>>=20 >>> d/ >>>=20 >>>=20 >>> -- >>> Dave Crocker >>> Brandenburg InternetWorking >>> bbiw.net >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From philippe.fouquart@orange.com Wed Jul 3 08:38: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 0199211E81EA for ; Wed, 3 Jul 2013 08:38:49 -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 rl-9MOfegSky for ; Wed, 3 Jul 2013 08:38:45 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE6111E81B5 for ; Wed, 3 Jul 2013 08:38:44 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 70037264853; Wed, 3 Jul 2013 17:38:43 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 3A76035C05A; Wed, 3 Jul 2013 17:38:43 +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, 3 Jul 2013 17:38:42 +0200 From: To: Henning Schulzrinne , Brian Rosen , "Dwight, Timothy M (Tim)" Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qYQbRBguG1BUWXYgpbqGpqHZlLJKUAgAArZACAAAM/gIAAC30AgABB8ACABz9yAIAABZQAgAADigCAAAR8gIAABGkAgAAj5tD//+K5AIAAJSlg Date: Wed, 3 Jul 2013 15:38:42 +0000 Message-ID: <21690_1372865923_51D44583_21690_3687_12_B5939C6860701C49AA39C5DA5189448B0B295B@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <6435_1372864087_51D43E57_6435_5254_8_B5939C6860701C49AA39C5DA5189448B0B2905@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.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.3.105728 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: Wed, 03 Jul 2013 15:38:49 -0000 Yes, I quite agree, apologies if this wasn't clear: that's why I noted on a= different thread that if that number cannot be provided in its full form, = both calling and called parties will in most cases (eg they are on the same= dialing plan) share an implicit context which makes the conversion to the = full form feasible (for the callee if it's a CLI). The original question he= re as I understood it was whether there could exist somewhere a document th= at specifies all of the variations that will be encountered to avoid resort= ing to such an implicit context/"knowledge". I just don't think there is, a= nd don't see how there could possibly be one. Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Wednesday, July 03, 2013 5:19 PM To: FOUQUART Philippe OLNC/OLN; Brian Rosen; Dwight, Timothy M (Tim) Cc: stir@ietf.org; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) The advantage we have is that the conversion of the From is done close to t= he origin, i.e., by somebody with local knowledge, even if it requires algo= rithms that are country-specific. For the reasons mentioned several times (= CNAM, SS7, intercarrier compensation, voicemail, 911 ALI for wireless, etc.= ), this seems to work well enough in practice, even without a formal standa= rd beyond E.164. I have no objection to describing common cases, but I don'= t think this is a major concern for interoperability as long as everyone ag= rees what the canonical form is. Only the canonical form matters for intero= perability, i.e., the receiver doesn't have to understand in detail how it = was arrived at and how much programmer sweat was involved. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of phi= lippe.fouquart@orange.com Sent: Wednesday, July 03, 2013 11:08 AM To: Brian Rosen; Dwight, Timothy M (Tim) Cc: stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) I agree, I'm not sure I would go as far as calling the idea of defining all= possible variations "silly" but if, as I understand it, the idea was (at l= east) to come up with an algorithm/mapping to describe how a CLI expressed = in the dialing plan (or the national portion of the E.164 number) can be co= nverted into a full E.164 form for example, I think this would indeed be ov= erly ambitious.=20 For example, I regularly deal with a public dialling plan that requires abo= ut 20 if/then/else clauses on the value of the national Subscriber Number t= o do just that. And that's only for one (arguably quite complex yet closed)= national dialling plan. There are more than 200 of these on the planet, ea= ch of which potentially has its own national variations and change over tim= e. 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 Bri= an Rosen Sent: Wednesday, July 03, 2013 4:55 PM To: Dwight, Timothy M (Tim) Cc: stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) The From problem is lack of country codes, and maybe worse. Consider these= possible From: contents 5551212 2025551212 12025551212 +12025551212 and of course all the variations with parens, spaces, hyphens, commas, peri= ods, etc. Although the first is getting really rare, I think it still happens The problem with these is when they appear in From on an international call= - the first 2 are the real problems. They would have to be rewritten. With To:, you get the variations with dial 9/8/... in enterprise systems, a= nd the 011 style prefix=20 Brian On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" wrote: > Could someone provide a few examples? I have to say I find this thread h= ard to follow. I trust the individuals making the arguments to be knowledg= eable and honest, but personally I have little experience with this "FROM h= eader manipulation" that I'm told is so rampant.=20=20 >=20 > The only example I can think of is the "SIP trunking" use case I raised p= reviously (user part of URI in FROM and/or TO header may be significant onl= y within the dial plan of the associated Enterprise) which was ruled out of= scope for this activity. So I'm puzzled, what use cases there are that (a= ) are in scope for this exercise, and (b) involve manipulation of the user = part of the URI in the FROM header. >=20 > Apologies in advance if this is obvious to everyone else and I'm the only= one who doesn't "get it". >=20 > Thanks, >=20 > Tim >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 > Of Brian Rosen > Sent: Wednesday, July 03, 2013 9:23 AM > To: dcrocker@bbiw.net > Cc: stir@ietf.org > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for=20 > STIR) >=20 > There are a lot of local variations out there, but they all have the prop= erty that in order to route them, you need to be able to figure out at leas= t the "left" part of the e.164 is, and the right part has to pass unscathed= in order to work. Since everyone, and I mean everyone, dealing with these= systems knows what e.164s are, and how they work, I don't think it's neces= sary, or even possible to describe all of the various ways the strings migh= t appear and what to do with them. >=20 > All we need say is that in order to work, the header contents has to be a= ble to have the canonical e.164 extracted with no knowledge at the validato= r, and validations can occur anywhere in the call path. We'll dress up tha= t text a lot I am sure, but the notion that we could write, or need a docum= ent describing all possible variations of how telephone numbers may appear = and how to extract the e.164 in each of them seems to me to be silly. >=20 > It may be possible to specify an algorithm however. >=20 > Brian >=20 > On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >=20 >> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>> Catching up (I was out for a week) >>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>=20 >>>> The experience with canonicalization algorithms for DKIM -- and it,=20 >>>> too, had to deal with in-transit modifications -- makes clear that=20 >>>> it's a topic with challenges and compromises. (Hmmm.=20=20 >>>> "compromises" might be a pun, here.) >>> e.164s are much more constrained than the email address issues DKIM has= to deal with. We could have challenges with local dial plans, and we've b= een discussing those issues, but the easy way out on those is that they may= not be covered if both ends don't understand the dial plan the same way. >>>=20 >>> So far, while we have one issue I'm concerned with (verifier not being = able to extract a canonical e.164 from the content of "From"), I don't thin= k the DKIM experience is particularly relevant. >>=20 >>=20 >> Brian, >>=20 >> Thanks. Good to hear. >>=20 >> I assume there is a document that specifies all of the variations that w= ill be encountered and how to deterministically and successfully transform = them into the single, canonical representation? >>=20 >> Absent that, this topic remains a likely source of non-interoperability. >>=20 >> d/ >>=20 >>=20 >> -- >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ___________________________________________________________________________= ______________________________________________ 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From br@brianrosen.net Wed Jul 3 08:44: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 5653211E80D9 for ; Wed, 3 Jul 2013 08:44:05 -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 z4k1lYEdlqds for ; Wed, 3 Jul 2013 08:44:01 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id EA89911E81CA for ; Wed, 3 Jul 2013 08:44: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=f3h3YVeAp01eVvGz3sm2ZurftDYSg315DDT7mnA29aU=; b=ivTYJhTqIR6TAZh9i9wOzimUI6CUDBhMkCPYiSgzUGmvTq9iPv+MZVpvHfhieuOyirSGkSbuaU+3GWtBj1tjIEMUJy4ab5nF4n97qdU78F3K38pyT9BhS4CvUomGd0RadSbg45JKHGx41cJqIHpme/BvVe93nQ5SN6DEPEsv5hU=; Received: from neustargw.va.neustar.com ([209.173.53.233]:59462 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UuPDr-0001D7-HW; Wed, 03 Jul 2013 11:43:59 -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: Wed, 3 Jul 2013 11:43:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> To: Henning Schulzrinne 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" , 'Michael Hammer' , "timothy.dwight@verizon.com" , "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: Wed, 03 Jul 2013 15:44:05 -0000 Here is an example of where I think we have a problem: From: 2025551212 To: +44 800 505555 Any entity on the origination side, including an SS7 GW, would know that = the e.164 for =46rom is +12025551212 The problem is if the call arrives as all SIP, the UK phone or SP won't = know that. Brian On Jul 3, 2013, at 11:37 AM, Henning Schulzrinne = wrote: > We're retreading the same territory, but I don't think anybody is = talking about rewriting From. The process is >=20 > Identity =3D Hash-and-sign(convert-to-E.164(From)) >=20 > As long as the receiver can perform the same operation and get the = same result, this works. For the reasons now repeated several times, = receivers do seem to be able to make sense of inter-provider =46rom = information, as they use it mechanically for a variety of purposes. >=20 > I just don't see the real problem - if =46rom (and their SS7 kin) = didn't work, callerID would fail altogether. It obviously doesn't, for = almost all calls. >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Michael Hammer > Sent: Wednesday, July 03, 2013 11:22 AM > To: br@brianrosen.net > Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for = STIR) >=20 > Then that tells me =46rom is the wrong answer. >=20 > Mike >=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, July 03, 2013 11:19 AM > To: Michael Hammer > Cc: timothy.dwight@verizon.com; stir@ietf.org; dcrocker@bbiw.net > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for = STIR) >=20 > Sure, but you get that the To has to go through rewrite to get it = routed, but the =46rom doesn't. >=20 > It's all well and good to wave your hands and say "all SIP UAs must = put full e.164s in From" but it doesn't happen, and it's not going to = happen. >=20 > Today, rewrites of =46rom happen, but not always to e.164s. We're = either going to have to have those rewrites occur always to an e.164, = include a full e.164 in a new header, or use P-A-I and require it be a = full e.164 (or a combination). >=20 > Brian >=20 > On Jul 3, 2013, at 11:13 AM, Michael Hammer = > wrote: >=20 >> All, >>=20 >> It helps to read E.164. >> It is a string of digits, max 15, no other characters, with CC, NDC,=20= >> and > SN. >> (There are variations on the names for those parts, but the concept = is=20 >> the >> same.) >> If you provide a specification that unambiguously delimits that, you=20= >> are golden. >>=20 >> Do not inject confusion by introducing dialing sting prefixes. >> Do not inject confusion by introducing trunking indicators. >> Do not inject confusion by introducing methods to group digits. >>=20 >> If you want the phone number to get anywhere globally, you need to=20 >> know how to generate the E.164. >> Any domain worth its salt knows how to go from a local representation=20= >> to a canonical one. >> (And there are local representation secret sauce folks who know how = to=20 >> do >> that.) >>=20 >> Mike >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20= >> Of Brian Rosen >> Sent: Wednesday, July 03, 2013 10:55 AM >> To: Dwight, Timothy M (Tim) >> Cc: stir@ietf.org; dcrocker@bbiw.net >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for >> STIR) >>=20 >> The =46rom problem is lack of country codes, and maybe worse. = Consider=20 >> these possible From: contents >> 5551212 >> 2025551212 >> 12025551212 >> +12025551212 >> and of course all the variations with parens, spaces, hyphens, = commas,=20 >> periods, etc. >>=20 >> Although the first is getting really rare, I think it still happens >>=20 >> The problem with these is when they appear in =46rom on an = international=20 >> call >> - the first 2 are the real problems. They would have to be = rewritten. >>=20 >> With To:, you get the variations with dial 9/8/... in enterprise=20 >> systems, and the 011 style prefix >>=20 >> Brian >>=20 >>=20 >>=20 >> On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" >> wrote: >>=20 >>> Could someone provide a few examples? I have to say I find this=20 >>> thread >> hard to follow. I trust the individuals making the arguments to be=20= >> knowledgeable and honest, but personally I have little experience = with=20 >> this "FROM header manipulation" that I'm told is so rampant. >>>=20 >>> The only example I can think of is the "SIP trunking" use case I=20 >>> raised >> previously (user part of URI in FROM and/or TO header may be=20 >> significant only within the dial plan of the associated Enterprise)=20= >> which was ruled out of scope for this activity. So I'm puzzled, what=20= >> use cases there are that >> (a) are in scope for this exercise, and (b) involve manipulation of=20= >> the user part of the URI in the FROM header. >>>=20 >>> Apologies in advance if this is obvious to everyone else and I'm the=20= >>> only >> one who doesn't "get it". >>>=20 >>> Thanks, >>>=20 >>> Tim >>>=20 >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20= >>> Of >> Brian Rosen >>> Sent: Wednesday, July 03, 2013 9:23 AM >>> To: dcrocker@bbiw.net >>> Cc: stir@ietf.org >>> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for >>> STIR) >>>=20 >>> There are a lot of local variations out there, but they all have the >> property that in order to route them, you need to be able to figure=20= >> out at least the "left" part of the e.164 is, and the right part has=20= >> to pass unscathed in order to work. Since everyone, and I mean=20 >> everyone, dealing with these systems knows what e.164s are, and how=20= >> they work, I don't think it's necessary, or even possible to describe=20= >> all of the various ways the strings might appear and what to do with = them. >>>=20 >>> All we need say is that in order to work, the header contents has to=20= >>> be >> able to have the canonical e.164 extracted with no knowledge at the=20= >> validator, and validations can occur anywhere in the call path. = We'll=20 >> dress up that text a lot I am sure, but the notion that we could=20 >> write, or need a document describing all possible variations of how=20= >> telephone numbers may appear and how to extract the e.164 in each of=20= >> them > seems to me to be silly. >>>=20 >>> It may be possible to specify an algorithm however. >>>=20 >>> Brian >>>=20 >>> On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >>>=20 >>>> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>>>> Catching up (I was out for a week) >>>>> On Jun 28, 2013, at 7:09 PM, Dave Crocker = wrote: >>>>>=20 >>>>>> The experience with canonicalization algorithms for DKIM -- and=20= >>>>>> it, >> too, had to deal with in-transit modifications -- makes clear that=20 >> it's a topic with challenges and compromises. (Hmmm. "compromises" >> might be a pun, here.) >>>>> e.164s are much more constrained than the email address issues = DKIM=20 >>>>> has >> to deal with. We could have challenges with local dial plans, and=20 >> we've been discussing those issues, but the easy way out on those is=20= >> that they may not be covered if both ends don't understand the dial=20= >> plan > the same way. >>>>>=20 >>>>> So far, while we have one issue I'm concerned with (verifier not=20= >>>>> being >> able to extract a canonical e.164 from the content of "From"), I = don't=20 >> think the DKIM experience is particularly relevant. >>>>=20 >>>>=20 >>>> Brian, >>>>=20 >>>> Thanks. Good to hear. >>>>=20 >>>> I assume there is a document that specifies all of the variations=20= >>>> that >> will be encountered and how to deterministically and successfully=20 >> transform them into the single, canonical representation? >>>>=20 >>>> Absent that, this topic remains a likely source of = non-interoperability. >>>>=20 >>>> d/ >>>>=20 >>>>=20 >>>> -- >>>> Dave Crocker >>>> Brandenburg InternetWorking >>>> bbiw.net >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 From timothy.dwight@verizon.com Wed Jul 3 09:07: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 B197921F9D21 for ; Wed, 3 Jul 2013 09:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 36dd-t384TH0 for ; Wed, 3 Jul 2013 09:07:53 -0700 (PDT) Received: from omzsmtpe01.verizonbusiness.com (omzsmtpe01.verizonbusiness.com [199.249.25.210]) by ietfa.amsl.com (Postfix) with ESMTP id 6924621F9CA7 for ; Wed, 3 Jul 2013 09:07:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by omzsmtpe01.verizonbusiness.com with ESMTP; 03 Jul 2013 16:07:48 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.87,988,1363132800"; d="scan'208";a="501346821" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi02.verizon.com with ESMTP; 03 Jul 2013 16:07:48 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Wed, 3 Jul 2013 12:07:41 -0400 To: "Olle E. Johansson" Date: Wed, 3 Jul 2013 12:07:39 -0400 Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: Ac53++C3rmwz5XbvSda2AZimVMN5wQAAGP0A Message-ID: <2B0F677F0B95454297753F58D4A07FA3012801ECE8@FHDP1LUMXC7V31.us.one.verizon.com> References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <43DFEF36-0A7F-410E-A0A9-854A42BF82C1@edvina.net> In-Reply-To: <43DFEF36-0A7F-410E-A0A9-854A42BF82C1@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "dcrocker@bbiw.net" , Brian Rosen 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: Wed, 03 Jul 2013 16:07:58 -0000 Thanks, Olle. I guess you refer to the use of local (national significant)= numbers? That should have occurred to me. We don't do that in our fixed-= line VoIP networks (we always configure the device signal global (Internati= onal format) E.164 numbers in FROM and TO. But in mobile networks I know i= t is common to assign a temporary number (TLDN) to a visiting device, the f= ormat of which reflects the local numbering plan. Historically this has oc= casionally caused some ambiguity, particularly if the Type of Number indica= tion is somehow lost. Interestingly, the resolution to such ambiguity (oth= er than to not munge the Type of Number indication) is to "canonicalize" th= e TLDN on the originating side. Is that it then? All the use cases with which we're concerned, have to do = with conversions between national significant numbers and global / Internat= ional numbers? If so, I think I understand how and where this 'canonicalization' can be pe= rformed. It is however critically dependent on preservation of Type of Num= ber (on the circuit switched side) and/or proper use and preservation of th= e 'phone-context' URI parameter (on the VoIP side). When Hadriel says "it = must be possible since it works today" he's mostly right. There are occasi= onal cases today where enough things go wrong that at the point of 'canonic= alization' it's unclear whether the number is national or International. B= ut AFAIK that only happens when bad luck compounds protocol errors; and no = specification we write will prevent either of those. tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Oll= e E. Johansson Sent: Wednesday, July 03, 2013 9:45 AM To: Dwight, Timothy M (Tim) Cc: stir@ietf.org; Olle E. Johansson; dcrocker@bbiw.net; Brian Rosen Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) 3 jul 2013 kl. 16:39 skrev "Dwight, Timothy M \(Tim\)" : > Could someone provide a few examples? I have to say I find this thread h= ard to follow. I trust the individuals making the arguments to be knowledg= eable and honest, but personally I have little experience with this "FROM h= eader manipulation" that I'm told is so rampant. =20 >=20 > The only example I can think of is the "SIP trunking" use case I raised p= reviously (user part of URI in FROM and/or TO header may be significant onl= y within the dial plan of the associated Enterprise) which was ruled out of= scope for this activity. So I'm puzzled, what use cases there are that (a= ) are in scope for this exercise, and (b) involve manipulation of the user = part of the URI in the FROM header. >=20 > Apologies in advance if this is obvious to everyone else and I'm the only= one who doesn't "get it". RFC 3966 on the Tel URI got some good reading. http://tools.ietf.org/html/rfc3966#section-5.1.4 Think of it as "anything that starts with a country code". In every platfo= rm I have installed, we have those algorithms. /O >=20 > Thanks, >=20 > Tim >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of B= rian Rosen > Sent: Wednesday, July 03, 2013 9:23 AM > To: dcrocker@bbiw.net > Cc: stir@ietf.org > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR= ) >=20 > There are a lot of local variations out there, but they all have the prop= erty that in order to route them, you need to be able to figure out at leas= t the "left" part of the e.164 is, and the right part has to pass unscathed= in order to work. Since everyone, and I mean everyone, dealing with these= systems knows what e.164s are, and how they work, I don't think it's neces= sary, or even possible to describe all of the various ways the strings migh= t appear and what to do with them. >=20 > All we need say is that in order to work, the header contents has to be a= ble to have the canonical e.164 extracted with no knowledge at the validato= r, and validations can occur anywhere in the call path. We'll dress up tha= t text a lot I am sure, but the notion that we could write, or need a docum= ent describing all possible variations of how telephone numbers may appear = and how to extract the e.164 in each of them seems to me to be silly. >=20 > It may be possible to specify an algorithm however. >=20 > Brian >=20 > On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >=20 >> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>> Catching up (I was out for a week) >>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>=20 >>>> The experience with canonicalization algorithms for DKIM -- and it, to= o, had to deal with in-transit modifications -- makes clear that it's a top= ic with challenges and compromises. (Hmmm. "compromises" might be a pun, = here.) >>> e.164s are much more constrained than the email address issues DKIM has= to deal with. We could have challenges with local dial plans, and we've b= een discussing those issues, but the easy way out on those is that they may= not be covered if both ends don't understand the dial plan the same way. >>>=20 >>> So far, while we have one issue I'm concerned with (verifier not being = able to extract a canonical e.164 from the content of "From"), I don't thin= k the DKIM experience is particularly relevant. >>=20 >>=20 >> Brian, >>=20 >> Thanks. Good to hear. >>=20 >> I assume there is a document that specifies all of the variations that w= ill be encountered and how to deterministically and successfully transform = them into the single, canonical representation? >>=20 >> Absent that, this topic remains a likely source of non-interoperability. >>=20 >> d/ >>=20 >>=20 >> --=20 >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From timothy.dwight@verizon.com Wed Jul 3 09:11: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 A9C2121F9D9B for ; Wed, 3 Jul 2013 09:11: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=[AWL=0.000, 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 2dCxgWYHah58 for ; Wed, 3 Jul 2013 09:10:55 -0700 (PDT) Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) by ietfa.amsl.com (Postfix) with ESMTP id 6598021F9D9A for ; Wed, 3 Jul 2013 09:10:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by omzsmtpe02.verizonbusiness.com with ESMTP; 03 Jul 2013 16:10:54 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.87,988,1363132800"; d="scan'208";a="510301311" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi01.verizon.com with ESMTP; 03 Jul 2013 16:10:54 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Wed, 3 Jul 2013 12:10:54 -0400 To: Brian Rosen Date: Wed, 3 Jul 2013 12:10:52 -0400 Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: Ac53/UkYAsQSeLRQR966UNoYSyV9PQAClpLQ Message-ID: <2B0F677F0B95454297753F58D4A07FA3012801ECEB@FHDP1LUMXC7V31.us.one.verizon.com> References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "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: Wed, 03 Jul 2013 16:11:00 -0000 I don't see a problem with any of those, assuming the phone-context URI par= ameter is properly used. Of course if it's not, and you don't otherwise kn= ow where the call came from (e.g., by a trunk group parameter) you're in tr= ouble. But in that case the problem's unsolvable... which contradicts Hadr= iel's "trust me it works today" assertion. Tim -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, July 03, 2013 9:55 AM To: Dwight, Timothy M (Tim) Cc: dcrocker@bbiw.net; stir@ietf.org Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) The From problem is lack of country codes, and maybe worse. Consider these= possible From: contents=20 5551212 2025551212 12025551212 +12025551212 and of course all the variations with parens, spaces, hyphens, commas, peri= ods, etc. Although the first is getting really rare, I think it still happens The problem with these is when they appear in From on an international call= - the first 2 are the real problems. They would have to be rewritten. With To:, you get the variations with dial 9/8/... in enterprise systems, a= nd the 011 style prefix=20 Brian On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" wrote: > Could someone provide a few examples? I have to say I find this thread h= ard to follow. I trust the individuals making the arguments to be knowledg= eable and honest, but personally I have little experience with this "FROM h= eader manipulation" that I'm told is so rampant. =20 >=20 > The only example I can think of is the "SIP trunking" use case I raised p= reviously (user part of URI in FROM and/or TO header may be significant onl= y within the dial plan of the associated Enterprise) which was ruled out of= scope for this activity. So I'm puzzled, what use cases there are that (a= ) are in scope for this exercise, and (b) involve manipulation of the user = part of the URI in the FROM header. >=20 > Apologies in advance if this is obvious to everyone else and I'm the only= one who doesn't "get it". >=20 > Thanks, >=20 > Tim >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of B= rian Rosen > Sent: Wednesday, July 03, 2013 9:23 AM > To: dcrocker@bbiw.net > Cc: stir@ietf.org > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR= ) >=20 > There are a lot of local variations out there, but they all have the prop= erty that in order to route them, you need to be able to figure out at leas= t the "left" part of the e.164 is, and the right part has to pass unscathed= in order to work. Since everyone, and I mean everyone, dealing with these= systems knows what e.164s are, and how they work, I don't think it's neces= sary, or even possible to describe all of the various ways the strings migh= t appear and what to do with them. >=20 > All we need say is that in order to work, the header contents has to be a= ble to have the canonical e.164 extracted with no knowledge at the validato= r, and validations can occur anywhere in the call path. We'll dress up tha= t text a lot I am sure, but the notion that we could write, or need a docum= ent describing all possible variations of how telephone numbers may appear = and how to extract the e.164 in each of them seems to me to be silly. >=20 > It may be possible to specify an algorithm however. >=20 > Brian >=20 > On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >=20 >> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>> Catching up (I was out for a week) >>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>=20 >>>> The experience with canonicalization algorithms for DKIM -- and it, to= o, had to deal with in-transit modifications -- makes clear that it's a top= ic with challenges and compromises. (Hmmm. "compromises" might be a pun, = here.) >>> e.164s are much more constrained than the email address issues DKIM has= to deal with. We could have challenges with local dial plans, and we've b= een discussing those issues, but the easy way out on those is that they may= not be covered if both ends don't understand the dial plan the same way. >>>=20 >>> So far, while we have one issue I'm concerned with (verifier not being = able to extract a canonical e.164 from the content of "From"), I don't thin= k the DKIM experience is particularly relevant. >>=20 >>=20 >> Brian, >>=20 >> Thanks. Good to hear. >>=20 >> I assume there is a document that specifies all of the variations that w= ill be encountered and how to deterministically and successfully transform = them into the single, canonical representation? >>=20 >> Absent that, this topic remains a likely source of non-interoperability. >>=20 >> d/ >>=20 >>=20 >> --=20 >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From michael.hammer@yaanatech.com Wed Jul 3 09:11: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 2241921F9DA0 for ; Wed, 3 Jul 2013 09:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.211, 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 LIWFPG+0IEel for ; Wed, 3 Jul 2013 09:11: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 9998F21F9D9A for ; Wed, 3 Jul 2013 09:11:08 -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, 3 Jul 2013 09:11:08 -0700 From: Michael Hammer To: "Henning.Schulzrinne@fcc.gov" , "br@brianrosen.net" Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qWRsjPKQFYKEy7+8dmUhlONZlLu4UAgAArZAD//42y0IAAgQkAgABB8ACABz9zAIAABZQAgAADigCAAAR8gIAABGkA//+NhfCAAHktAP//i4pgAA83oYAADZW/QA== Date: Wed, 3 Jul 2013 16:11:06 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC11043@EX2K10MB1.corp.yaanatech.com> References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.96] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00B4_01CE77E6.64D5CE00" MIME-Version: 1.0 Cc: "stir@ietf.org" , "timothy.dwight@verizon.com" , "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: Wed, 03 Jul 2013 16:11:13 -0000 ------=_NextPart_000_00B4_01CE77E6.64D5CE00 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Henning, The Caller-ID argument seems to run along these lines: SS7 PTSN works well, we get good caller ID. SIP world is problematic, we get robo-calling. Because we get good caller ID, we don't need to change how SIP operates today. That is a disconnect for me. Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 11:38 AM To: Michael Hammer; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) We're retreading the same territory, but I don't think anybody is talking about rewriting From. The process is Identity = Hash-and-sign(convert-to-E.164(From)) As long as the receiver can perform the same operation and get the same result, this works. For the reasons now repeated several times, receivers do seem to be able to make sense of inter-provider From information, as they use it mechanically for a variety of purposes. I just don't see the real problem - if From (and their SS7 kin) didn't work, callerID would fail altogether. It obviously doesn't, for almost all calls. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Wednesday, July 03, 2013 11:22 AM To: br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Then that tells me From is the wrong answer. Mike -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, July 03, 2013 11:19 AM To: Michael Hammer Cc: timothy.dwight@verizon.com; stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Sure, but you get that the To has to go through rewrite to get it routed, but the From doesn't. It's all well and good to wave your hands and say "all SIP UAs must put full e.164s in From" but it doesn't happen, and it's not going to happen. Today, rewrites of From happen, but not always to e.164s. We're either going to have to have those rewrites occur always to an e.164, include a full e.164 in a new header, or use P-A-I and require it be a full e.164 (or a combination). Brian On Jul 3, 2013, at 11:13 AM, Michael Hammer wrote: > All, > > It helps to read E.164. > It is a string of digits, max 15, no other characters, with CC, NDC, > and SN. > (There are variations on the names for those parts, but the concept is > the > same.) > If you provide a specification that unambiguously delimits that, you > are golden. > > Do not inject confusion by introducing dialing sting prefixes. > Do not inject confusion by introducing trunking indicators. > Do not inject confusion by introducing methods to group digits. > > If you want the phone number to get anywhere globally, you need to > know how to generate the E.164. > Any domain worth its salt knows how to go from a local representation > to a canonical one. > (And there are local representation secret sauce folks who know how to > do > that.) > > Mike > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: Wednesday, July 03, 2013 10:55 AM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org; dcrocker@bbiw.net > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for > STIR) > > The From problem is lack of country codes, and maybe worse. Consider > these possible From: contents > 5551212 > 2025551212 > 12025551212 > +12025551212 > and of course all the variations with parens, spaces, hyphens, commas, > periods, etc. > > Although the first is getting really rare, I think it still happens > > The problem with these is when they appear in From on an international > call > - the first 2 are the real problems. They would have to be rewritten. > > With To:, you get the variations with dial 9/8/... in enterprise > systems, and the 011 style prefix > > Brian > > > > On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" > wrote: > >> Could someone provide a few examples? I have to say I find this >> thread > hard to follow. I trust the individuals making the arguments to be > knowledgeable and honest, but personally I have little experience with > this "FROM header manipulation" that I'm told is so rampant. >> >> The only example I can think of is the "SIP trunking" use case I >> raised > previously (user part of URI in FROM and/or TO header may be > significant only within the dial plan of the associated Enterprise) > which was ruled out of scope for this activity. So I'm puzzled, what > use cases there are that > (a) are in scope for this exercise, and (b) involve manipulation of > the user part of the URI in the FROM header. >> >> Apologies in advance if this is obvious to everyone else and I'm the >> only > one who doesn't "get it". >> >> Thanks, >> >> Tim >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of > Brian Rosen >> Sent: Wednesday, July 03, 2013 9:23 AM >> To: dcrocker@bbiw.net >> Cc: stir@ietf.org >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for >> STIR) >> >> There are a lot of local variations out there, but they all have the > property that in order to route them, you need to be able to figure > out at least the "left" part of the e.164 is, and the right part has > to pass unscathed in order to work. Since everyone, and I mean > everyone, dealing with these systems knows what e.164s are, and how > they work, I don't think it's necessary, or even possible to describe > all of the various ways the strings might appear and what to do with them. >> >> All we need say is that in order to work, the header contents has to >> be > able to have the canonical e.164 extracted with no knowledge at the > validator, and validations can occur anywhere in the call path. We'll > dress up that text a lot I am sure, but the notion that we could > write, or need a document describing all possible variations of how > telephone numbers may appear and how to extract the e.164 in each of > them seems to me to be silly. >> >> It may be possible to specify an algorithm however. >> >> Brian >> >> On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >> >>> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>>> Catching up (I was out for a week) >>>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>> >>>>> 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.) >>>> e.164s are much more constrained than the email address issues DKIM >>>> has > to deal with. We could have challenges with local dial plans, and > we've been discussing those issues, but the easy way out on those is > that they may not be covered if both ends don't understand the dial > plan the same way. >>>> >>>> So far, while we have one issue I'm concerned with (verifier not >>>> being > able to extract a canonical e.164 from the content of "From"), I don't > think the DKIM experience is particularly relevant. >>> >>> >>> Brian, >>> >>> Thanks. Good to hear. >>> >>> I assume there is a document that specifies all of the variations >>> that > will be encountered and how to deterministically and successfully > transform them into the single, canonical representation? >>> >>> Absent that, this topic remains a likely source of non-interoperability. >>> >>> 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_00B4_01CE77E6.64D5CE00 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcw MzE2MTEwNVowIwYJKoZIhvcNAQkEMRYEFB/N0mVcCsFPBamM+hlZ6SdjumM+MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEActljvK51G3EYxw6fxVU6/vHKMWxEylbS5gEh2moy k/GydrFilko5l9b2uAiC+DBpC/S+GGm44Mwro2zXXV4y7aqdWD9lliGVbamkugEOSK+VGJDpKzmB c9FQFjJy1ybmu0HhjxMPXSJoEZXuU46tsbpkp+TCW9YLCGHXMyqzTSrr4fBk4AVkgyE+RcfuKGyl mMuVHK125hQJ8OUT1QxE/PVJ57lUjBEmdLzowZvvVIr6jWXAZKAESoSptnw3xYvdvfylZfxCg4Xy 8Qh0vGH9H5GCwkIUM/+eYWlliZ0U40esDS8B3S89rsoeXblesQCn7Ft9i2Buqy/1Qdfz75jpMwAA AAAAAA== ------=_NextPart_000_00B4_01CE77E6.64D5CE00-- From hadriel.kaplan@oracle.com Wed Jul 3 09:14:29 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D7A21F9A16 for ; Wed, 3 Jul 2013 09:14:29 -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 UDhg-XlvzbQo for ; Wed, 3 Jul 2013 09:14:23 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 628D221F9A14 for ; Wed, 3 Jul 2013 09:14:23 -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 r63GELuw004401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Jul 2013 16:14:22 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 r63GELD5020818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jul 2013 16:14:21 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r63GELVt026920; Wed, 3 Jul 2013 16:14:21 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Jul 2013 09:14: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: <2B0F677F0B95454297753F58D4A07FA30127F61B26@FHDP1LUMXC7V31.us.one.verizon.com> Date: Wed, 3 Jul 2013 12:14:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0273DC02-8865-4FAE-8CC2-0A44686DA1E8@oracle.com> References: <011501ce7676$79b756c0$6d260440$@shockey.us> <01bc01ce7691$e73f8bc0$b5bea340$@shockey.us> <51D1DC32.1080308@dcrocker.net> <520DE022-7E21-4B31-82E1-D332A2A94E63@oracle.com> <2B0F677F0B95454297753F58D4A07FA30127F61718@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA30127F61B26@FHDP1LUMXC7V31.us.one.verizon.com> To: "Dwight, Timothy M (Tim)" 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] 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, 03 Jul 2013 16:14:30 -0000 On Jul 3, 2013, at 9:54 AM, "Dwight, Timothy M (Tim)" = wrote: > Hadriel, > I thought there was from the outset some notion that compliance would = be made compulsory (by regulators). I assume that's part of what = motivates standardization. Nope. I specifically asked that question, but the answer is no there's = no mandate. That's not to say I don't think we need to do something - we do. > I'm not sure the invocation of this functionality has to be in an = "app", by the way. ISTM it could also be provided by the device OEM as = part of the standard dialer. The latter is more easily achieved if the = API is standardized. Of course - I too would expect that. I can imagine them getting the = data in-band from the carrier, for example. I'm not saying there isn't a market for app-based or even = phone-OEM-based caller-id verification. I'm saying trying to figure out = what the deployment, protocol, API, and requirements are for such a = solution is a waste of time unless we get the actual players for that = involved in the IETF. Imagine if we weren't talking about an in-band solution at all. Instead = we wanted to form STIR purely to define this out-of-band solution. What = would be our chances of success? By "success" I mean both in producing = an RFC as well as getting people to actually deploy and use it. We = don't have those people involved here. The IETF has rarely been = successful without the involvement of those who plan to = use/implement/deploy the stuff. -hadriel From timothy.dwight@verizon.com Wed Jul 3 09:14: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 0558021F9A3A for ; Wed, 3 Jul 2013 09:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 h+nul1GRaTsn for ; Wed, 3 Jul 2013 09:14:45 -0700 (PDT) Received: from omzsmtpe01.verizonbusiness.com (omzsmtpe01.verizonbusiness.com [199.249.25.210]) by ietfa.amsl.com (Postfix) with ESMTP id B079721F9DA3 for ; Wed, 3 Jul 2013 09:14:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by omzsmtpe01.verizonbusiness.com with ESMTP; 03 Jul 2013 16:14:44 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.87,989,1363132800"; d="scan'208";a="510304471" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi01.verizon.com with ESMTP; 03 Jul 2013 16:14:43 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Wed, 3 Jul 2013 12:14:43 -0400 To: Henning Schulzrinne , "'philippe.fouquart@orange.com'" , Brian Rosen Date: Wed, 3 Jul 2013 12:14:42 -0400 Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qfju36ah9Ux0e2HxhSF1PQN5lLiToAgAArZACAAAM/gIAAC30AgABB8ACABz9yAIAABZQAgAADigCAAAR8gIAABGkAgAADuID//76roIAAEHEg Message-ID: <2B0F677F0B95454297753F58D4A07FA3012801ECF6@FHDP1LUMXC7V31.us.one.verizon.com> References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <6435_1372864087_51D43E57_6435_5254_8_B5939C6860701C49AA39C5DA5189448B0B2905@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: "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: Wed, 03 Jul 2013 16:14:50 -0000 I thought we were talking about 'canonicalization' of the URI in the FROM h= eader, at the terminating end. =20 Sorry to have confused the issue. tim -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Wednesday, July 03, 2013 10:19 AM To: 'philippe.fouquart@orange.com'; Brian Rosen; Dwight, Timothy M (Tim) Cc: stir@ietf.org; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) The advantage we have is that the conversion of the From is done close to t= he origin, i.e., by somebody with local knowledge, even if it requires algo= rithms that are country-specific. For the reasons mentioned several times (= CNAM, SS7, intercarrier compensation, voicemail, 911 ALI for wireless, etc.= ), this seems to work well enough in practice, even without a formal standa= rd beyond E.164. I have no objection to describing common cases, but I don'= t think this is a major concern for interoperability as long as everyone ag= rees what the canonical form is. Only the canonical form matters for intero= perability, i.e., the receiver doesn't have to understand in detail how it = was arrived at and how much programmer sweat was involved. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of phi= lippe.fouquart@orange.com Sent: Wednesday, July 03, 2013 11:08 AM To: Brian Rosen; Dwight, Timothy M (Tim) Cc: stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) I agree, I'm not sure I would go as far as calling the idea of defining all= possible variations "silly" but if, as I understand it, the idea was (at l= east) to come up with an algorithm/mapping to describe how a CLI expressed = in the dialing plan (or the national portion of the E.164 number) can be co= nverted into a full E.164 form for example, I think this would indeed be ov= erly ambitious.=20 For example, I regularly deal with a public dialling plan that requires abo= ut 20 if/then/else clauses on the value of the national Subscriber Number t= o do just that. And that's only for one (arguably quite complex yet closed)= national dialling plan. There are more than 200 of these on the planet, ea= ch of which potentially has its own national variations and change over tim= e. 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 Bri= an Rosen Sent: Wednesday, July 03, 2013 4:55 PM To: Dwight, Timothy M (Tim) Cc: stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) The From problem is lack of country codes, and maybe worse. Consider these= possible From: contents 5551212 2025551212 12025551212 +12025551212 and of course all the variations with parens, spaces, hyphens, commas, peri= ods, etc. Although the first is getting really rare, I think it still happens The problem with these is when they appear in From on an international call= - the first 2 are the real problems. They would have to be rewritten. With To:, you get the variations with dial 9/8/... in enterprise systems, a= nd the 011 style prefix=20 Brian On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" wrote: > Could someone provide a few examples? I have to say I find this thread h= ard to follow. I trust the individuals making the arguments to be knowledg= eable and honest, but personally I have little experience with this "FROM h= eader manipulation" that I'm told is so rampant. =20 >=20 > The only example I can think of is the "SIP trunking" use case I raised p= reviously (user part of URI in FROM and/or TO header may be significant onl= y within the dial plan of the associated Enterprise) which was ruled out of= scope for this activity. So I'm puzzled, what use cases there are that (a= ) are in scope for this exercise, and (b) involve manipulation of the user = part of the URI in the FROM header. >=20 > Apologies in advance if this is obvious to everyone else and I'm the only= one who doesn't "get it". >=20 > Thanks, >=20 > Tim >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 > Of Brian Rosen > Sent: Wednesday, July 03, 2013 9:23 AM > To: dcrocker@bbiw.net > Cc: stir@ietf.org > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for > STIR) >=20 > There are a lot of local variations out there, but they all have the prop= erty that in order to route them, you need to be able to figure out at leas= t the "left" part of the e.164 is, and the right part has to pass unscathed= in order to work. Since everyone, and I mean everyone, dealing with these= systems knows what e.164s are, and how they work, I don't think it's neces= sary, or even possible to describe all of the various ways the strings migh= t appear and what to do with them. >=20 > All we need say is that in order to work, the header contents has to be a= ble to have the canonical e.164 extracted with no knowledge at the validato= r, and validations can occur anywhere in the call path. We'll dress up tha= t text a lot I am sure, but the notion that we could write, or need a docum= ent describing all possible variations of how telephone numbers may appear = and how to extract the e.164 in each of them seems to me to be silly. >=20 > It may be possible to specify an algorithm however. >=20 > Brian >=20 > On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >=20 >> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>> Catching up (I was out for a week) >>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>=20 >>>> The experience with canonicalization algorithms for DKIM -- and it,=20 >>>> too, had to deal with in-transit modifications -- makes clear that=20 >>>> it's a topic with challenges and compromises. (Hmmm. >>>> "compromises" might be a pun, here.) >>> e.164s are much more constrained than the email address issues DKIM has= to deal with. We could have challenges with local dial plans, and we've b= een discussing those issues, but the easy way out on those is that they may= not be covered if both ends don't understand the dial plan the same way. >>>=20 >>> So far, while we have one issue I'm concerned with (verifier not being = able to extract a canonical e.164 from the content of "From"), I don't thin= k the DKIM experience is particularly relevant. >>=20 >>=20 >> Brian, >>=20 >> Thanks. Good to hear. >>=20 >> I assume there is a document that specifies all of the variations that w= ill be encountered and how to deterministically and successfully transform = them into the single, canonical representation? >>=20 >> Absent that, this topic remains a likely source of non-interoperability. >>=20 >> d/ >>=20 >>=20 >> -- >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ___________________________________________________________________________= ______________________________________________ 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 From Henning.Schulzrinne@fcc.gov Wed Jul 3 09:26: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 6540C21F9D05 for ; Wed, 3 Jul 2013 09:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[AWL=1.110, 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 WJc3YjggLBC8 for ; Wed, 3 Jul 2013 09:26:20 -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 31D6421F9CE7 for ; Wed, 3 Jul 2013 09:26:19 -0700 (PDT) Message-ID: X-CheckPoint: {51D44F99-9D-D2C987A5-1FFFF} From: Henning Schulzrinne To: Michael Hammer , "br@brianrosen.net" Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qfju36ah9Ux0e2HxhSF1PQN5lLiToAgAArZACAAAM/gIAAC30AgABB8ACABz9yAIAABZQAgAADigCAAAR8gIAABGkAgAAFRQCAAAFtAIAAAQiA//+/2HCAAE2/AP//v9zn Date: Wed, 3 Jul 2013 16:25:01 +0000 References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> , <00C069FD01E0324C9FFCADF539701DB3BBC11043@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC11043@EX2K10MB1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "timothy.dwight@verizon.com" , "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: Wed, 03 Jul 2013 16:26:24 -0000 I don't see the contradiction: Today, we get perfectly-formatted, but subst= antially-false, callerID. Just because it's fake doesn't mean it's bad-look= ing...=0A= =0A= Indeed, the bad guys have every incentive to provide well-formatted numbers= as otherwise the CNAM lookup will fail, defeating the purpose of rendering= plausible textual caller ID information.=0A= =0A= ________________________________________=0A= From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Michael Ha= mmer [michael.hammer@yaanatech.com]=0A= Sent: Wednesday, July 03, 2013 12:11 PM=0A= To: Henning Schulzrinne; br@brianrosen.net=0A= Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net=0A= Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)= =0A= =0A= Henning,=0A= =0A= The Caller-ID argument seems to run along these lines:=0A= =0A= SS7 PTSN works well, we get good caller ID.=0A= SIP world is problematic, we get robo-calling.=0A= Because we get good caller ID, we don't need to change how SIP operates=0A= today.=0A= =0A= That is a disconnect for me.=0A= =0A= Mike=0A= =0A= =0A= -----Original Message-----=0A= From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=0A= Sent: Wednesday, July 03, 2013 11:38 AM=0A= To: Michael Hammer; br@brianrosen.net=0A= Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net=0A= Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)= =0A= =0A= We're retreading the same territory, but I don't think anybody is talking= =0A= about rewriting From. The process is=0A= =0A= Identity =3D Hash-and-sign(convert-to-E.164(From))=0A= =0A= As long as the receiver can perform the same operation and get the same=0A= result, this works. For the reasons now repeated several times, receivers d= o=0A= seem to be able to make sense of inter-provider From information, as they= =0A= use it mechanically for a variety of purposes.=0A= =0A= I just don't see the real problem - if From (and their SS7 kin) didn't work= ,=0A= callerID would fail altogether. It obviously doesn't, for almost all calls.= =0A= =0A= -----Original Message-----=0A= From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of=0A= Michael Hammer=0A= Sent: Wednesday, July 03, 2013 11:22 AM=0A= To: br@brianrosen.net=0A= Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net=0A= Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)= =0A= =0A= Then that tells me From is the wrong answer.=0A= =0A= Mike=0A= =0A= =0A= -----Original Message-----=0A= From: Brian Rosen [mailto:br@brianrosen.net]=0A= Sent: Wednesday, July 03, 2013 11:19 AM=0A= To: Michael Hammer=0A= Cc: timothy.dwight@verizon.com; stir@ietf.org; dcrocker@bbiw.net=0A= Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)= =0A= =0A= Sure, but you get that the To has to go through rewrite to get it routed,= =0A= but the From doesn't.=0A= =0A= It's all well and good to wave your hands and say "all SIP UAs must put ful= l=0A= e.164s in From" but it doesn't happen, and it's not going to happen.=0A= =0A= Today, rewrites of From happen, but not always to e.164s. We're either=0A= going to have to have those rewrites occur always to an e.164, include a=0A= full e.164 in a new header, or use P-A-I and require it be a full e.164 (or= =0A= a combination).=0A= =0A= Brian=0A= =0A= On Jul 3, 2013, at 11:13 AM, Michael Hammer = =0A= wrote:=0A= =0A= > All,=0A= >=0A= > It helps to read E.164.=0A= > It is a string of digits, max 15, no other characters, with CC, NDC,=0A= > and=0A= SN.=0A= > (There are variations on the names for those parts, but the concept is=0A= > the=0A= > same.)=0A= > If you provide a specification that unambiguously delimits that, you=0A= > are golden.=0A= >=0A= > Do not inject confusion by introducing dialing sting prefixes.=0A= > Do not inject confusion by introducing trunking indicators.=0A= > Do not inject confusion by introducing methods to group digits.=0A= >=0A= > If you want the phone number to get anywhere globally, you need to=0A= > know how to generate the E.164.=0A= > Any domain worth its salt knows how to go from a local representation=0A= > to a canonical one.=0A= > (And there are local representation secret sauce folks who know how to=0A= > do=0A= > that.)=0A= >=0A= > Mike=0A= >=0A= >=0A= > -----Original Message-----=0A= > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=0A= > Of Brian Rosen=0A= > Sent: Wednesday, July 03, 2013 10:55 AM=0A= > To: Dwight, Timothy M (Tim)=0A= > Cc: stir@ietf.org; dcrocker@bbiw.net=0A= > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for=0A= > STIR)=0A= >=0A= > The From problem is lack of country codes, and maybe worse. Consider=0A= > these possible From: contents=0A= > 5551212=0A= > 2025551212=0A= > 12025551212=0A= > +12025551212=0A= > and of course all the variations with parens, spaces, hyphens, commas,=0A= > periods, etc.=0A= >=0A= > Although the first is getting really rare, I think it still happens=0A= >=0A= > The problem with these is when they appear in From on an international=0A= > call=0A= > - the first 2 are the real problems. They would have to be rewritten.=0A= >=0A= > With To:, you get the variations with dial 9/8/... in enterprise=0A= > systems, and the 011 style prefix=0A= >=0A= > Brian=0A= >=0A= >=0A= >=0A= > On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)"=0A= > wrote:=0A= >=0A= >> Could someone provide a few examples? I have to say I find this=0A= >> thread=0A= > hard to follow. I trust the individuals making the arguments to be=0A= > knowledgeable and honest, but personally I have little experience with=0A= > this "FROM header manipulation" that I'm told is so rampant.=0A= >>=0A= >> The only example I can think of is the "SIP trunking" use case I=0A= >> raised=0A= > previously (user part of URI in FROM and/or TO header may be=0A= > significant only within the dial plan of the associated Enterprise)=0A= > which was ruled out of scope for this activity. So I'm puzzled, what=0A= > use cases there are that=0A= > (a) are in scope for this exercise, and (b) involve manipulation of=0A= > the user part of the URI in the FROM header.=0A= >>=0A= >> Apologies in advance if this is obvious to everyone else and I'm the=0A= >> only=0A= > one who doesn't "get it".=0A= >>=0A= >> Thanks,=0A= >>=0A= >> Tim=0A= >>=0A= >> -----Original Message-----=0A= >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=0A= >> Of=0A= > Brian Rosen=0A= >> Sent: Wednesday, July 03, 2013 9:23 AM=0A= >> To: dcrocker@bbiw.net=0A= >> Cc: stir@ietf.org=0A= >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for=0A= >> STIR)=0A= >>=0A= >> There are a lot of local variations out there, but they all have the=0A= > property that in order to route them, you need to be able to figure=0A= > out at least the "left" part of the e.164 is, and the right part has=0A= > to pass unscathed in order to work. Since everyone, and I mean=0A= > everyone, dealing with these systems knows what e.164s are, and how=0A= > they work, I don't think it's necessary, or even possible to describe=0A= > all of the various ways the strings might appear and what to do with them= .=0A= >>=0A= >> All we need say is that in order to work, the header contents has to=0A= >> be=0A= > able to have the canonical e.164 extracted with no knowledge at the=0A= > validator, and validations can occur anywhere in the call path. We'll=0A= > dress up that text a lot I am sure, but the notion that we could=0A= > write, or need a document describing all possible variations of how=0A= > telephone numbers may appear and how to extract the e.164 in each of=0A= > them=0A= seems to me to be silly.=0A= >>=0A= >> It may be possible to specify an algorithm however.=0A= >>=0A= >> Brian=0A= >>=0A= >> On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote:=0A= >>=0A= >>> On 7/3/2013 6:50 AM, Brian Rosen wrote:=0A= >>>> Catching up (I was out for a week)=0A= >>>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote:=0A= >>>>=0A= >>>>> The experience with canonicalization algorithms for DKIM -- and=0A= >>>>> it,=0A= > too, had to deal with in-transit modifications -- makes clear that=0A= > it's a topic with challenges and compromises. (Hmmm. "compromises"=0A= > might be a pun, here.)=0A= >>>> e.164s are much more constrained than the email address issues DKIM=0A= >>>> has=0A= > to deal with. We could have challenges with local dial plans, and=0A= > we've been discussing those issues, but the easy way out on those is=0A= > that they may not be covered if both ends don't understand the dial=0A= > plan=0A= the same way.=0A= >>>>=0A= >>>> So far, while we have one issue I'm concerned with (verifier not=0A= >>>> being=0A= > able to extract a canonical e.164 from the content of "From"), I don't=0A= > think the DKIM experience is particularly relevant.=0A= >>>=0A= >>>=0A= >>> Brian,=0A= >>>=0A= >>> Thanks. Good to hear.=0A= >>>=0A= >>> I assume there is a document that specifies all of the variations=0A= >>> that=0A= > will be encountered and how to deterministically and successfully=0A= > transform them into the single, canonical representation?=0A= >>>=0A= >>> Absent that, this topic remains a likely source of non-interoperability= .=0A= >>>=0A= >>> d/=0A= >>>=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= >=0A= > _______________________________________________=0A= > stir mailing list=0A= > stir@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/stir=0A= > _______________________________________________=0A= > stir mailing list=0A= > stir@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/stir=0A= =0A= From hadriel.kaplan@oracle.com Wed Jul 3 09:49: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 79E2D21F99AF for ; Wed, 3 Jul 2013 09:49:42 -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 zFv0zs+z1iU1 for ; Wed, 3 Jul 2013 09:49:36 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0957F21F9A16 for ; Wed, 3 Jul 2013 09:49:35 -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 r63Gh8UR017940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Jul 2013 16:43:09 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 r63GnRPX019304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jul 2013 16:49:27 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 r63GnQZ6018442; Wed, 3 Jul 2013 16:49:26 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Jul 2013 09:49: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: <00C069FD01E0324C9FFCADF539701DB3BBC11043@EX2K10MB1.corp.yaanatech.com> Date: Wed, 3 Jul 2013 12:49:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <674D7D15-D1BD-4C30-9E08-1CCF6F642460@oracle.com> References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC11043@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" , "br@brianrosen.net" , "dcrocker@bbiw.net" , "timothy.dwight@verizon.com" , "Henning.Schulzrinne@fcc.gov" 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: Wed, 03 Jul 2013 16:49:42 -0000 Both SIP and SS7 get caller-id's they recognize/treat/process as E.164 = phone-numbers. Both SIP and SS7 get caller-ids that do not actually belong to the = source of the call request. When investigated, it turns out that the problem is not that the sources = meant to say X while the receiver believed they said Y. Instead, the = sources meant to say Y and the receiver understood it to be Y. The = problem is the source isn't actually authorized to claim Y. -hadriel On Jul 3, 2013, at 12:11 PM, Michael Hammer = wrote: > Henning, >=20 > The Caller-ID argument seems to run along these lines: >=20 > SS7 PTSN works well, we get good caller ID. > SIP world is problematic, we get robo-calling. > Because we get good caller ID, we don't need to change how SIP = operates > today. >=20 > That is a disconnect for me. >=20 > Mike >=20 From Henning.Schulzrinne@fcc.gov Wed Jul 3 09:51: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 5F85D11E81F8 for ; Wed, 3 Jul 2013 09:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.563 X-Spam-Level: X-Spam-Status: No, score=-1.563 tagged_above=-999 required=5 tests=[AWL=1.036, 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 553dGASkothL for ; Wed, 3 Jul 2013 09:51:53 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 6A32511E80F2 for ; Wed, 3 Jul 2013 09:51:48 -0700 (PDT) Message-ID: X-CheckPoint: {51D45616-75-D2C987A5-1FFFF} From: Henning Schulzrinne To: "Dwight, Timothy M (Tim)" , Hadriel Kaplan Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObffB01fXrRHtXUWe5nyT4KMtCplA/mcAgARfFAD//9WzZYAARyoA///B17GAAQ/TgIAAYW+AgAA/UICAAAVDgIAABX+AgAF0k4CAAx4NgIAAB9CAgAAC/wCAABpmgIAAAXSAgAL2fjWAAEZUgP//wDsbAAoVkYD//73B+4AARjaAgAACS4CAAADvAIAAAy0AgAEeuYCAACxzAIAAJtEAgAAQCQCAAAMaAIAAQIdwgABvF4D//4YzQP//CVtQ//4Q/BAAjXgWAAAg2CEAAAJ2WDU= Date: Wed, 3 Jul 2013 16:49:48 +0000 References: <011501ce7676$79b756c0$6d260440$@shockey.us> <01bc01ce7691$e73f8bc0$b5bea340$@shockey.us> <51D1DC32.1080308@dcrocker.net> <520DE022-7E21-4B31-82E1-D332A2A94E63@oracle.com> <2B0F677F0B95454297753F58D4A07FA30127F61718@FHDP1LUMXC7V31.us.one.verizon.com> , <2B0F677F0B95454297753F58D4A07FA30127F61B26@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA30127F61B26@FHDP1LUMXC7V31.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] 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, 03 Jul 2013 16:51:57 -0000 We generally don't do well attracting small software/app vendors to the IET= F, but I could imagine that standards would lower the bar to entry, since n= ot every such provider will have to get all originating providers to provid= e call information (and each originating provider would have to deal with m= ultiple entities). =0A= =0A= I wouldn't be surprised if organizations represented on this mailing list w= ould be interested in providing such a service, but they are not likely to = step up and announce their tentative business plans.=0A= =0A= ________________________________________=0A= From: Dwight, Timothy M (Tim) [timothy.dwight@verizon.com]=0A= Sent: Wednesday, July 03, 2013 9:54 AM=0A= To: Hadriel Kaplan; Henning Schulzrinne=0A= Cc: stir@ietf.org=0A= Subject: RE: [stir] Out-of-band vs. in-band=0A= =0A= Hadriel,=0A= =0A= I thought there was from the outset some notion that compliance would be ma= de compulsory (by regulators). I assume that's part of what motivates stan= dardization.=0A= =0A= I'm not sure the invocation of this functionality has to be in an "app", by= the way. ISTM it could also be provided by the device OEM as part of the = standard dialer. The latter is more easily achieved if the API is standard= ized.=0A= =0A= Both options may be viable of course. For example some OEMs might provide = this functionality in some smart phones, whereas users of older phones migh= t need to download the functionality in the form of an app.=0A= =0A= I do agree that it would be difficult at this stage to standardize a "fancy= " app, that provided the type of additional information about the caller yo= u list below. IMHO if we attempt to standardize any API it should be a "mi= nimalist" one that only supports calling party verification. This would no= t of course preclude 3rd parties from wrapping that API in one of their own= and augmenting the information provided to the user.=0A= =0A= tim=0A= =0A= =0A= -----Original Message-----=0A= From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Had= riel Kaplan=0A= Sent: Tuesday, July 02, 2013 5:14 PM=0A= To: Henning Schulzrinne=0A= Cc: stir@ietf.org; Dwight, Timothy M (Tim)=0A= Subject: Re: [stir] Out-of-band vs. in-band=0A= =0A= =0A= I'm not in the business of providing smart-phone apps, but ISTM most of the= successful ones are free. They're often provided for free by the company = that provides the "database" or service (for lack of a better term to descr= ibe the stuff on the Internet-side). The actual money comes from other sou= rces.=0A= =0A= In this caller-id verification case, I would assume the money for such a "d= atabase" service either comes from callers who would be willing to pay (e.g= ., banks, airlines, etc.), or from the carriers.=0A= =0A= So why would the "database" service even *want* a standard to follow? They= 'll make the app themselves and give it out for free, and they'll decide ho= w the app gets its info and what features it needs to have and so on. They= 'll likely want to provide far more than a simple caller-id. For example t= hey would want to provide a calling name, website, email address, and other= contact-card info; maybe even a picture or brand logo/icon. We don't know= what they'd want, and such a company wouldn't want to wait for a standard = to tell them what/how.=0A= =0A= Standards are only necessary and useful if more than one manufacturer/servi= ce/vendor needs and wants to interoperate with another. So unless you get = multiple of these database providers to participate in the IETF, and tell u= s what they want and how they want it, I don't see the point of repeating t= he ATOCA working group in STIR.=0A= =0A= -hadriel=0A= =0A= =0A= On Jul 2, 2013, at 1:57 PM, Henning Schulzrinne wrote:=0A= =0A= > Thanks for emphasizing this. The current CNAM-style model would indeed on= ly apply to validation by the terminating carrier, but the basic model of h= aving multiple intermediaries that are not carriers offer database access s= ervices seems to be more general. (In the CNAM case, it's probably less a t= echnical reason, but rather that their business model of dip charges doesn'= t really work for consumer access. You could imagine various intermediary m= odels - the app vendor contracts with the database provider and pays for bu= lk access based on their subscription or advertising revenue, for example.)= =0A= =0A= _______________________________________________=0A= stir mailing list=0A= stir@ietf.org=0A= https://www.ietf.org/mailman/listinfo/stir=0A= From timothy.dwight@verizon.com Wed Jul 3 09:52: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 375D621F9D86 for ; Wed, 3 Jul 2013 09:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 oBv+DMt1Lf7S for ; Wed, 3 Jul 2013 09:52:45 -0700 (PDT) Received: from omzsmtpe01.verizonbusiness.com (omzsmtpe01.verizonbusiness.com [199.249.25.210]) by ietfa.amsl.com (Postfix) with ESMTP id 5E30E11E81EC for ; Wed, 3 Jul 2013 09:52:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by omzsmtpe01.verizonbusiness.com with ESMTP; 03 Jul 2013 16:52:41 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.87,989,1363132800"; d="scan'208";a="501392824" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi02.verizon.com with ESMTP; 03 Jul 2013 16:52:41 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Wed, 3 Jul 2013 12:52:40 -0400 To: Henning Schulzrinne , 'Michael Hammer' , "br@brianrosen.net" Date: Wed, 3 Jul 2013 12:52:38 -0400 Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qfju36ah9Ux0e2HxhSF1PQN5lLiToAgAArZACAAAM/gIAAC30AgABB8ACABz9yAIAABZQAgAADigCAAAR8gIAABGkAgAAFRQCAAAFtAIAAAQiA//+/2HCAAAx98A== Message-ID: <2B0F677F0B95454297753F58D4A07FA3012801ED45@FHDP1LUMXC7V31.us.one.verizon.com> References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "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: Wed, 03 Jul 2013 16:52:50 -0000 Ah, so I wasn't as confused as I thought. Good to know. We are talking ab= out being able to translate the value in the FROM header to an Internationa= l E.164 number, on the terminating side of the call. Not over-write the va= lue in the message, but the 'convert-to-E.164' function has to return the s= ame value on the terminating side as it did on the originating side. So I'm back to my previous position - this is indeed possible, assuming eno= ugh contextual information is present. Which in general it must be since a= s Hadriel repeatedly assures us, this all (usually) works today. =20 The nature of the contextual information is different in SIP though. If pe= ople are going to signal FROM headers with national significant numbers in = the user part, they (or something in the path on the originating leg) had b= etter be religious about appending the phone-context parameter, so that on = the terminating leg it's possible to know what they meant. tim=20 -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Wednesday, July 03, 2013 10:38 AM To: 'Michael Hammer'; br@brianrosen.net Cc: stir@ietf.org; Dwight, Timothy M (Tim); dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) We're retreading the same territory, but I don't think anybody is talking a= bout rewriting From. The process is Identity =3D Hash-and-sign(convert-to-E.164(From)) As long as the receiver can perform the same operation and get the same res= ult, this works. For the reasons now repeated several times, receivers do s= eem to be able to make sense of inter-provider From information, as they us= e it mechanically for a variety of purposes. I just don't see the real problem - if From (and their SS7 kin) didn't work= , callerID would fail altogether. It obviously doesn't, for almost all call= s. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Mic= hael Hammer Sent: Wednesday, July 03, 2013 11:22 AM To: br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Then that tells me From is the wrong answer. Mike -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, July 03, 2013 11:19 AM To: Michael Hammer Cc: timothy.dwight@verizon.com; stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Sure, but you get that the To has to go through rewrite to get it routed, b= ut the From doesn't. It's all well and good to wave your hands and say "all SIP UAs must put ful= l e.164s in From" but it doesn't happen, and it's not going to happen. Today, rewrites of From happen, but not always to e.164s. We're either goi= ng to have to have those rewrites occur always to an e.164, include a full = e.164 in a new header, or use P-A-I and require it be a full e.164 (or a co= mbination). Brian On Jul 3, 2013, at 11:13 AM, Michael Hammer wrote: > All, >=20 > It helps to read E.164. > It is a string of digits, max 15, no other characters, with CC, NDC,=20 > and SN. > (There are variations on the names for those parts, but the concept is=20 > the > same.) > If you provide a specification that unambiguously delimits that, you=20 > are golden. >=20 > Do not inject confusion by introducing dialing sting prefixes. > Do not inject confusion by introducing trunking indicators. > Do not inject confusion by introducing methods to group digits. >=20 > If you want the phone number to get anywhere globally, you need to=20 > know how to generate the E.164. > Any domain worth its salt knows how to go from a local representation=20 > to a canonical one. > (And there are local representation secret sauce folks who know how to=20 > do > that.) >=20 > Mike >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 > Of Brian Rosen > Sent: Wednesday, July 03, 2013 10:55 AM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org; dcrocker@bbiw.net > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for > STIR) >=20 > The From problem is lack of country codes, and maybe worse. Consider=20 > these possible From: contents > 5551212 > 2025551212 > 12025551212 > +12025551212 > and of course all the variations with parens, spaces, hyphens, commas,=20 > periods, etc. >=20 > Although the first is getting really rare, I think it still happens >=20 > The problem with these is when they appear in From on an international=20 > call > - the first 2 are the real problems. They would have to be rewritten. >=20 > With To:, you get the variations with dial 9/8/... in enterprise=20 > systems, and the 011 style prefix >=20 > Brian >=20 >=20 >=20 > On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" > wrote: >=20 >> Could someone provide a few examples? I have to say I find this=20 >> thread > hard to follow. I trust the individuals making the arguments to be=20 > knowledgeable and honest, but personally I have little experience with=20 > this "FROM header manipulation" that I'm told is so rampant. >>=20 >> The only example I can think of is the "SIP trunking" use case I=20 >> raised > previously (user part of URI in FROM and/or TO header may be=20 > significant only within the dial plan of the associated Enterprise)=20 > which was ruled out of scope for this activity. So I'm puzzled, what=20 > use cases there are that > (a) are in scope for this exercise, and (b) involve manipulation of=20 > the user part of the URI in the FROM header. >>=20 >> Apologies in advance if this is obvious to everyone else and I'm the=20 >> only > one who doesn't "get it". >>=20 >> Thanks, >>=20 >> Tim >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of > Brian Rosen >> Sent: Wednesday, July 03, 2013 9:23 AM >> To: dcrocker@bbiw.net >> Cc: stir@ietf.org >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for >> STIR) >>=20 >> There are a lot of local variations out there, but they all have the > property that in order to route them, you need to be able to figure=20 > out at least the "left" part of the e.164 is, and the right part has=20 > to pass unscathed in order to work. Since everyone, and I mean=20 > everyone, dealing with these systems knows what e.164s are, and how=20 > they work, I don't think it's necessary, or even possible to describe=20 > all of the various ways the strings might appear and what to do with them= . >>=20 >> All we need say is that in order to work, the header contents has to=20 >> be > able to have the canonical e.164 extracted with no knowledge at the=20 > validator, and validations can occur anywhere in the call path. We'll=20 > dress up that text a lot I am sure, but the notion that we could=20 > write, or need a document describing all possible variations of how=20 > telephone numbers may appear and how to extract the e.164 in each of=20 > them seems to me to be silly. >>=20 >> It may be possible to specify an algorithm however. >>=20 >> Brian >>=20 >> On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >>=20 >>> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>>> Catching up (I was out for a week) >>>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>>=20 >>>>> The experience with canonicalization algorithms for DKIM -- and=20 >>>>> it, > too, had to deal with in-transit modifications -- makes clear that=20 > it's a topic with challenges and compromises. (Hmmm. "compromises" > might be a pun, here.) >>>> e.164s are much more constrained than the email address issues DKIM=20 >>>> has > to deal with. We could have challenges with local dial plans, and=20 > we've been discussing those issues, but the easy way out on those is=20 > that they may not be covered if both ends don't understand the dial=20 > plan the same way. >>>>=20 >>>> So far, while we have one issue I'm concerned with (verifier not=20 >>>> being > able to extract a canonical e.164 from the content of "From"), I don't=20 > think the DKIM experience is particularly relevant. >>>=20 >>>=20 >>> Brian, >>>=20 >>> Thanks. Good to hear. >>>=20 >>> I assume there is a document that specifies all of the variations=20 >>> that > will be encountered and how to deterministically and successfully=20 > transform them into the single, canonical representation? >>>=20 >>> Absent that, this topic remains a likely source of non-interoperability= . >>>=20 >>> d/ >>>=20 >>>=20 >>> -- >>> Dave Crocker >>> Brandenburg InternetWorking >>> bbiw.net >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From michael.hammer@yaanatech.com Wed Jul 3 10:07: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 9AE7B21F9CDF for ; Wed, 3 Jul 2013 10:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.190, 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 wbe7Ll4LnKav for ; Wed, 3 Jul 2013 10:07: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 066D421F9C25 for ; Wed, 3 Jul 2013 10:07:05 -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, 3 Jul 2013 10:07:04 -0700 From: Michael Hammer To: "Henning.Schulzrinne@fcc.gov" , "br@brianrosen.net" Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qWRsjPKQFYKEy7+8dmUhlONZlLu4UAgAArZAD//42y0IAAgQkAgABB8ACABz9zAIAABZQAgAADigCAAAR8gIAABGkA//+NhfCAAHktAP//i4pgAA83oYAADZW/QP//oI2AgABqTFA= Date: Wed, 3 Jul 2013 17:07:04 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC110E6@EX2K10MB1.corp.yaanatech.com> References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> , <00C069FD01E0324C9FFCADF539701DB3BBC11043@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.96] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00D1_01CE77EE.35D4E6B0" MIME-Version: 1.0 Cc: "stir@ietf.org" , "timothy.dwight@verizon.com" , "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: Wed, 03 Jul 2013 17:07:15 -0000 ------=_NextPart_000_00D1_01CE77EE.35D4E6B0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Yes, but where are the false data being injected? Also, these are links in a chain, that if one fails, the follow-on checks will also fail. If you have a large number of failures for valid users, then the recipient cannot rely on the feature. And, the end result is the same, meager adoption. Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 12:25 PM To: Michael Hammer; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) I don't see the contradiction: Today, we get perfectly-formatted, but substantially-false, callerID. Just because it's fake doesn't mean it's bad-looking... Indeed, the bad guys have every incentive to provide well-formatted numbers as otherwise the CNAM lookup will fail, defeating the purpose of rendering plausible textual caller ID information. ________________________________________ From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Michael Hammer [michael.hammer@yaanatech.com] Sent: Wednesday, July 03, 2013 12:11 PM To: Henning Schulzrinne; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Henning, The Caller-ID argument seems to run along these lines: SS7 PTSN works well, we get good caller ID. SIP world is problematic, we get robo-calling. Because we get good caller ID, we don't need to change how SIP operates today. That is a disconnect for me. Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 11:38 AM To: Michael Hammer; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) We're retreading the same territory, but I don't think anybody is talking about rewriting From. The process is Identity = Hash-and-sign(convert-to-E.164(From)) As long as the receiver can perform the same operation and get the same result, this works. For the reasons now repeated several times, receivers do seem to be able to make sense of inter-provider From information, as they use it mechanically for a variety of purposes. I just don't see the real problem - if From (and their SS7 kin) didn't work, callerID would fail altogether. It obviously doesn't, for almost all calls. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Wednesday, July 03, 2013 11:22 AM To: br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Then that tells me From is the wrong answer. Mike -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, July 03, 2013 11:19 AM To: Michael Hammer Cc: timothy.dwight@verizon.com; stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Sure, but you get that the To has to go through rewrite to get it routed, but the From doesn't. It's all well and good to wave your hands and say "all SIP UAs must put full e.164s in From" but it doesn't happen, and it's not going to happen. Today, rewrites of From happen, but not always to e.164s. We're either going to have to have those rewrites occur always to an e.164, include a full e.164 in a new header, or use P-A-I and require it be a full e.164 (or a combination). Brian On Jul 3, 2013, at 11:13 AM, Michael Hammer wrote: > All, > > It helps to read E.164. > It is a string of digits, max 15, no other characters, with CC, NDC, > and SN. > (There are variations on the names for those parts, but the concept is > the > same.) > If you provide a specification that unambiguously delimits that, you > are golden. > > Do not inject confusion by introducing dialing sting prefixes. > Do not inject confusion by introducing trunking indicators. > Do not inject confusion by introducing methods to group digits. > > If you want the phone number to get anywhere globally, you need to > know how to generate the E.164. > Any domain worth its salt knows how to go from a local representation > to a canonical one. > (And there are local representation secret sauce folks who know how to > do > that.) > > Mike > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: Wednesday, July 03, 2013 10:55 AM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org; dcrocker@bbiw.net > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for > STIR) > > The From problem is lack of country codes, and maybe worse. Consider > these possible From: contents > 5551212 > 2025551212 > 12025551212 > +12025551212 > and of course all the variations with parens, spaces, hyphens, commas, > periods, etc. > > Although the first is getting really rare, I think it still happens > > The problem with these is when they appear in From on an international > call > - the first 2 are the real problems. They would have to be rewritten. > > With To:, you get the variations with dial 9/8/... in enterprise > systems, and the 011 style prefix > > Brian > > > > On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" > wrote: > >> Could someone provide a few examples? I have to say I find this >> thread > hard to follow. I trust the individuals making the arguments to be > knowledgeable and honest, but personally I have little experience with > this "FROM header manipulation" that I'm told is so rampant. >> >> The only example I can think of is the "SIP trunking" use case I >> raised > previously (user part of URI in FROM and/or TO header may be > significant only within the dial plan of the associated Enterprise) > which was ruled out of scope for this activity. So I'm puzzled, what > use cases there are that > (a) are in scope for this exercise, and (b) involve manipulation of > the user part of the URI in the FROM header. >> >> Apologies in advance if this is obvious to everyone else and I'm the >> only > one who doesn't "get it". >> >> Thanks, >> >> Tim >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of > Brian Rosen >> Sent: Wednesday, July 03, 2013 9:23 AM >> To: dcrocker@bbiw.net >> Cc: stir@ietf.org >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for >> STIR) >> >> There are a lot of local variations out there, but they all have the > property that in order to route them, you need to be able to figure > out at least the "left" part of the e.164 is, and the right part has > to pass unscathed in order to work. Since everyone, and I mean > everyone, dealing with these systems knows what e.164s are, and how > they work, I don't think it's necessary, or even possible to describe > all of the various ways the strings might appear and what to do with them. >> >> All we need say is that in order to work, the header contents has to >> be > able to have the canonical e.164 extracted with no knowledge at the > validator, and validations can occur anywhere in the call path. We'll > dress up that text a lot I am sure, but the notion that we could > write, or need a document describing all possible variations of how > telephone numbers may appear and how to extract the e.164 in each of > them seems to me to be silly. >> >> It may be possible to specify an algorithm however. >> >> Brian >> >> On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >> >>> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>>> Catching up (I was out for a week) >>>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>> >>>>> 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.) >>>> e.164s are much more constrained than the email address issues DKIM >>>> has > to deal with. We could have challenges with local dial plans, and > we've been discussing those issues, but the easy way out on those is > that they may not be covered if both ends don't understand the dial > plan the same way. >>>> >>>> So far, while we have one issue I'm concerned with (verifier not >>>> being > able to extract a canonical e.164 from the content of "From"), I don't > think the DKIM experience is particularly relevant. >>> >>> >>> Brian, >>> >>> Thanks. Good to hear. >>> >>> I assume there is a document that specifies all of the variations >>> that > will be encountered and how to deterministically and successfully > transform them into the single, canonical representation? >>> >>> Absent that, this topic remains a likely source of non-interoperability. >>> >>> 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_00D1_01CE77EE.35D4E6B0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcw MzE3MDcwMlowIwYJKoZIhvcNAQkEMRYEFIeyOr/ZEzr2AlfV6RWY97zOUke3MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAUQNXY6EiPzfhmxCQQe/BvIPik9MXlRPgaQClZM8A +VUy6tgJ3D53nB9vF+8EXinPi43YA4WGzctHxzJyym6n3ob8Wh4Q/AGBlTAzwcmHprBnBnRbnQw3 TORdVx+r7+yjBFqAKItbZf223zp9GbXAdZcxs19V/aE4oCpp9U7iF2Co7Le8LpHrVLF+ofAfnfan WWC1tlWO6zJFzU0xquqhEBlBs8B82GEjbIZBbmwSHycaLVVUzg148KZq9gnQ0f/FdsnNfaN2wViH dRBxeU9vt+oIZWT7WOgj6OzlnA1Luinz+AkYIT0Ud9JJxFA1t9WZm0B7m21cltMZbV4Qa6yYyQAA AAAAAA== ------=_NextPart_000_00D1_01CE77EE.35D4E6B0-- From timothy.dwight@verizon.com Wed Jul 3 10: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 67B1E21F9C25 for ; Wed, 3 Jul 2013 10:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 5ygVMrUmKGrP for ; Wed, 3 Jul 2013 10:07:43 -0700 (PDT) Received: from omzsmtpe01.verizonbusiness.com (omzsmtpe01.verizonbusiness.com [199.249.25.210]) by ietfa.amsl.com (Postfix) with ESMTP id C995621F9D8C for ; Wed, 3 Jul 2013 10:07:42 -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; 03 Jul 2013 17:07:42 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.87,989,1363132800"; d="scan'208";a="502305791" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi03.verizon.com with ESMTP; 03 Jul 2013 17:07:41 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Wed, 3 Jul 2013 13:07:41 -0400 To: Henning Schulzrinne , Michael Hammer , "br@brianrosen.net" Date: Wed, 3 Jul 2013 13:07:40 -0400 Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qfju36ah9Ux0e2HxhSF1PQN5lLiToAgAArZACAAAM/gIAAC30AgABB8ACABz9yAIAABZQAgAADigCAAAR8gIAABGkAgAAFRQCAAAFtAIAAAQiA//+/2HCAAE2/AP//v9zngAAKAgA= Message-ID: <2B0F677F0B95454297753F58D4A07FA3012801ED65@FHDP1LUMXC7V31.us.one.verizon.com> References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> , <00C069FD01E0324C9FFCADF539701DB3BBC11043@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "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: Wed, 03 Jul 2013 17:07:48 -0000 Actually in networks with which I am familiar, the CNAM lookup is performed= based on the URI in the P-A-ID header (if it's present). Until / unless t= he caller finds a way to spoof that header, they can't 'finish the job' of = pretending to be someone they're not. Of course today there is a loophole provided by entities-that-resemble-carr= iers, who don't meaningfully populate P-A-ID (I say 'meaningfully' to inten= tionally rule out nonsense like all zero's). If you were doing this type o= f mischief I guess you'd seek out such an entity. =20 tim -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Wednesday, July 03, 2013 11:25 AM To: Michael Hammer; br@brianrosen.net Cc: stir@ietf.org; Dwight, Timothy M (Tim); dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) I don't see the contradiction: Today, we get perfectly-formatted, but subst= antially-false, callerID. Just because it's fake doesn't mean it's bad-look= ing... Indeed, the bad guys have every incentive to provide well-formatted numbers= as otherwise the CNAM lookup will fail, defeating the purpose of rendering= plausible textual caller ID information. ________________________________________ From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Michael Ha= mmer [michael.hammer@yaanatech.com] Sent: Wednesday, July 03, 2013 12:11 PM To: Henning Schulzrinne; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Henning, The Caller-ID argument seems to run along these lines: SS7 PTSN works well, we get good caller ID. SIP world is problematic, we get robo-calling. Because we get good caller ID, we don't need to change how SIP operates tod= ay. That is a disconnect for me. Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 11:38 AM To: Michael Hammer; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) We're retreading the same territory, but I don't think anybody is talking a= bout rewriting From. The process is Identity =3D Hash-and-sign(convert-to-E.164(From)) As long as the receiver can perform the same operation and get the same res= ult, this works. For the reasons now repeated several times, receivers do s= eem to be able to make sense of inter-provider From information, as they us= e it mechanically for a variety of purposes. I just don't see the real problem - if From (and their SS7 kin) didn't work= , callerID would fail altogether. It obviously doesn't, for almost all call= s. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Mic= hael Hammer Sent: Wednesday, July 03, 2013 11:22 AM To: br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Then that tells me From is the wrong answer. Mike -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, July 03, 2013 11:19 AM To: Michael Hammer Cc: timothy.dwight@verizon.com; stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Sure, but you get that the To has to go through rewrite to get it routed, b= ut the From doesn't. It's all well and good to wave your hands and say "all SIP UAs must put ful= l e.164s in From" but it doesn't happen, and it's not going to happen. Today, rewrites of From happen, but not always to e.164s. We're either goi= ng to have to have those rewrites occur always to an e.164, include a full = e.164 in a new header, or use P-A-I and require it be a full e.164 (or a co= mbination). Brian On Jul 3, 2013, at 11:13 AM, Michael Hammer wrote: > All, > > It helps to read E.164. > It is a string of digits, max 15, no other characters, with CC, NDC,=20 > and SN. > (There are variations on the names for those parts, but the concept is=20 > the > same.) > If you provide a specification that unambiguously delimits that, you=20 > are golden. > > Do not inject confusion by introducing dialing sting prefixes. > Do not inject confusion by introducing trunking indicators. > Do not inject confusion by introducing methods to group digits. > > If you want the phone number to get anywhere globally, you need to=20 > know how to generate the E.164. > Any domain worth its salt knows how to go from a local representation=20 > to a canonical one. > (And there are local representation secret sauce folks who know how to=20 > do > that.) > > Mike > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 > Of Brian Rosen > Sent: Wednesday, July 03, 2013 10:55 AM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org; dcrocker@bbiw.net > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for > STIR) > > The From problem is lack of country codes, and maybe worse. Consider=20 > these possible From: contents > 5551212 > 2025551212 > 12025551212 > +12025551212 > and of course all the variations with parens, spaces, hyphens, commas,=20 > periods, etc. > > Although the first is getting really rare, I think it still happens > > The problem with these is when they appear in From on an international=20 > call > - the first 2 are the real problems. They would have to be rewritten. > > With To:, you get the variations with dial 9/8/... in enterprise=20 > systems, and the 011 style prefix > > Brian > > > > On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" > wrote: > >> Could someone provide a few examples? I have to say I find this=20 >> thread > hard to follow. I trust the individuals making the arguments to be=20 > knowledgeable and honest, but personally I have little experience with=20 > this "FROM header manipulation" that I'm told is so rampant. >> >> The only example I can think of is the "SIP trunking" use case I=20 >> raised > previously (user part of URI in FROM and/or TO header may be=20 > significant only within the dial plan of the associated Enterprise)=20 > which was ruled out of scope for this activity. So I'm puzzled, what=20 > use cases there are that > (a) are in scope for this exercise, and (b) involve manipulation of=20 > the user part of the URI in the FROM header. >> >> Apologies in advance if this is obvious to everyone else and I'm the=20 >> only > one who doesn't "get it". >> >> Thanks, >> >> Tim >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of > Brian Rosen >> Sent: Wednesday, July 03, 2013 9:23 AM >> To: dcrocker@bbiw.net >> Cc: stir@ietf.org >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for >> STIR) >> >> There are a lot of local variations out there, but they all have the > property that in order to route them, you need to be able to figure=20 > out at least the "left" part of the e.164 is, and the right part has=20 > to pass unscathed in order to work. Since everyone, and I mean=20 > everyone, dealing with these systems knows what e.164s are, and how=20 > they work, I don't think it's necessary, or even possible to describe=20 > all of the various ways the strings might appear and what to do with them= . >> >> All we need say is that in order to work, the header contents has to=20 >> be > able to have the canonical e.164 extracted with no knowledge at the=20 > validator, and validations can occur anywhere in the call path. We'll=20 > dress up that text a lot I am sure, but the notion that we could=20 > write, or need a document describing all possible variations of how=20 > telephone numbers may appear and how to extract the e.164 in each of=20 > them seems to me to be silly. >> >> It may be possible to specify an algorithm however. >> >> Brian >> >> On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >> >>> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>>> Catching up (I was out for a week) >>>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>> >>>>> The experience with canonicalization algorithms for DKIM -- and=20 >>>>> it, > too, had to deal with in-transit modifications -- makes clear that=20 > it's a topic with challenges and compromises. (Hmmm. "compromises" > might be a pun, here.) >>>> e.164s are much more constrained than the email address issues DKIM=20 >>>> has > to deal with. We could have challenges with local dial plans, and=20 > we've been discussing those issues, but the easy way out on those is=20 > that they may not be covered if both ends don't understand the dial=20 > plan the same way. >>>> >>>> So far, while we have one issue I'm concerned with (verifier not=20 >>>> being > able to extract a canonical e.164 from the content of "From"), I don't=20 > think the DKIM experience is particularly relevant. >>> >>> >>> Brian, >>> >>> Thanks. Good to hear. >>> >>> I assume there is a document that specifies all of the variations=20 >>> that > will be encountered and how to deterministically and successfully=20 > transform them into the single, canonical representation? >>> >>> Absent that, this topic remains a likely source of non-interoperability= . >>> >>> 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 timothy.dwight@verizon.com Wed Jul 3 10:35: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 BB0BB11E80E3 for ; Wed, 3 Jul 2013 10:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 9xuX1WJQBfUY for ; Wed, 3 Jul 2013 10:34:58 -0700 (PDT) Received: from fldsmtpe03.verizon.com (fldsmtpe03.verizon.com [140.108.26.142]) by ietfa.amsl.com (Postfix) with ESMTP id 491CF21F924A for ; Wed, 3 Jul 2013 10:34:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe03.verizon.com with ESMTP; 03 Jul 2013 17:34:56 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.87,989,1363132800"; d="scan'208";a="502331251" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi03.verizon.com with ESMTP; 03 Jul 2013 17:34:49 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Wed, 3 Jul 2013 13:34:49 -0400 To: Brian Rosen , Henning Schulzrinne Date: Wed, 3 Jul 2013 13:34:48 -0400 Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: Ac54BDWpqcs3PnzyTQm7/4aYFf3u7wADDN5Q Message-ID: <2B0F677F0B95454297753F58D4A07FA3012801EDBF@FHDP1LUMXC7V31.us.one.verizon.com> References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , 'Michael Hammer' , "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: Wed, 03 Jul 2013 17:35:03 -0000 Right, unless the URI in the FROM header has something like phone-context= =3D+1 the UK network would have to base its 'canonicalization' logic on som= ething else. If it's lucky it'll know more about where the call came from,= e.g., an ingress trunk group, from which it can make inferences. It can a= lso consider whether there's a country with CC=3D2 (there isn't), and if so= whether the remaining 9 digits could be a valid national significant numbe= r in that country; then repeat for CC=3D20 and CC=3D202. In my experience= such checking is (in the circuit switched network) implementation specific= and not always as rigorous as you would like. We are saved by the fact th= at SS7 signaling is very reliable, so we don't often have to exercise such = logic. =20 I have seen cases where the caller ID for a call from a mobile roaming inte= rnationally, was presented as having come from a (non-existent) US area cod= e. It messes up not only the caller ID but a subsequent callback, should o= ne be attempted. This happened because the 'context' of the call was someh= ow lost and the terminating switch's logic for resolving that case wasn't r= obust. =20 Fortunately in ISUP we very rarely lose the context of the call. Unfortuna= tely as we introduce VoIP our mechanisms for communicating such context (UR= I parameters) are not as rigidly adhered to as they should be. So in SIP u= se cases such as you describe could be more problematic. I conclude that i= n addition to the cryptographic security mechanisms we aim to define, we ne= ed to find a way to improve compliance, or at least clarify the ramificatio= ns of noncompliance, with existing specifications. Tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Bri= an Rosen Sent: Wednesday, July 03, 2013 10:44 AM To: Henning Schulzrinne Cc: stir@ietf.org; 'Michael Hammer'; Dwight, Timothy M (Tim); dcrocker@bbiw= .net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Here is an example of where I think we have a problem: From: 2025551212 To: +44 800 505555 Any entity on the origination side, including an SS7 GW, would know that th= e e.164 for From is +12025551212 The problem is if the call arrives as all SIP, the UK phone or SP won't kno= w that. Brian On Jul 3, 2013, at 11:37 AM, Henning Schulzrinne wrote: > We're retreading the same territory, but I don't think anybody is=20 > talking about rewriting From. The process is >=20 > Identity =3D Hash-and-sign(convert-to-E.164(From)) >=20 > As long as the receiver can perform the same operation and get the same r= esult, this works. For the reasons now repeated several times, receivers do= seem to be able to make sense of inter-provider From information, as they = use it mechanically for a variety of purposes. >=20 > I just don't see the real problem - if From (and their SS7 kin) didn't wo= rk, callerID would fail altogether. It obviously doesn't, for almost all ca= lls. >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 > Of Michael Hammer > Sent: Wednesday, July 03, 2013 11:22 AM > To: br@brianrosen.net > Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for=20 > STIR) >=20 > Then that tells me From is the wrong answer. >=20 > Mike >=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, July 03, 2013 11:19 AM > To: Michael Hammer > Cc: timothy.dwight@verizon.com; stir@ietf.org; dcrocker@bbiw.net > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for=20 > STIR) >=20 > Sure, but you get that the To has to go through rewrite to get it routed,= but the From doesn't. >=20 > It's all well and good to wave your hands and say "all SIP UAs must put f= ull e.164s in From" but it doesn't happen, and it's not going to happen. >=20 > Today, rewrites of From happen, but not always to e.164s. We're either g= oing to have to have those rewrites occur always to an e.164, include a ful= l e.164 in a new header, or use P-A-I and require it be a full e.164 (or a = combination). >=20 > Brian >=20 > On Jul 3, 2013, at 11:13 AM, Michael Hammer=20 > > wrote: >=20 >> All, >>=20 >> It helps to read E.164. >> It is a string of digits, max 15, no other characters, with CC, NDC,=20 >> and > SN. >> (There are variations on the names for those parts, but the concept=20 >> is the >> same.) >> If you provide a specification that unambiguously delimits that, you=20 >> are golden. >>=20 >> Do not inject confusion by introducing dialing sting prefixes. >> Do not inject confusion by introducing trunking indicators. >> Do not inject confusion by introducing methods to group digits. >>=20 >> If you want the phone number to get anywhere globally, you need to=20 >> know how to generate the E.164. >> Any domain worth its salt knows how to go from a local representation=20 >> to a canonical one. >> (And there are local representation secret sauce folks who know how=20 >> to do >> that.) >>=20 >> Mike >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Brian Rosen >> Sent: Wednesday, July 03, 2013 10:55 AM >> To: Dwight, Timothy M (Tim) >> Cc: stir@ietf.org; dcrocker@bbiw.net >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for >> STIR) >>=20 >> The From problem is lack of country codes, and maybe worse. Consider=20 >> these possible From: contents >> 5551212 >> 2025551212 >> 12025551212 >> +12025551212 >> and of course all the variations with parens, spaces, hyphens,=20 >> commas, periods, etc. >>=20 >> Although the first is getting really rare, I think it still happens >>=20 >> The problem with these is when they appear in From on an=20 >> international call >> - the first 2 are the real problems. They would have to be rewritten. >>=20 >> With To:, you get the variations with dial 9/8/... in enterprise=20 >> systems, and the 011 style prefix >>=20 >> Brian >>=20 >>=20 >>=20 >> On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" >> wrote: >>=20 >>> Could someone provide a few examples? I have to say I find this=20 >>> thread >> hard to follow. I trust the individuals making the arguments to be=20 >> knowledgeable and honest, but personally I have little experience=20 >> with this "FROM header manipulation" that I'm told is so rampant. >>>=20 >>> The only example I can think of is the "SIP trunking" use case I=20 >>> raised >> previously (user part of URI in FROM and/or TO header may be=20 >> significant only within the dial plan of the associated Enterprise)=20 >> which was ruled out of scope for this activity. So I'm puzzled, what=20 >> use cases there are that >> (a) are in scope for this exercise, and (b) involve manipulation of=20 >> the user part of the URI in the FROM header. >>>=20 >>> Apologies in advance if this is obvious to everyone else and I'm the=20 >>> only >> one who doesn't "get it". >>>=20 >>> Thanks, >>>=20 >>> Tim >>>=20 >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >>> Of >> Brian Rosen >>> Sent: Wednesday, July 03, 2013 9:23 AM >>> To: dcrocker@bbiw.net >>> Cc: stir@ietf.org >>> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for >>> STIR) >>>=20 >>> There are a lot of local variations out there, but they all have the >> property that in order to route them, you need to be able to figure=20 >> out at least the "left" part of the e.164 is, and the right part has=20 >> to pass unscathed in order to work. Since everyone, and I mean=20 >> everyone, dealing with these systems knows what e.164s are, and how=20 >> they work, I don't think it's necessary, or even possible to describe=20 >> all of the various ways the strings might appear and what to do with the= m. >>>=20 >>> All we need say is that in order to work, the header contents has to=20 >>> be >> able to have the canonical e.164 extracted with no knowledge at the=20 >> validator, and validations can occur anywhere in the call path. =20 >> We'll dress up that text a lot I am sure, but the notion that we=20 >> could write, or need a document describing all possible variations of=20 >> how telephone numbers may appear and how to extract the e.164 in each=20 >> of them > seems to me to be silly. >>>=20 >>> It may be possible to specify an algorithm however. >>>=20 >>> Brian >>>=20 >>> On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >>>=20 >>>> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>>>> Catching up (I was out for a week) On Jun 28, 2013, at 7:09 PM,=20 >>>>> Dave Crocker wrote: >>>>>=20 >>>>>> The experience with canonicalization algorithms for DKIM -- and=20 >>>>>> it, >> too, had to deal with in-transit modifications -- makes clear that=20 >> it's a topic with challenges and compromises. (Hmmm. "compromises" >> might be a pun, here.) >>>>> e.164s are much more constrained than the email address issues=20 >>>>> DKIM has >> to deal with. We could have challenges with local dial plans, and=20 >> we've been discussing those issues, but the easy way out on those is=20 >> that they may not be covered if both ends don't understand the dial=20 >> plan > the same way. >>>>>=20 >>>>> So far, while we have one issue I'm concerned with (verifier not=20 >>>>> being >> able to extract a canonical e.164 from the content of "From"), I=20 >> don't think the DKIM experience is particularly relevant. >>>>=20 >>>>=20 >>>> Brian, >>>>=20 >>>> Thanks. Good to hear. >>>>=20 >>>> I assume there is a document that specifies all of the variations=20 >>>> that >> will be encountered and how to deterministically and successfully=20 >> transform them into the single, canonical representation? >>>>=20 >>>> Absent that, this topic remains a likely source of non-interoperabilit= y. >>>>=20 >>>> d/ >>>>=20 >>>>=20 >>>> -- >>>> Dave Crocker >>>> Brandenburg InternetWorking >>>> bbiw.net >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> _______________________________________________ >> 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 Henning.Schulzrinne@fcc.gov Wed Jul 3 11:03: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 7C76C21F9D79 for ; Wed, 3 Jul 2013 11:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.628 X-Spam-Level: X-Spam-Status: No, score=-1.628 tagged_above=-999 required=5 tests=[AWL=0.971, 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 qxFwswWq4Z6S for ; Wed, 3 Jul 2013 11:03:53 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id CD52421F9D88 for ; Wed, 3 Jul 2013 11:03:52 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Michael Hammer' , "br@brianrosen.net" Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qfju36ah9Ux0e2HxhSF1PQN5lLiToAgAArZACAAAM/gIAAC30AgABB8ACABz9yAIAABZQAgAADigCAAAR8gIAABGkAgAAFRQCAAAFtAIAAAQiA//+/2HCAAE2/AP//v9zngABPxwD//8tOEA== Date: Wed, 3 Jul 2013 18:03:46 +0000 References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> , <00C069FD01E0324C9FFCADF539701DB3BBC11043@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC110E6@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC110E6@EX2K10MB1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "timothy.dwight@verizon.com" , "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: Wed, 03 Jul 2013 18:03:57 -0000 I'm probably missing something, but as far as I can tell, the situation tod= ay is: (1) Most calls have well-formatted "From" (CgN, ANI, ...) information that = is truthful. (2) Some calls have well-formatted origin information that is spoofed. (3) A very small fraction of calls have ill-formatted caller ID information= , typically inserted by entities with something to hide or the occasionally= clueless/bad-combination-of-circumstances cases. With validation, (1) would succeed, (2) would fail, as it should, and (3) w= ould remain as-is (and also fail validation, most likely). If anything, as = validation increases, since the originator of a call, particularly on the c= ommercial side, has every incentive for the call to complete, legitimate (3= ) calls should move into (1). -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20 Sent: Wednesday, July 03, 2013 1:07 PM To: Henning Schulzrinne; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Yes, but where are the false data being injected? Also, these are links in a chain, that if one fails, the follow-on checks will also fail. If you have a large number of failures for valid users, then the recipient cannot rely on the feature. And, the end result is the same, meager adoption. Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Wednesday, July 03, 2013 12:25 PM To: Michael Hammer; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) I don't see the contradiction: Today, we get perfectly-formatted, but substantially-false, callerID. Just because it's fake doesn't mean it's bad-looking... Indeed, the bad guys have every incentive to provide well-formatted numbers as otherwise the CNAM lookup will fail, defeating the purpose of rendering plausible textual caller ID information. ________________________________________ From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Michael Hammer [michael.hammer@yaanatech.com] Sent: Wednesday, July 03, 2013 12:11 PM To: Henning Schulzrinne; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Henning, The Caller-ID argument seems to run along these lines: SS7 PTSN works well, we get good caller ID. SIP world is problematic, we get robo-calling. Because we get good caller ID, we don't need to change how SIP operates today. That is a disconnect for me. Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 11:38 AM To: Michael Hammer; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) We're retreading the same territory, but I don't think anybody is talking about rewriting From. The process is Identity =3D Hash-and-sign(convert-to-E.164(From)) As long as the receiver can perform the same operation and get the same result, this works. For the reasons now repeated several times, receivers d= o seem to be able to make sense of inter-provider From information, as they use it mechanically for a variety of purposes. I just don't see the real problem - if From (and their SS7 kin) didn't work= , callerID would fail altogether. It obviously doesn't, for almost all calls. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Wednesday, July 03, 2013 11:22 AM To: br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Then that tells me From is the wrong answer. Mike -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, July 03, 2013 11:19 AM To: Michael Hammer Cc: timothy.dwight@verizon.com; stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Sure, but you get that the To has to go through rewrite to get it routed, but the From doesn't. It's all well and good to wave your hands and say "all SIP UAs must put ful= l e.164s in From" but it doesn't happen, and it's not going to happen. Today, rewrites of From happen, but not always to e.164s. We're either going to have to have those rewrites occur always to an e.164, include a full e.164 in a new header, or use P-A-I and require it be a full e.164 (or a combination). Brian On Jul 3, 2013, at 11:13 AM, Michael Hammer wrote: > All, > > It helps to read E.164. > It is a string of digits, max 15, no other characters, with CC, NDC,=20 > and SN. > (There are variations on the names for those parts, but the concept is=20 > the > same.) > If you provide a specification that unambiguously delimits that, you=20 > are golden. > > Do not inject confusion by introducing dialing sting prefixes. > Do not inject confusion by introducing trunking indicators. > Do not inject confusion by introducing methods to group digits. > > If you want the phone number to get anywhere globally, you need to=20 > know how to generate the E.164. > Any domain worth its salt knows how to go from a local representation=20 > to a canonical one. > (And there are local representation secret sauce folks who know how to=20 > do > that.) > > Mike > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 > Of Brian Rosen > Sent: Wednesday, July 03, 2013 10:55 AM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org; dcrocker@bbiw.net > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for > STIR) > > The From problem is lack of country codes, and maybe worse. Consider=20 > these possible From: contents > 5551212 > 2025551212 > 12025551212 > +12025551212 > and of course all the variations with parens, spaces, hyphens, commas,=20 > periods, etc. > > Although the first is getting really rare, I think it still happens > > The problem with these is when they appear in From on an international=20 > call > - the first 2 are the real problems. They would have to be rewritten. > > With To:, you get the variations with dial 9/8/... in enterprise=20 > systems, and the 011 style prefix > > Brian > > > > On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" > wrote: > >> Could someone provide a few examples? I have to say I find this=20 >> thread > hard to follow. I trust the individuals making the arguments to be=20 > knowledgeable and honest, but personally I have little experience with=20 > this "FROM header manipulation" that I'm told is so rampant. >> >> The only example I can think of is the "SIP trunking" use case I=20 >> raised > previously (user part of URI in FROM and/or TO header may be=20 > significant only within the dial plan of the associated Enterprise)=20 > which was ruled out of scope for this activity. So I'm puzzled, what=20 > use cases there are that > (a) are in scope for this exercise, and (b) involve manipulation of=20 > the user part of the URI in the FROM header. >> >> Apologies in advance if this is obvious to everyone else and I'm the=20 >> only > one who doesn't "get it". >> >> Thanks, >> >> Tim >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of > Brian Rosen >> Sent: Wednesday, July 03, 2013 9:23 AM >> To: dcrocker@bbiw.net >> Cc: stir@ietf.org >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for >> STIR) >> >> There are a lot of local variations out there, but they all have the > property that in order to route them, you need to be able to figure=20 > out at least the "left" part of the e.164 is, and the right part has=20 > to pass unscathed in order to work. Since everyone, and I mean=20 > everyone, dealing with these systems knows what e.164s are, and how=20 > they work, I don't think it's necessary, or even possible to describe=20 > all of the various ways the strings might appear and what to do with them= . >> >> All we need say is that in order to work, the header contents has to=20 >> be > able to have the canonical e.164 extracted with no knowledge at the=20 > validator, and validations can occur anywhere in the call path. We'll=20 > dress up that text a lot I am sure, but the notion that we could=20 > write, or need a document describing all possible variations of how=20 > telephone numbers may appear and how to extract the e.164 in each of=20 > them seems to me to be silly. >> >> It may be possible to specify an algorithm however. >> >> Brian >> >> On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >> >>> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>>> Catching up (I was out for a week) >>>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>> >>>>> The experience with canonicalization algorithms for DKIM -- and=20 >>>>> it, > too, had to deal with in-transit modifications -- makes clear that=20 > it's a topic with challenges and compromises. (Hmmm. "compromises" > might be a pun, here.) >>>> e.164s are much more constrained than the email address issues DKIM=20 >>>> has > to deal with. We could have challenges with local dial plans, and=20 > we've been discussing those issues, but the easy way out on those is=20 > that they may not be covered if both ends don't understand the dial=20 > plan the same way. >>>> >>>> So far, while we have one issue I'm concerned with (verifier not=20 >>>> being > able to extract a canonical e.164 from the content of "From"), I don't=20 > think the DKIM experience is particularly relevant. >>> >>> >>> Brian, >>> >>> Thanks. Good to hear. >>> >>> I assume there is a document that specifies all of the variations=20 >>> that > will be encountered and how to deterministically and successfully=20 > transform them into the single, canonical representation? >>> >>> Absent that, this topic remains a likely source of non-interoperability= . >>> >>> 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 Wed Jul 3 11:07: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 7B1BD11E81F3 for ; Wed, 3 Jul 2013 11:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.685 X-Spam-Level: X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[AWL=0.914, 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 YYDrI1v-L+1m for ; Wed, 3 Jul 2013 11:07:45 -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 42FAA11E81F8 for ; Wed, 3 Jul 2013 11:07:45 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "'Dwight, Timothy M (Tim)'" Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qfju36ah9Ux0e2HxhSF1PQN5lLiToAgAArZACAAAM/gIAAC30AgABB8ACABz9yAIAABZQAgAADigCAAAR8gIAABGkAgAAFRQCAAAFtAIAAAQiA//+/2HCAAAx98IAAHdIw Date: Wed, 3 Jul 2013 18:07:43 +0000 References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> <2B0F677F0B95454297753F58D4A07FA3012801ED45@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3012801ED45@FHDP1LUMXC7V31.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] 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: Wed, 03 Jul 2013 18:07:49 -0000 If they don't, both numeric and textual callerID won't work at all, most l= ikely (or will show random garbage). Large companies presumably want their = calls to show usable callerID, so that people pick up the calls. (And indiv= iduals and small businesses will complain to the state PUC or the FCC.) I s= uspect that if United Airlines calls up their carrier and complains about m= angled callerIDs, somebody at that carrier will try to get this fixed - at = least at your company... -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com]=20 Sent: Wednesday, July 03, 2013 12:53 PM To: Henning Schulzrinne; 'Michael Hammer'; br@brianrosen.net Cc: stir@ietf.org; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Ah, so I wasn't as confused as I thought. Good to know. We are talking ab= out being able to translate the value in the FROM header to an Internationa= l E.164 number, on the terminating side of the call. Not over-write the va= lue in the message, but the 'convert-to-E.164' function has to return the s= ame value on the terminating side as it did on the originating side. So I'm back to my previous position - this is indeed possible, assuming eno= ugh contextual information is present. Which in general it must be since a= s Hadriel repeatedly assures us, this all (usually) works today. =20 The nature of the contextual information is different in SIP though. If pe= ople are going to signal FROM headers with national significant numbers in = the user part, they (or something in the path on the originating leg) had b= etter be religious about appending the phone-context parameter, so that on = the terminating leg it's possible to know what they meant. tim=20 -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 10:38 AM To: 'Michael Hammer'; br@brianrosen.net Cc: stir@ietf.org; Dwight, Timothy M (Tim); dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) We're retreading the same territory, but I don't think anybody is talking a= bout rewriting From. The process is Identity =3D Hash-and-sign(convert-to-E.164(From)) As long as the receiver can perform the same operation and get the same res= ult, this works. For the reasons now repeated several times, receivers do s= eem to be able to make sense of inter-provider From information, as they us= e it mechanically for a variety of purposes. I just don't see the real problem - if From (and their SS7 kin) didn't work= , callerID would fail altogether. It obviously doesn't, for almost all call= s. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Mic= hael Hammer Sent: Wednesday, July 03, 2013 11:22 AM To: br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Then that tells me From is the wrong answer. Mike -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, July 03, 2013 11:19 AM To: Michael Hammer Cc: timothy.dwight@verizon.com; stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Sure, but you get that the To has to go through rewrite to get it routed, b= ut the From doesn't. It's all well and good to wave your hands and say "all SIP UAs must put ful= l e.164s in From" but it doesn't happen, and it's not going to happen. Today, rewrites of From happen, but not always to e.164s. We're either goi= ng to have to have those rewrites occur always to an e.164, include a full = e.164 in a new header, or use P-A-I and require it be a full e.164 (or a co= mbination). Brian On Jul 3, 2013, at 11:13 AM, Michael Hammer wrote: > All, >=20 > It helps to read E.164. > It is a string of digits, max 15, no other characters, with CC, NDC,=20 > and SN. > (There are variations on the names for those parts, but the concept is=20 > the > same.) > If you provide a specification that unambiguously delimits that, you=20 > are golden. >=20 > Do not inject confusion by introducing dialing sting prefixes. > Do not inject confusion by introducing trunking indicators. > Do not inject confusion by introducing methods to group digits. >=20 > If you want the phone number to get anywhere globally, you need to=20 > know how to generate the E.164. > Any domain worth its salt knows how to go from a local representation=20 > to a canonical one. > (And there are local representation secret sauce folks who know how to=20 > do > that.) >=20 > Mike >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 > Of Brian Rosen > Sent: Wednesday, July 03, 2013 10:55 AM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org; dcrocker@bbiw.net > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for > STIR) >=20 > The From problem is lack of country codes, and maybe worse. Consider=20 > these possible From: contents > 5551212 > 2025551212 > 12025551212 > +12025551212 > and of course all the variations with parens, spaces, hyphens, commas,=20 > periods, etc. >=20 > Although the first is getting really rare, I think it still happens >=20 > The problem with these is when they appear in From on an international=20 > call > - the first 2 are the real problems. They would have to be rewritten. >=20 > With To:, you get the variations with dial 9/8/... in enterprise=20 > systems, and the 011 style prefix >=20 > Brian >=20 >=20 >=20 > On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" > wrote: >=20 >> Could someone provide a few examples? I have to say I find this=20 >> thread > hard to follow. I trust the individuals making the arguments to be=20 > knowledgeable and honest, but personally I have little experience with=20 > this "FROM header manipulation" that I'm told is so rampant. >>=20 >> The only example I can think of is the "SIP trunking" use case I=20 >> raised > previously (user part of URI in FROM and/or TO header may be=20 > significant only within the dial plan of the associated Enterprise)=20 > which was ruled out of scope for this activity. So I'm puzzled, what=20 > use cases there are that > (a) are in scope for this exercise, and (b) involve manipulation of=20 > the user part of the URI in the FROM header. >>=20 >> Apologies in advance if this is obvious to everyone else and I'm the=20 >> only > one who doesn't "get it". >>=20 >> Thanks, >>=20 >> Tim >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of > Brian Rosen >> Sent: Wednesday, July 03, 2013 9:23 AM >> To: dcrocker@bbiw.net >> Cc: stir@ietf.org >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for >> STIR) >>=20 >> There are a lot of local variations out there, but they all have the > property that in order to route them, you need to be able to figure=20 > out at least the "left" part of the e.164 is, and the right part has=20 > to pass unscathed in order to work. Since everyone, and I mean=20 > everyone, dealing with these systems knows what e.164s are, and how=20 > they work, I don't think it's necessary, or even possible to describe=20 > all of the various ways the strings might appear and what to do with them= . >>=20 >> All we need say is that in order to work, the header contents has to=20 >> be > able to have the canonical e.164 extracted with no knowledge at the=20 > validator, and validations can occur anywhere in the call path. We'll=20 > dress up that text a lot I am sure, but the notion that we could=20 > write, or need a document describing all possible variations of how=20 > telephone numbers may appear and how to extract the e.164 in each of=20 > them seems to me to be silly. >>=20 >> It may be possible to specify an algorithm however. >>=20 >> Brian >>=20 >> On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >>=20 >>> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>>> Catching up (I was out for a week) >>>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>>=20 >>>>> The experience with canonicalization algorithms for DKIM -- and=20 >>>>> it, > too, had to deal with in-transit modifications -- makes clear that=20 > it's a topic with challenges and compromises. (Hmmm. "compromises" > might be a pun, here.) >>>> e.164s are much more constrained than the email address issues DKIM=20 >>>> has > to deal with. We could have challenges with local dial plans, and=20 > we've been discussing those issues, but the easy way out on those is=20 > that they may not be covered if both ends don't understand the dial=20 > plan the same way. >>>>=20 >>>> So far, while we have one issue I'm concerned with (verifier not=20 >>>> being > able to extract a canonical e.164 from the content of "From"), I don't=20 > think the DKIM experience is particularly relevant. >>>=20 >>>=20 >>> Brian, >>>=20 >>> Thanks. Good to hear. >>>=20 >>> I assume there is a document that specifies all of the variations=20 >>> that > will be encountered and how to deterministically and successfully=20 > transform them into the single, canonical representation? >>>=20 >>> Absent that, this topic remains a likely source of non-interoperability= . >>>=20 >>> d/ >>>=20 >>>=20 >>> -- >>> Dave Crocker >>> Brandenburg InternetWorking >>> bbiw.net >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From michael.hammer@yaanatech.com Wed Jul 3 11:18: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 2507511E81F3 for ; Wed, 3 Jul 2013 11:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 H4bFYteHLg42 for ; Wed, 3 Jul 2013 11:18: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 296AE11E80C5 for ; Wed, 3 Jul 2013 11:18:17 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Wed, 3 Jul 2013 11:18:17 -0700 From: Michael Hammer To: "Henning.Schulzrinne@fcc.gov" , "br@brianrosen.net" Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qWRsjPKQFYKEy7+8dmUhlONZlLu4UAgAArZAD//42y0IAAgQkAgABB8ACABz9zAIAABZQAgAADigCAAAR8gIAABGkA//+NhfCAAHktAP//i4pgAA83oYAADZW/QP//oI2AgABqTFD//7FMAIAAcfAw Date: Wed, 3 Jul 2013 18:18:16 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC1124D@EX2K10MB1.corp.yaanatech.com> References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> , <00C069FD01E0324C9FFCADF539701DB3BBC11043@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC110E6@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.96] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00F0_01CE77F8.282E70D0" MIME-Version: 1.0 Cc: "stir@ietf.org" , "timothy.dwight@verizon.com" , "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: Wed, 03 Jul 2013 18:18:21 -0000 ------=_NextPart_000_00F0_01CE77F8.282E70D0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit My impression from this thread was that (3) was more often the case, and (1) was the minority. And, that there was little incentive thus far to change that. Thus, absence some "encouragement" from regulators, call completion is not impeded, since $$ come from call completion, not from valid caller ID. Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 2:04 PM To: Michael Hammer; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) I'm probably missing something, but as far as I can tell, the situation today is: (1) Most calls have well-formatted "From" (CgN, ANI, ...) information that is truthful. (2) Some calls have well-formatted origin information that is spoofed. (3) A very small fraction of calls have ill-formatted caller ID information, typically inserted by entities with something to hide or the occasionally clueless/bad-combination-of-circumstances cases. With validation, (1) would succeed, (2) would fail, as it should, and (3) would remain as-is (and also fail validation, most likely). If anything, as validation increases, since the originator of a call, particularly on the commercial side, has every incentive for the call to complete, legitimate (3) calls should move into (1). -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Wednesday, July 03, 2013 1:07 PM To: Henning Schulzrinne; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Yes, but where are the false data being injected? Also, these are links in a chain, that if one fails, the follow-on checks will also fail. If you have a large number of failures for valid users, then the recipient cannot rely on the feature. And, the end result is the same, meager adoption. Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 12:25 PM To: Michael Hammer; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) I don't see the contradiction: Today, we get perfectly-formatted, but substantially-false, callerID. Just because it's fake doesn't mean it's bad-looking... Indeed, the bad guys have every incentive to provide well-formatted numbers as otherwise the CNAM lookup will fail, defeating the purpose of rendering plausible textual caller ID information. ________________________________________ From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Michael Hammer [michael.hammer@yaanatech.com] Sent: Wednesday, July 03, 2013 12:11 PM To: Henning Schulzrinne; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Henning, The Caller-ID argument seems to run along these lines: SS7 PTSN works well, we get good caller ID. SIP world is problematic, we get robo-calling. Because we get good caller ID, we don't need to change how SIP operates today. That is a disconnect for me. Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 11:38 AM To: Michael Hammer; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) We're retreading the same territory, but I don't think anybody is talking about rewriting From. The process is Identity = Hash-and-sign(convert-to-E.164(From)) As long as the receiver can perform the same operation and get the same result, this works. For the reasons now repeated several times, receivers do seem to be able to make sense of inter-provider From information, as they use it mechanically for a variety of purposes. I just don't see the real problem - if From (and their SS7 kin) didn't work, callerID would fail altogether. It obviously doesn't, for almost all calls. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Wednesday, July 03, 2013 11:22 AM To: br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Then that tells me From is the wrong answer. Mike -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, July 03, 2013 11:19 AM To: Michael Hammer Cc: timothy.dwight@verizon.com; stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Sure, but you get that the To has to go through rewrite to get it routed, but the From doesn't. It's all well and good to wave your hands and say "all SIP UAs must put full e.164s in From" but it doesn't happen, and it's not going to happen. Today, rewrites of From happen, but not always to e.164s. We're either going to have to have those rewrites occur always to an e.164, include a full e.164 in a new header, or use P-A-I and require it be a full e.164 (or a combination). Brian On Jul 3, 2013, at 11:13 AM, Michael Hammer wrote: > All, > > It helps to read E.164. > It is a string of digits, max 15, no other characters, with CC, NDC, > and SN. > (There are variations on the names for those parts, but the concept is > the > same.) > If you provide a specification that unambiguously delimits that, you > are golden. > > Do not inject confusion by introducing dialing sting prefixes. > Do not inject confusion by introducing trunking indicators. > Do not inject confusion by introducing methods to group digits. > > If you want the phone number to get anywhere globally, you need to > know how to generate the E.164. > Any domain worth its salt knows how to go from a local representation > to a canonical one. > (And there are local representation secret sauce folks who know how to > do > that.) > > Mike > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: Wednesday, July 03, 2013 10:55 AM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org; dcrocker@bbiw.net > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for > STIR) > > The From problem is lack of country codes, and maybe worse. Consider > these possible From: contents > 5551212 > 2025551212 > 12025551212 > +12025551212 > and of course all the variations with parens, spaces, hyphens, commas, > periods, etc. > > Although the first is getting really rare, I think it still happens > > The problem with these is when they appear in From on an international > call > - the first 2 are the real problems. They would have to be rewritten. > > With To:, you get the variations with dial 9/8/... in enterprise > systems, and the 011 style prefix > > Brian > > > > On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" > wrote: > >> Could someone provide a few examples? I have to say I find this >> thread > hard to follow. I trust the individuals making the arguments to be > knowledgeable and honest, but personally I have little experience with > this "FROM header manipulation" that I'm told is so rampant. >> >> The only example I can think of is the "SIP trunking" use case I >> raised > previously (user part of URI in FROM and/or TO header may be > significant only within the dial plan of the associated Enterprise) > which was ruled out of scope for this activity. So I'm puzzled, what > use cases there are that > (a) are in scope for this exercise, and (b) involve manipulation of > the user part of the URI in the FROM header. >> >> Apologies in advance if this is obvious to everyone else and I'm the >> only > one who doesn't "get it". >> >> Thanks, >> >> Tim >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of > Brian Rosen >> Sent: Wednesday, July 03, 2013 9:23 AM >> To: dcrocker@bbiw.net >> Cc: stir@ietf.org >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for >> STIR) >> >> There are a lot of local variations out there, but they all have the > property that in order to route them, you need to be able to figure > out at least the "left" part of the e.164 is, and the right part has > to pass unscathed in order to work. Since everyone, and I mean > everyone, dealing with these systems knows what e.164s are, and how > they work, I don't think it's necessary, or even possible to describe > all of the various ways the strings might appear and what to do with them. >> >> All we need say is that in order to work, the header contents has to >> be > able to have the canonical e.164 extracted with no knowledge at the > validator, and validations can occur anywhere in the call path. We'll > dress up that text a lot I am sure, but the notion that we could > write, or need a document describing all possible variations of how > telephone numbers may appear and how to extract the e.164 in each of > them seems to me to be silly. >> >> It may be possible to specify an algorithm however. >> >> Brian >> >> On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >> >>> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>>> Catching up (I was out for a week) >>>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>> >>>>> 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.) >>>> e.164s are much more constrained than the email address issues DKIM >>>> has > to deal with. We could have challenges with local dial plans, and > we've been discussing those issues, but the easy way out on those is > that they may not be covered if both ends don't understand the dial > plan the same way. >>>> >>>> So far, while we have one issue I'm concerned with (verifier not >>>> being > able to extract a canonical e.164 from the content of "From"), I don't > think the DKIM experience is particularly relevant. >>> >>> >>> Brian, >>> >>> Thanks. Good to hear. >>> >>> I assume there is a document that specifies all of the variations >>> that > will be encountered and how to deterministically and successfully > transform them into the single, canonical representation? >>> >>> Absent that, this topic remains a likely source of non-interoperability. >>> >>> 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_00F0_01CE77F8.282E70D0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcw MzE4MTgxNVowIwYJKoZIhvcNAQkEMRYEFNeJ8g1DlcTXD2RaV1A1iCeT1Zv9MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEANsl7tl9lxwtaGbV1LuSQbO65r6+KEoUOPXZ6vIu5 suDHGd1wbO9HeUnOY7tymk5lbOMSbpCE+sDa5FkS5+0Sx6mNTqfudgsGp22Ylmv/DduwRAMUTGac +23bUpYkfHPU5bvfJkuU0VT0VZWcdBdPWZGlmuwpdEv20ukFEb5blUhNCdm1eyPeeu7goY7K6ttX fK1BMyKzAKeQQeFs7AaJbDdxmJC9LWROse/yNW3ZnjjZcqeYCJmylCxZZJOSZvPYeQ3cimGmoCRB StcBWpgUebfAvHRVt1EAsDXA2lqHUWEHZhGvt12iyI7sxUOwPR+Ls/AvF0QqiHT6sYsiZAjsiAAA AAAAAA== ------=_NextPart_000_00F0_01CE77F8.282E70D0-- From michael.hammer@yaanatech.com Wed Jul 3 11:20: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 401A611E81CD for ; Wed, 3 Jul 2013 11:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 7T6RuTotQiHT for ; Wed, 3 Jul 2013 11:20:05 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 03CFB11E81F7 for ; Wed, 3 Jul 2013 11:19:59 -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, 3 Jul 2013 11:19:58 -0700 From: Michael Hammer To: "Henning.Schulzrinne@fcc.gov" , "timothy.dwight@verizon.com" Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qWRsjPKQFYKEy7+8dmUhlONZlLu4UAgAArZAD//42y0IAAgQkAgABB8ACABz9zAIAABZQAgAADigCAAAR8gIAABGkA//+NhfCAAHktAP//i4pgAA83oYAAAp5oAAACn0yAAA5BnQA= Date: Wed, 3 Jul 2013 18:19:57 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC1126B@EX2K10MB1.corp.yaanatech.com> References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> <2B0F677F0B95454297753F58D4A07FA3012801ED45@FHDP1LUMXC7V31.us.one.verizon.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.96] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00F5_01CE77F8.64A6A280" 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: Wed, 03 Jul 2013 18:20:09 -0000 ------=_NextPart_000_00F5_01CE77F8.64A6A280 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Ummm.... who do I call to complain about calls from 800 numbers? :) Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Wednesday, July 03, 2013 2:08 PM To: 'Dwight, Timothy M (Tim)' Cc: stir@ietf.org Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) If they don't, both numeric and textual callerID won't work at all, most likely (or will show random garbage). Large companies presumably want their calls to show usable callerID, so that people pick up the calls. (And individuals and small businesses will complain to the state PUC or the FCC.) I suspect that if United Airlines calls up their carrier and complains about mangled callerIDs, somebody at that carrier will try to get this fixed - at least at your company... -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] Sent: Wednesday, July 03, 2013 12:53 PM To: Henning Schulzrinne; 'Michael Hammer'; br@brianrosen.net Cc: stir@ietf.org; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Ah, so I wasn't as confused as I thought. Good to know. We are talking about being able to translate the value in the FROM header to an International E.164 number, on the terminating side of the call. Not over-write the value in the message, but the 'convert-to-E.164' function has to return the same value on the terminating side as it did on the originating side. So I'm back to my previous position - this is indeed possible, assuming enough contextual information is present. Which in general it must be since as Hadriel repeatedly assures us, this all (usually) works today. The nature of the contextual information is different in SIP though. If people are going to signal FROM headers with national significant numbers in the user part, they (or something in the path on the originating leg) had better be religious about appending the phone-context parameter, so that on the terminating leg it's possible to know what they meant. tim -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 10:38 AM To: 'Michael Hammer'; br@brianrosen.net Cc: stir@ietf.org; Dwight, Timothy M (Tim); dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) We're retreading the same territory, but I don't think anybody is talking about rewriting From. The process is Identity = Hash-and-sign(convert-to-E.164(From)) As long as the receiver can perform the same operation and get the same result, this works. For the reasons now repeated several times, receivers do seem to be able to make sense of inter-provider From information, as they use it mechanically for a variety of purposes. I just don't see the real problem - if From (and their SS7 kin) didn't work, callerID would fail altogether. It obviously doesn't, for almost all calls. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Wednesday, July 03, 2013 11:22 AM To: br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Then that tells me From is the wrong answer. Mike -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, July 03, 2013 11:19 AM To: Michael Hammer Cc: timothy.dwight@verizon.com; stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Sure, but you get that the To has to go through rewrite to get it routed, but the From doesn't. It's all well and good to wave your hands and say "all SIP UAs must put full e.164s in From" but it doesn't happen, and it's not going to happen. Today, rewrites of From happen, but not always to e.164s. We're either going to have to have those rewrites occur always to an e.164, include a full e.164 in a new header, or use P-A-I and require it be a full e.164 (or a combination). Brian On Jul 3, 2013, at 11:13 AM, Michael Hammer wrote: > All, > > It helps to read E.164. > It is a string of digits, max 15, no other characters, with CC, NDC, > and SN. > (There are variations on the names for those parts, but the concept is > the > same.) > If you provide a specification that unambiguously delimits that, you > are golden. > > Do not inject confusion by introducing dialing sting prefixes. > Do not inject confusion by introducing trunking indicators. > Do not inject confusion by introducing methods to group digits. > > If you want the phone number to get anywhere globally, you need to > know how to generate the E.164. > Any domain worth its salt knows how to go from a local representation > to a canonical one. > (And there are local representation secret sauce folks who know how to > do > that.) > > Mike > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: Wednesday, July 03, 2013 10:55 AM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org; dcrocker@bbiw.net > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for > STIR) > > The From problem is lack of country codes, and maybe worse. Consider > these possible From: contents > 5551212 > 2025551212 > 12025551212 > +12025551212 > and of course all the variations with parens, spaces, hyphens, commas, > periods, etc. > > Although the first is getting really rare, I think it still happens > > The problem with these is when they appear in From on an international > call > - the first 2 are the real problems. They would have to be rewritten. > > With To:, you get the variations with dial 9/8/... in enterprise > systems, and the 011 style prefix > > Brian > > > > On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" > wrote: > >> Could someone provide a few examples? I have to say I find this >> thread > hard to follow. I trust the individuals making the arguments to be > knowledgeable and honest, but personally I have little experience with > this "FROM header manipulation" that I'm told is so rampant. >> >> The only example I can think of is the "SIP trunking" use case I >> raised > previously (user part of URI in FROM and/or TO header may be > significant only within the dial plan of the associated Enterprise) > which was ruled out of scope for this activity. So I'm puzzled, what > use cases there are that > (a) are in scope for this exercise, and (b) involve manipulation of > the user part of the URI in the FROM header. >> >> Apologies in advance if this is obvious to everyone else and I'm the >> only > one who doesn't "get it". >> >> Thanks, >> >> Tim >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of > Brian Rosen >> Sent: Wednesday, July 03, 2013 9:23 AM >> To: dcrocker@bbiw.net >> Cc: stir@ietf.org >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for >> STIR) >> >> There are a lot of local variations out there, but they all have the > property that in order to route them, you need to be able to figure > out at least the "left" part of the e.164 is, and the right part has > to pass unscathed in order to work. Since everyone, and I mean > everyone, dealing with these systems knows what e.164s are, and how > they work, I don't think it's necessary, or even possible to describe > all of the various ways the strings might appear and what to do with them. >> >> All we need say is that in order to work, the header contents has to >> be > able to have the canonical e.164 extracted with no knowledge at the > validator, and validations can occur anywhere in the call path. We'll > dress up that text a lot I am sure, but the notion that we could > write, or need a document describing all possible variations of how > telephone numbers may appear and how to extract the e.164 in each of > them seems to me to be silly. >> >> It may be possible to specify an algorithm however. >> >> Brian >> >> On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >> >>> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>>> Catching up (I was out for a week) >>>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>> >>>>> 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.) >>>> e.164s are much more constrained than the email address issues DKIM >>>> has > to deal with. We could have challenges with local dial plans, and > we've been discussing those issues, but the easy way out on those is > that they may not be covered if both ends don't understand the dial > plan the same way. >>>> >>>> So far, while we have one issue I'm concerned with (verifier not >>>> being > able to extract a canonical e.164 from the content of "From"), I don't > think the DKIM experience is particularly relevant. >>> >>> >>> Brian, >>> >>> Thanks. Good to hear. >>> >>> I assume there is a document that specifies all of the variations >>> that > will be encountered and how to deterministically and successfully > transform them into the single, canonical representation? >>> >>> Absent that, this topic remains a likely source of non-interoperability. >>> >>> 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_00F5_01CE77F8.64A6A280 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcw MzE4MTk1NlowIwYJKoZIhvcNAQkEMRYEFGwse97sBUHWnCNa/SrMfQnJR6oYMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEANhTwBmPqMspP4evUgfhi+K/5OupVEizD8pb7e1in Aqu12NLn0eog/1zthy/u0XJIfHd+rlxvPlxbjnzM00S7r1668/keEgdjnz1kN0/YW0UbxZ5wb/a3 1mmcf2b+dUhYPr39j9jIVaXETUhxIt+VjjCKur7W471tR/QiTut5DFWf6BmyHaCq9n2Y8UM7a9pV DsJf+i4yDJ3WxeBNmFt/xjb6Td8SIxEsmMoB+LiKtWd9jLpAV8YvhwHxBoNRlWygfUxmqZH27J5b Jwy/N2TcvCa+I+yIloWsDeK2Sep63cii4wqv1RniQj3LgHjVcR+dJXBw4VjyRk0g8+m4sTsRdgAA AAAAAA== ------=_NextPart_000_00F5_01CE77F8.64A6A280-- From Henning.Schulzrinne@fcc.gov Wed Jul 3 11:33: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 236FC21F9CD4 for ; Wed, 3 Jul 2013 11:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[AWL=0.863, 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 Gx5Uyr0IWAzs for ; Wed, 3 Jul 2013 11:33:00 -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 C563D21F9CD7 for ; Wed, 3 Jul 2013 11:32:59 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Michael Hammer' , "br@brianrosen.net" Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qfju36ah9Ux0e2HxhSF1PQN5lLiToAgAArZACAAAM/gIAAC30AgABB8ACABz9yAIAABZQAgAADigCAAAR8gIAABGkAgAAFRQCAAAFtAIAAAQiA//+/2HCAAE2/AP//v9zngABPxwD//8tOEAAJEvIAAAfz7LA= Date: Wed, 3 Jul 2013 18:32:57 +0000 References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> , <00C069FD01E0324C9FFCADF539701DB3BBC11043@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC110E6@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC1124D@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC1124D@EX2K10MB1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "timothy.dwight@verizon.com" , "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: Wed, 03 Jul 2013 18:33:04 -0000 I don't think anybody has complete statistical data, but from what I can te= ll, for almost all domestic calls, callerID tends to work (whether it's spo= ofed or not). Given that a significant fraction of call origination is now = VoIP (in some areas, close to 50%), courtesy of MSOs, there's usually some = SIP in the call path. Is your experience that a large fraction of your incoming calls have mangle= d callerID? -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Mic= hael Hammer Sent: Wednesday, July 03, 2013 2:18 PM To: Henning Schulzrinne; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) My impression from this thread was that (3) was more often the case, and (1= ) was the minority. And, that there was little incentive thus far to change that. Thus, absence some "encouragement" from regulators, call completion is not = impeded, since $$ come from call completion, not from valid caller ID. Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 2:04 PM To: Michael Hammer; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) I'm probably missing something, but as far as I can tell, the situation tod= ay is: (1) Most calls have well-formatted "From" (CgN, ANI, ...) information that = is truthful. (2) Some calls have well-formatted origin information that is spoofed. (3) A very small fraction of calls have ill-formatted caller ID information= , typically inserted by entities with something to hide or the occasionally= clueless/bad-combination-of-circumstances cases. With validation, (1) would succeed, (2) would fail, as it should, and (3) w= ould remain as-is (and also fail validation, most likely). If anything, as = validation increases, since the originator of a call, particularly on the c= ommercial side, has every incentive for the call to complete, legitimate (3) calls should move into (1). -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Wednesday, July 03, 2013 1:07 PM To: Henning Schulzrinne; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Yes, but where are the false data being injected? Also, these are links in a chain, that if one fails, the follow-on checks w= ill also fail. If you have a large number of failures for valid users, then the recipient = cannot rely on the feature. And, the end result is the same, meager adoption. Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 12:25 PM To: Michael Hammer; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) I don't see the contradiction: Today, we get perfectly-formatted, but subst= antially-false, callerID. Just because it's fake doesn't mean it's bad-look= ing... Indeed, the bad guys have every incentive to provide well-formatted numbers= as otherwise the CNAM lookup will fail, defeating the purpose of rendering= plausible textual caller ID information. ________________________________________ From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Michael Ha= mmer [michael.hammer@yaanatech.com] Sent: Wednesday, July 03, 2013 12:11 PM To: Henning Schulzrinne; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Henning, The Caller-ID argument seems to run along these lines: SS7 PTSN works well, we get good caller ID. SIP world is problematic, we get robo-calling. Because we get good caller ID, we don't need to change how SIP operates tod= ay. That is a disconnect for me. Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 11:38 AM To: Michael Hammer; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) We're retreading the same territory, but I don't think anybody is talking a= bout rewriting From. The process is Identity =3D Hash-and-sign(convert-to-E.164(From)) As long as the receiver can perform the same operation and get the same res= ult, this works. For the reasons now repeated several times, receivers do s= eem to be able to make sense of inter-provider From information, as they us= e it mechanically for a variety of purposes. I just don't see the real problem - if From (and their SS7 kin) didn't work= , callerID would fail altogether. It obviously doesn't, for almost all call= s. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Mic= hael Hammer Sent: Wednesday, July 03, 2013 11:22 AM To: br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Then that tells me From is the wrong answer. Mike -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, July 03, 2013 11:19 AM To: Michael Hammer Cc: timothy.dwight@verizon.com; stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Sure, but you get that the To has to go through rewrite to get it routed, b= ut the From doesn't. It's all well and good to wave your hands and say "all SIP UAs must put ful= l e.164s in From" but it doesn't happen, and it's not going to happen. Today, rewrites of From happen, but not always to e.164s. We're either goi= ng to have to have those rewrites occur always to an e.164, include a full = e.164 in a new header, or use P-A-I and require it be a full e.164 (or a co= mbination). Brian On Jul 3, 2013, at 11:13 AM, Michael Hammer wrote: > All, > > It helps to read E.164. > It is a string of digits, max 15, no other characters, with CC, NDC,=20 > and SN. > (There are variations on the names for those parts, but the concept is=20 > the > same.) > If you provide a specification that unambiguously delimits that, you=20 > are golden. > > Do not inject confusion by introducing dialing sting prefixes. > Do not inject confusion by introducing trunking indicators. > Do not inject confusion by introducing methods to group digits. > > If you want the phone number to get anywhere globally, you need to=20 > know how to generate the E.164. > Any domain worth its salt knows how to go from a local representation=20 > to a canonical one. > (And there are local representation secret sauce folks who know how to=20 > do > that.) > > Mike > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 > Of Brian Rosen > Sent: Wednesday, July 03, 2013 10:55 AM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org; dcrocker@bbiw.net > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for > STIR) > > The From problem is lack of country codes, and maybe worse. Consider=20 > these possible From: contents > 5551212 > 2025551212 > 12025551212 > +12025551212 > and of course all the variations with parens, spaces, hyphens, commas,=20 > periods, etc. > > Although the first is getting really rare, I think it still happens > > The problem with these is when they appear in From on an international=20 > call > - the first 2 are the real problems. They would have to be rewritten. > > With To:, you get the variations with dial 9/8/... in enterprise=20 > systems, and the 011 style prefix > > Brian > > > > On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" > wrote: > >> Could someone provide a few examples? I have to say I find this=20 >> thread > hard to follow. I trust the individuals making the arguments to be=20 > knowledgeable and honest, but personally I have little experience with=20 > this "FROM header manipulation" that I'm told is so rampant. >> >> The only example I can think of is the "SIP trunking" use case I=20 >> raised > previously (user part of URI in FROM and/or TO header may be=20 > significant only within the dial plan of the associated Enterprise)=20 > which was ruled out of scope for this activity. So I'm puzzled, what=20 > use cases there are that > (a) are in scope for this exercise, and (b) involve manipulation of=20 > the user part of the URI in the FROM header. >> >> Apologies in advance if this is obvious to everyone else and I'm the=20 >> only > one who doesn't "get it". >> >> Thanks, >> >> Tim >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of > Brian Rosen >> Sent: Wednesday, July 03, 2013 9:23 AM >> To: dcrocker@bbiw.net >> Cc: stir@ietf.org >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for >> STIR) >> >> There are a lot of local variations out there, but they all have the > property that in order to route them, you need to be able to figure=20 > out at least the "left" part of the e.164 is, and the right part has=20 > to pass unscathed in order to work. Since everyone, and I mean=20 > everyone, dealing with these systems knows what e.164s are, and how=20 > they work, I don't think it's necessary, or even possible to describe=20 > all of the various ways the strings might appear and what to do with them= . >> >> All we need say is that in order to work, the header contents has to=20 >> be > able to have the canonical e.164 extracted with no knowledge at the=20 > validator, and validations can occur anywhere in the call path. We'll=20 > dress up that text a lot I am sure, but the notion that we could=20 > write, or need a document describing all possible variations of how=20 > telephone numbers may appear and how to extract the e.164 in each of=20 > them seems to me to be silly. >> >> It may be possible to specify an algorithm however. >> >> Brian >> >> On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >> >>> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>>> Catching up (I was out for a week) >>>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>> >>>>> The experience with canonicalization algorithms for DKIM -- and=20 >>>>> it, > too, had to deal with in-transit modifications -- makes clear that=20 > it's a topic with challenges and compromises. (Hmmm. "compromises" > might be a pun, here.) >>>> e.164s are much more constrained than the email address issues DKIM=20 >>>> has > to deal with. We could have challenges with local dial plans, and=20 > we've been discussing those issues, but the easy way out on those is=20 > that they may not be covered if both ends don't understand the dial=20 > plan the same way. >>>> >>>> So far, while we have one issue I'm concerned with (verifier not=20 >>>> being > able to extract a canonical e.164 from the content of "From"), I don't=20 > think the DKIM experience is particularly relevant. >>> >>> >>> Brian, >>> >>> Thanks. Good to hear. >>> >>> I assume there is a document that specifies all of the variations=20 >>> that > will be encountered and how to deterministically and successfully=20 > transform them into the single, canonical representation? >>> >>> Absent that, this topic remains a likely source of non-interoperability= . >>> >>> 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 pp3129@att.com Wed Jul 3 11: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 7DC5321F9CDC for ; Wed, 3 Jul 2013 11:34:13 -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 R89TSKrdq1hB for ; Wed, 3 Jul 2013 11:34:08 -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 A33F221F9CD4 for ; Wed, 3 Jul 2013 11:34:07 -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 f9e64d15.54c9b940.198875.00-568.566483.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 03 Jul 2013 18:34:07 +0000 (UTC) X-MXL-Hash: 51d46e9f2c607ad3-bf19a56c3f7a03c6cb2906a8797514b7c73b70c3 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 a9e64d15.0.198817.00-406.566315.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 03 Jul 2013 18:34:06 +0000 (UTC) X-MXL-Hash: 51d46e9e05f45873-d5bb1528bb5e1fa8546f263c261c46f37a701eb9 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 r63IY1Ok025052; Wed, 3 Jul 2013 14:34:02 -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 r63IXgWa024815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jul 2013 14:33:43 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 3 Jul 2013 18:33:25 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, 3 Jul 2013 14:33:35 -0400 From: "PFAUTZ, PENN L" To: Michael Hammer , "Henning.Schulzrinne@fcc.gov" , "br@brianrosen.net" Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qWRsjPKQFYKEy7+8dmUhlONZlLu4UAgAArZAD//42y0IAAgQkAgABB8ACABz9zAIAABZQAgAADigCAAAR8gIAABGkA//+NhfCAAHktAP//i4pgAA83oYAADZW/QP//oI2AgABqTFD//7FMAIAAcfAwgADgcmA= Date: Wed, 3 Jul 2013 18:33:35 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D604977C07@MISOUT7MSGUSR9N.ITServices.sbc.com> References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> , <00C069FD01E0324C9FFCADF539701DB3BBC11043@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC110E6@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC1124D@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC1124D@EX2K10MB1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.160.80] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=NrlmhbhJ c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=7rbOGru5kh8A:10 a=qvXq6a5bQMYA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=SmorGXxrPMUA:10 a=48vgC7mUAAAA:8 a=HLLxP2VMAAAA:8] X-AnalysisOut: [ a=ZsyXEVtvAAAA:8 a=k7Ga1wGzAAAA:8 a=scBmumm3AAAA:8 a=b8Ov] X-AnalysisOut: [NEjoAAAA:8 a=gceTnYkB1hyjFc6a58UA:9 a=CjuIK1q_8ugA:10 a=iE] X-AnalysisOut: [9YWIBck50A:10 a=ClmATp4dOM8A:10 a=lZB815dzVvQA:10 a=-zy3ex] X-AnalysisOut: [45pM4A:10 a=TRFw3Wk1wdAA:10 a=fcAx7uNQz4EA:10 a=E7MB4TUEIZ] X-AnalysisOut: [IA:10 a=4EH3lStnpPUJ9VOs:21 a=agJYDFl1geKhek48:21] Cc: "stir@ietf.org" , "timothy.dwight@verizon.com" , "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: Wed, 03 Jul 2013 18:34:13 -0000 Mike: I think that (1) is actually the predominant case taking all calls in accou= nt. There is enough absolute number of calls that are (2) or (3) that it *i= s* a problem. When I don't get a good caller ID, I mostly get nothing, and = indeed, there are some outbound services that have no caller ID or meaningf= ul Charge Number/ANI. I've had telemarketers spoof my office number on calls to others and it's a= truly painful experience. Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Mic= hael Hammer Sent: Wednesday, July 03, 2013 2:18 PM To: Henning.Schulzrinne@fcc.gov; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) My impression from this thread was that (3) was more often the case, and (1= ) was the minority. And, that there was little incentive thus far to change that. Thus, absence some "encouragement" from regulators, call completion is not impeded, since $$ come from call completion, not fro= m valid caller ID. Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 2:04 PM To: Michael Hammer; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) I'm probably missing something, but as far as I can tell, the situation today is: (1) Most calls have well-formatted "From" (CgN, ANI, ...) information that is truthful. (2) Some calls have well-formatted origin information that is spoofed. (3) A very small fraction of calls have ill-formatted caller ID information= , typically inserted by entities with something to hide or the occasionally clueless/bad-combination-of-circumstances cases. With validation, (1) would succeed, (2) would fail, as it should, and (3) would remain as-is (and also fail validation, most likely). If anything, as validation increases, since the originator of a call, particularly on the commercial side, has every incentive for the call to complete, legitimate (3) calls should move into (1). -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Wednesday, July 03, 2013 1:07 PM To: Henning Schulzrinne; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Yes, but where are the false data being injected? Also, these are links in a chain, that if one fails, the follow-on checks will also fail. If you have a large number of failures for valid users, then the recipient cannot rely on the feature. And, the end result is the same, meager adoption. Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 12:25 PM To: Michael Hammer; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) I don't see the contradiction: Today, we get perfectly-formatted, but substantially-false, callerID. Just because it's fake doesn't mean it's bad-looking... Indeed, the bad guys have every incentive to provide well-formatted numbers as otherwise the CNAM lookup will fail, defeating the purpose of rendering plausible textual caller ID information. ________________________________________ From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Michael Hammer [michael.hammer@yaanatech.com] Sent: Wednesday, July 03, 2013 12:11 PM To: Henning Schulzrinne; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Henning, The Caller-ID argument seems to run along these lines: SS7 PTSN works well, we get good caller ID. SIP world is problematic, we get robo-calling. Because we get good caller ID, we don't need to change how SIP operates today. That is a disconnect for me. Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 11:38 AM To: Michael Hammer; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) We're retreading the same territory, but I don't think anybody is talking about rewriting From. The process is Identity =3D Hash-and-sign(convert-to-E.164(From)) As long as the receiver can perform the same operation and get the same result, this works. For the reasons now repeated several times, receivers d= o seem to be able to make sense of inter-provider From information, as they use it mechanically for a variety of purposes. I just don't see the real problem - if From (and their SS7 kin) didn't work= , callerID would fail altogether. It obviously doesn't, for almost all calls. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Wednesday, July 03, 2013 11:22 AM To: br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Then that tells me From is the wrong answer. Mike -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, July 03, 2013 11:19 AM To: Michael Hammer Cc: timothy.dwight@verizon.com; stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Sure, but you get that the To has to go through rewrite to get it routed, but the From doesn't. It's all well and good to wave your hands and say "all SIP UAs must put ful= l e.164s in From" but it doesn't happen, and it's not going to happen. Today, rewrites of From happen, but not always to e.164s. We're either going to have to have those rewrites occur always to an e.164, include a full e.164 in a new header, or use P-A-I and require it be a full e.164 (or a combination). Brian On Jul 3, 2013, at 11:13 AM, Michael Hammer wrote: > All, > > It helps to read E.164. > It is a string of digits, max 15, no other characters, with CC, NDC, > and SN. > (There are variations on the names for those parts, but the concept is > the > same.) > If you provide a specification that unambiguously delimits that, you > are golden. > > Do not inject confusion by introducing dialing sting prefixes. > Do not inject confusion by introducing trunking indicators. > Do not inject confusion by introducing methods to group digits. > > If you want the phone number to get anywhere globally, you need to > know how to generate the E.164. > Any domain worth its salt knows how to go from a local representation > to a canonical one. > (And there are local representation secret sauce folks who know how to > do > that.) > > Mike > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: Wednesday, July 03, 2013 10:55 AM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org; dcrocker@bbiw.net > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for > STIR) > > The From problem is lack of country codes, and maybe worse. Consider > these possible From: contents > 5551212 > 2025551212 > 12025551212 > +12025551212 > and of course all the variations with parens, spaces, hyphens, commas, > periods, etc. > > Although the first is getting really rare, I think it still happens > > The problem with these is when they appear in From on an international > call > - the first 2 are the real problems. They would have to be rewritten. > > With To:, you get the variations with dial 9/8/... in enterprise > systems, and the 011 style prefix > > Brian > > > > On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" > wrote: > >> Could someone provide a few examples? I have to say I find this >> thread > hard to follow. I trust the individuals making the arguments to be > knowledgeable and honest, but personally I have little experience with > this "FROM header manipulation" that I'm told is so rampant. >> >> The only example I can think of is the "SIP trunking" use case I >> raised > previously (user part of URI in FROM and/or TO header may be > significant only within the dial plan of the associated Enterprise) > which was ruled out of scope for this activity. So I'm puzzled, what > use cases there are that > (a) are in scope for this exercise, and (b) involve manipulation of > the user part of the URI in the FROM header. >> >> Apologies in advance if this is obvious to everyone else and I'm the >> only > one who doesn't "get it". >> >> Thanks, >> >> Tim >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of > Brian Rosen >> Sent: Wednesday, July 03, 2013 9:23 AM >> To: dcrocker@bbiw.net >> Cc: stir@ietf.org >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for >> STIR) >> >> There are a lot of local variations out there, but they all have the > property that in order to route them, you need to be able to figure > out at least the "left" part of the e.164 is, and the right part has > to pass unscathed in order to work. Since everyone, and I mean > everyone, dealing with these systems knows what e.164s are, and how > they work, I don't think it's necessary, or even possible to describe > all of the various ways the strings might appear and what to do with them= . >> >> All we need say is that in order to work, the header contents has to >> be > able to have the canonical e.164 extracted with no knowledge at the > validator, and validations can occur anywhere in the call path. We'll > dress up that text a lot I am sure, but the notion that we could > write, or need a document describing all possible variations of how > telephone numbers may appear and how to extract the e.164 in each of > them seems to me to be silly. >> >> It may be possible to specify an algorithm however. >> >> Brian >> >> On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >> >>> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>>> Catching up (I was out for a week) >>>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>> >>>>> 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.) >>>> e.164s are much more constrained than the email address issues DKIM >>>> has > to deal with. We could have challenges with local dial plans, and > we've been discussing those issues, but the easy way out on those is > that they may not be covered if both ends don't understand the dial > plan the same way. >>>> >>>> So far, while we have one issue I'm concerned with (verifier not >>>> being > able to extract a canonical e.164 from the content of "From"), I don't > think the DKIM experience is particularly relevant. >>> >>> >>> Brian, >>> >>> Thanks. Good to hear. >>> >>> I assume there is a document that specifies all of the variations >>> that > will be encountered and how to deterministically and successfully > transform them into the single, canonical representation? >>> >>> Absent that, this topic remains a likely source of non-interoperability= . >>> >>> 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 Wed Jul 3 11:43: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 B1AAE11E8201 for ; Wed, 3 Jul 2013 11:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.781 X-Spam-Level: X-Spam-Status: No, score=-1.781 tagged_above=-999 required=5 tests=[AWL=0.818, 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 ZxOwicEQoktW for ; Wed, 3 Jul 2013 11:43:32 -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 94E1E11E8200 for ; Wed, 3 Jul 2013 11:43:31 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "'PFAUTZ, PENN L'" Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qfju36ah9Ux0e2HxhSF1PQN5lLiToAgAArZACAAAM/gIAAC30AgABB8ACABz9yAIAABZQAgAADigCAAAR8gIAABGkAgAAFRQCAAAFtAIAAAQiA//+/2HCAAE2/AP//v9zngABPxwD//8tOEAAJEvIAAACI8YAACC8hAA== Date: Wed, 3 Jul 2013 18:43:28 +0000 References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> , <00C069FD01E0324C9FFCADF539701DB3BBC11043@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC110E6@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC1124D@EX2K10MB1.corp.yaanatech.com> <38726EDA2109264987B45E29E758C4D604977C07@MISOUT7MSGUSR9N.ITServices.sbc.com> In-Reply-To: <38726EDA2109264987B45E29E758C4D604977C07@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="us-ascii" 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: Wed, 03 Jul 2013 18:43:35 -0000 I'll add that there are indeed rules against "calls for which identifying = information is missing or masked in ways that frustrate intercarrier billi= ng." See, for example, footnote 58 at http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-13-18A1.pdf and references therein, in particular 47 CFR 64.1601, at http://www.law.cornell.edu/cfr/text/47/64.1601 Henning -----Original Message----- From: PFAUTZ, PENN L [mailto:pp3129@att.com]=20 Sent: Wednesday, July 03, 2013 2:34 PM To: Michael Hammer; Henning Schulzrinne; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Mike: I think that (1) is actually the predominant case taking all calls in accou= nt. There is enough absolute number of calls that are (2) or (3) that it *i= s* a problem. When I don't get a good caller ID, I mostly get nothing, and = indeed, there are some outbound services that have no caller ID or meaningf= ul Charge Number/ANI. I've had telemarketers spoof my office number on calls to others and it's a= truly painful experience. Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Mic= hael Hammer Sent: Wednesday, July 03, 2013 2:18 PM To: Henning.Schulzrinne@fcc.gov; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) My impression from this thread was that (3) was more often the case, and (1= ) was the minority. And, that there was little incentive thus far to change that. Thus, absence some "encouragement" from regulators, call completion is not = impeded, since $$ come from call completion, not from valid caller ID. Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 2:04 PM To: Michael Hammer; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) I'm probably missing something, but as far as I can tell, the situation tod= ay is: (1) Most calls have well-formatted "From" (CgN, ANI, ...) information that = is truthful. (2) Some calls have well-formatted origin information that is spoofed. (3) A very small fraction of calls have ill-formatted caller ID information= , typically inserted by entities with something to hide or the occasionally= clueless/bad-combination-of-circumstances cases. With validation, (1) would succeed, (2) would fail, as it should, and (3) w= ould remain as-is (and also fail validation, most likely). If anything, as = validation increases, since the originator of a call, particularly on the c= ommercial side, has every incentive for the call to complete, legitimate (3) calls should move into (1). -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Wednesday, July 03, 2013 1:07 PM To: Henning Schulzrinne; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Yes, but where are the false data being injected? Also, these are links in a chain, that if one fails, the follow-on checks w= ill also fail. If you have a large number of failures for valid users, then the recipient = cannot rely on the feature. And, the end result is the same, meager adoption. Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 12:25 PM To: Michael Hammer; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) I don't see the contradiction: Today, we get perfectly-formatted, but subst= antially-false, callerID. Just because it's fake doesn't mean it's bad-look= ing... Indeed, the bad guys have every incentive to provide well-formatted numbers= as otherwise the CNAM lookup will fail, defeating the purpose of rendering= plausible textual caller ID information. ________________________________________ From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Michael Ha= mmer [michael.hammer@yaanatech.com] Sent: Wednesday, July 03, 2013 12:11 PM To: Henning Schulzrinne; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Henning, The Caller-ID argument seems to run along these lines: SS7 PTSN works well, we get good caller ID. SIP world is problematic, we get robo-calling. Because we get good caller ID, we don't need to change how SIP operates tod= ay. That is a disconnect for me. Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 11:38 AM To: Michael Hammer; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) We're retreading the same territory, but I don't think anybody is talking a= bout rewriting From. The process is Identity =3D Hash-and-sign(convert-to-E.164(From)) As long as the receiver can perform the same operation and get the same res= ult, this works. For the reasons now repeated several times, receivers do s= eem to be able to make sense of inter-provider From information, as they us= e it mechanically for a variety of purposes. I just don't see the real problem - if From (and their SS7 kin) didn't work= , callerID would fail altogether. It obviously doesn't, for almost all call= s. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Mic= hael Hammer Sent: Wednesday, July 03, 2013 11:22 AM To: br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Then that tells me From is the wrong answer. Mike -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, July 03, 2013 11:19 AM To: Michael Hammer Cc: timothy.dwight@verizon.com; stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Sure, but you get that the To has to go through rewrite to get it routed, b= ut the From doesn't. It's all well and good to wave your hands and say "all SIP UAs must put ful= l e.164s in From" but it doesn't happen, and it's not going to happen. Today, rewrites of From happen, but not always to e.164s. We're either goi= ng to have to have those rewrites occur always to an e.164, include a full = e.164 in a new header, or use P-A-I and require it be a full e.164 (or a co= mbination). Brian On Jul 3, 2013, at 11:13 AM, Michael Hammer wrote: > All, > > It helps to read E.164. > It is a string of digits, max 15, no other characters, with CC, NDC,=20 > and SN. > (There are variations on the names for those parts, but the concept is=20 > the > same.) > If you provide a specification that unambiguously delimits that, you=20 > are golden. > > Do not inject confusion by introducing dialing sting prefixes. > Do not inject confusion by introducing trunking indicators. > Do not inject confusion by introducing methods to group digits. > > If you want the phone number to get anywhere globally, you need to=20 > know how to generate the E.164. > Any domain worth its salt knows how to go from a local representation=20 > to a canonical one. > (And there are local representation secret sauce folks who know how to=20 > do > that.) > > Mike > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 > Of Brian Rosen > Sent: Wednesday, July 03, 2013 10:55 AM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org; dcrocker@bbiw.net > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for > STIR) > > The From problem is lack of country codes, and maybe worse. Consider=20 > these possible From: contents > 5551212 > 2025551212 > 12025551212 > +12025551212 > and of course all the variations with parens, spaces, hyphens, commas,=20 > periods, etc. > > Although the first is getting really rare, I think it still happens > > The problem with these is when they appear in From on an international=20 > call > - the first 2 are the real problems. They would have to be rewritten. > > With To:, you get the variations with dial 9/8/... in enterprise=20 > systems, and the 011 style prefix > > Brian > > > > On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" > wrote: > >> Could someone provide a few examples? I have to say I find this=20 >> thread > hard to follow. I trust the individuals making the arguments to be=20 > knowledgeable and honest, but personally I have little experience with=20 > this "FROM header manipulation" that I'm told is so rampant. >> >> The only example I can think of is the "SIP trunking" use case I=20 >> raised > previously (user part of URI in FROM and/or TO header may be=20 > significant only within the dial plan of the associated Enterprise)=20 > which was ruled out of scope for this activity. So I'm puzzled, what=20 > use cases there are that > (a) are in scope for this exercise, and (b) involve manipulation of=20 > the user part of the URI in the FROM header. >> >> Apologies in advance if this is obvious to everyone else and I'm the=20 >> only > one who doesn't "get it". >> >> Thanks, >> >> Tim >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of > Brian Rosen >> Sent: Wednesday, July 03, 2013 9:23 AM >> To: dcrocker@bbiw.net >> Cc: stir@ietf.org >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for >> STIR) >> >> There are a lot of local variations out there, but they all have the > property that in order to route them, you need to be able to figure=20 > out at least the "left" part of the e.164 is, and the right part has=20 > to pass unscathed in order to work. Since everyone, and I mean=20 > everyone, dealing with these systems knows what e.164s are, and how=20 > they work, I don't think it's necessary, or even possible to describe=20 > all of the various ways the strings might appear and what to do with them= . >> >> All we need say is that in order to work, the header contents has to=20 >> be > able to have the canonical e.164 extracted with no knowledge at the=20 > validator, and validations can occur anywhere in the call path. We'll=20 > dress up that text a lot I am sure, but the notion that we could=20 > write, or need a document describing all possible variations of how=20 > telephone numbers may appear and how to extract the e.164 in each of=20 > them seems to me to be silly. >> >> It may be possible to specify an algorithm however. >> >> Brian >> >> On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >> >>> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>>> Catching up (I was out for a week) >>>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>> >>>>> The experience with canonicalization algorithms for DKIM -- and=20 >>>>> it, > too, had to deal with in-transit modifications -- makes clear that=20 > it's a topic with challenges and compromises. (Hmmm. "compromises" > might be a pun, here.) >>>> e.164s are much more constrained than the email address issues DKIM=20 >>>> has > to deal with. We could have challenges with local dial plans, and=20 > we've been discussing those issues, but the easy way out on those is=20 > that they may not be covered if both ends don't understand the dial=20 > plan the same way. >>>> >>>> So far, while we have one issue I'm concerned with (verifier not=20 >>>> being > able to extract a canonical e.164 from the content of "From"), I don't=20 > think the DKIM experience is particularly relevant. >>> >>> >>> Brian, >>> >>> Thanks. Good to hear. >>> >>> I assume there is a document that specifies all of the variations=20 >>> that > will be encountered and how to deterministically and successfully=20 > transform them into the single, canonical representation? >>> >>> Absent that, this topic remains a likely source of non-interoperability= . >>> >>> 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 timothy.dwight@verizon.com Wed Jul 3 12:31: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 27B0C21F99BB for ; Wed, 3 Jul 2013 12:31: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=[AWL=0.000, 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 S6Hprpz-xba1 for ; Wed, 3 Jul 2013 12:31:16 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id C749021F9D5D for ; Wed, 3 Jul 2013 12:31:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe01.verizon.com with ESMTP; 03 Jul 2013 19:31:14 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.87,990,1363132800"; d="scan'208";a="502425475" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi03.verizon.com with ESMTP; 03 Jul 2013 19:31:13 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Wed, 3 Jul 2013 15:31:12 -0400 To: Henning Schulzrinne Date: Wed, 3 Jul 2013 15:31:10 -0400 Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qfju36ah9Ux0e2HxhSF1PQN5lLiToAgAArZACAAAM/gIAAC30AgABB8ACABz9yAIAABZQAgAADigCAAAR8gIAABGkAgAAFRQCAAAFtAIAAAQiA//+/2HCAAAx98IAAHdIwgAAVmoA= Message-ID: <2B0F677F0B95454297753F58D4A07FA3012801EEF0@FHDP1LUMXC7V31.us.one.verizon.com> References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> <2B0F677F0B95454297753F58D4A07FA3012801ED45@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] 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: Wed, 03 Jul 2013 19:31:21 -0000 Henning, I agree that there are multiple reasons for trying to improve compliance wi= th use of URI parameters. I'm a little concerned with statements I've seen= to the contrary - I understand the frustration (related to their frequent = misuse) but giving up and resorting to pure guessing, will just make things= worse. I think we're in agreement there. You're correct that people (and companies) care that their caller ID / call= ing name is presented correctly. They complain when it isn't, and we do ou= r best to fix it. It's a complicated system though, for example there may = be calling name data for a given number in many 'CNAM databases', and it ca= n take a while to track down and fix an error. Something to think about wi= th respect to the task at hand... it's easy to postulate 3rd parties contri= buting to the solution, but be careful what you ask for... tim -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Wednesday, July 03, 2013 1:08 PM To: Dwight, Timothy M (Tim) Cc: stir@ietf.org Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) If they don't, both numeric and textual callerID won't work at all, most l= ikely (or will show random garbage). Large companies presumably want their = calls to show usable callerID, so that people pick up the calls. (And indiv= iduals and small businesses will complain to the state PUC or the FCC.) I s= uspect that if United Airlines calls up their carrier and complains about m= angled callerIDs, somebody at that carrier will try to get this fixed - at = least at your company... -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] Sent: Wednesday, July 03, 2013 12:53 PM To: Henning Schulzrinne; 'Michael Hammer'; br@brianrosen.net Cc: stir@ietf.org; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Ah, so I wasn't as confused as I thought. Good to know. We are talking ab= out being able to translate the value in the FROM header to an Internationa= l E.164 number, on the terminating side of the call. Not over-write the va= lue in the message, but the 'convert-to-E.164' function has to return the s= ame value on the terminating side as it did on the originating side. So I'm back to my previous position - this is indeed possible, assuming eno= ugh contextual information is present. Which in general it must be since a= s Hadriel repeatedly assures us, this all (usually) works today. =20 The nature of the contextual information is different in SIP though. If pe= ople are going to signal FROM headers with national significant numbers in = the user part, they (or something in the path on the originating leg) had b= etter be religious about appending the phone-context parameter, so that on = the terminating leg it's possible to know what they meant. tim=20 -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 10:38 AM To: 'Michael Hammer'; br@brianrosen.net Cc: stir@ietf.org; Dwight, Timothy M (Tim); dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) We're retreading the same territory, but I don't think anybody is talking a= bout rewriting From. The process is Identity =3D Hash-and-sign(convert-to-E.164(From)) As long as the receiver can perform the same operation and get the same res= ult, this works. For the reasons now repeated several times, receivers do s= eem to be able to make sense of inter-provider From information, as they us= e it mechanically for a variety of purposes. I just don't see the real problem - if From (and their SS7 kin) didn't work= , callerID would fail altogether. It obviously doesn't, for almost all call= s. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Mic= hael Hammer Sent: Wednesday, July 03, 2013 11:22 AM To: br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Then that tells me From is the wrong answer. Mike -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, July 03, 2013 11:19 AM To: Michael Hammer Cc: timothy.dwight@verizon.com; stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Sure, but you get that the To has to go through rewrite to get it routed, b= ut the From doesn't. It's all well and good to wave your hands and say "all SIP UAs must put ful= l e.164s in From" but it doesn't happen, and it's not going to happen. Today, rewrites of From happen, but not always to e.164s. We're either goi= ng to have to have those rewrites occur always to an e.164, include a full = e.164 in a new header, or use P-A-I and require it be a full e.164 (or a co= mbination). Brian On Jul 3, 2013, at 11:13 AM, Michael Hammer wrote: > All, >=20 > It helps to read E.164. > It is a string of digits, max 15, no other characters, with CC, NDC,=20 > and SN. > (There are variations on the names for those parts, but the concept is=20 > the > same.) > If you provide a specification that unambiguously delimits that, you=20 > are golden. >=20 > Do not inject confusion by introducing dialing sting prefixes. > Do not inject confusion by introducing trunking indicators. > Do not inject confusion by introducing methods to group digits. >=20 > If you want the phone number to get anywhere globally, you need to=20 > know how to generate the E.164. > Any domain worth its salt knows how to go from a local representation=20 > to a canonical one. > (And there are local representation secret sauce folks who know how to=20 > do > that.) >=20 > Mike >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 > Of Brian Rosen > Sent: Wednesday, July 03, 2013 10:55 AM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org; dcrocker@bbiw.net > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for > STIR) >=20 > The From problem is lack of country codes, and maybe worse. Consider=20 > these possible From: contents > 5551212 > 2025551212 > 12025551212 > +12025551212 > and of course all the variations with parens, spaces, hyphens, commas,=20 > periods, etc. >=20 > Although the first is getting really rare, I think it still happens >=20 > The problem with these is when they appear in From on an international=20 > call > - the first 2 are the real problems. They would have to be rewritten. >=20 > With To:, you get the variations with dial 9/8/... in enterprise=20 > systems, and the 011 style prefix >=20 > Brian >=20 >=20 >=20 > On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" > wrote: >=20 >> Could someone provide a few examples? I have to say I find this=20 >> thread > hard to follow. I trust the individuals making the arguments to be=20 > knowledgeable and honest, but personally I have little experience with=20 > this "FROM header manipulation" that I'm told is so rampant. >>=20 >> The only example I can think of is the "SIP trunking" use case I=20 >> raised > previously (user part of URI in FROM and/or TO header may be=20 > significant only within the dial plan of the associated Enterprise)=20 > which was ruled out of scope for this activity. So I'm puzzled, what=20 > use cases there are that > (a) are in scope for this exercise, and (b) involve manipulation of=20 > the user part of the URI in the FROM header. >>=20 >> Apologies in advance if this is obvious to everyone else and I'm the=20 >> only > one who doesn't "get it". >>=20 >> Thanks, >>=20 >> Tim >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of > Brian Rosen >> Sent: Wednesday, July 03, 2013 9:23 AM >> To: dcrocker@bbiw.net >> Cc: stir@ietf.org >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for >> STIR) >>=20 >> There are a lot of local variations out there, but they all have the > property that in order to route them, you need to be able to figure=20 > out at least the "left" part of the e.164 is, and the right part has=20 > to pass unscathed in order to work. Since everyone, and I mean=20 > everyone, dealing with these systems knows what e.164s are, and how=20 > they work, I don't think it's necessary, or even possible to describe=20 > all of the various ways the strings might appear and what to do with them= . >>=20 >> All we need say is that in order to work, the header contents has to=20 >> be > able to have the canonical e.164 extracted with no knowledge at the=20 > validator, and validations can occur anywhere in the call path. We'll=20 > dress up that text a lot I am sure, but the notion that we could=20 > write, or need a document describing all possible variations of how=20 > telephone numbers may appear and how to extract the e.164 in each of=20 > them seems to me to be silly. >>=20 >> It may be possible to specify an algorithm however. >>=20 >> Brian >>=20 >> On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >>=20 >>> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>>> Catching up (I was out for a week) >>>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>>=20 >>>>> The experience with canonicalization algorithms for DKIM -- and=20 >>>>> it, > too, had to deal with in-transit modifications -- makes clear that=20 > it's a topic with challenges and compromises. (Hmmm. "compromises" > might be a pun, here.) >>>> e.164s are much more constrained than the email address issues DKIM=20 >>>> has > to deal with. We could have challenges with local dial plans, and=20 > we've been discussing those issues, but the easy way out on those is=20 > that they may not be covered if both ends don't understand the dial=20 > plan the same way. >>>>=20 >>>> So far, while we have one issue I'm concerned with (verifier not=20 >>>> being > able to extract a canonical e.164 from the content of "From"), I don't=20 > think the DKIM experience is particularly relevant. >>>=20 >>>=20 >>> Brian, >>>=20 >>> Thanks. Good to hear. >>>=20 >>> I assume there is a document that specifies all of the variations=20 >>> that > will be encountered and how to deterministically and successfully=20 > transform them into the single, canonical representation? >>>=20 >>> Absent that, this topic remains a likely source of non-interoperability= . >>>=20 >>> d/ >>>=20 >>>=20 >>> -- >>> Dave Crocker >>> Brandenburg InternetWorking >>> bbiw.net >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From timothy.dwight@verizon.com Wed Jul 3 12:43: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 A28E211E8224 for ; Wed, 3 Jul 2013 12:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 uSXMv+NiRfz1 for ; Wed, 3 Jul 2013 12:43:37 -0700 (PDT) Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) by ietfa.amsl.com (Postfix) with ESMTP id 399E511E8222 for ; Wed, 3 Jul 2013 12:43:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by omzsmtpe02.verizonbusiness.com with ESMTP; 03 Jul 2013 19:43:35 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.87,990,1363132800"; d="scan'208";a="502433729" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi03.verizon.com with ESMTP; 03 Jul 2013 19:43:34 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Wed, 3 Jul 2013 15:43:31 -0400 To: Michael Hammer , "Henning.Schulzrinne@fcc.gov" , "br@brianrosen.net" Date: Wed, 3 Jul 2013 15:43:29 -0400 Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qWRsjPKQFYKEy7+8dmUhlONZlLu4UAgAArZAD//42y0IAAgQkAgABB8ACABz9zAIAABZQAgAADigCAAAR8gIAABGkA//+NhfCAAHktAP//i4pgAA83oYAADZW/QP//oI2AgABqTFD//7FMAIAAcfAwgADOC6A= Message-ID: <2B0F677F0B95454297753F58D4A07FA3012801EF12@FHDP1LUMXC7V31.us.one.verizon.com> References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> , <00C069FD01E0324C9FFCADF539701DB3BBC11043@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC110E6@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC1124D@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC1124D@EX2K10MB1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "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: Wed, 03 Jul 2013 19:43:42 -0000 Let's not get too carried away. Much more than 50% of the time, calls today have valid (as in, properly for= matted) calling party identification. =20 You're right about the fundamental driver being economic. We get paid when= the call completes. But there are additional drivers that reach the same = conclusion. For example if there is no valid calling party identification,= we don't know whose 'fault' that is. We don't want to 'punish' the callin= g and called parties, who generally have no control over how the signaling = messages that establish their call, are formatted. =20 What we do is try and 'persuade' our customers (e.g., wholesale, Enterprise= ) and peering partners, to provide such information. Commercial terms and = conditions, that sort of thing. Tim -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20 Sent: Wednesday, July 03, 2013 1:18 PM To: Henning.Schulzrinne@fcc.gov; br@brianrosen.net Cc: stir@ietf.org; Dwight, Timothy M (Tim); dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) My impression from this thread was that (3) was more often the case, and (1= ) was the minority. And, that there was little incentive thus far to change that. Thus, absence some "encouragement" from regulators,=20 call completion is not impeded, since $$ come from call completion, not fro= m valid caller ID. Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Wednesday, July 03, 2013 2:04 PM To: Michael Hammer; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) I'm probably missing something, but as far as I can tell, the situation today is: (1) Most calls have well-formatted "From" (CgN, ANI, ...) information that is truthful. (2) Some calls have well-formatted origin information that is spoofed. (3) A very small fraction of calls have ill-formatted caller ID information= , typically inserted by entities with something to hide or the occasionally clueless/bad-combination-of-circumstances cases. With validation, (1) would succeed, (2) would fail, as it should, and (3) would remain as-is (and also fail validation, most likely). If anything, as validation increases, since the originator of a call, particularly on the commercial side, has every incentive for the call to complete, legitimate (3) calls should move into (1). -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Wednesday, July 03, 2013 1:07 PM To: Henning Schulzrinne; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Yes, but where are the false data being injected? Also, these are links in a chain, that if one fails, the follow-on checks will also fail. If you have a large number of failures for valid users, then the recipient cannot rely on the feature. And, the end result is the same, meager adoption. Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 12:25 PM To: Michael Hammer; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) I don't see the contradiction: Today, we get perfectly-formatted, but substantially-false, callerID. Just because it's fake doesn't mean it's bad-looking... Indeed, the bad guys have every incentive to provide well-formatted numbers as otherwise the CNAM lookup will fail, defeating the purpose of rendering plausible textual caller ID information. ________________________________________ From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Michael Hammer [michael.hammer@yaanatech.com] Sent: Wednesday, July 03, 2013 12:11 PM To: Henning Schulzrinne; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Henning, The Caller-ID argument seems to run along these lines: SS7 PTSN works well, we get good caller ID. SIP world is problematic, we get robo-calling. Because we get good caller ID, we don't need to change how SIP operates today. That is a disconnect for me. Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 11:38 AM To: Michael Hammer; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) We're retreading the same territory, but I don't think anybody is talking about rewriting From. The process is Identity =3D Hash-and-sign(convert-to-E.164(From)) As long as the receiver can perform the same operation and get the same result, this works. For the reasons now repeated several times, receivers d= o seem to be able to make sense of inter-provider From information, as they use it mechanically for a variety of purposes. I just don't see the real problem - if From (and their SS7 kin) didn't work= , callerID would fail altogether. It obviously doesn't, for almost all calls. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Wednesday, July 03, 2013 11:22 AM To: br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Then that tells me From is the wrong answer. Mike -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, July 03, 2013 11:19 AM To: Michael Hammer Cc: timothy.dwight@verizon.com; stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Sure, but you get that the To has to go through rewrite to get it routed, but the From doesn't. It's all well and good to wave your hands and say "all SIP UAs must put ful= l e.164s in From" but it doesn't happen, and it's not going to happen. Today, rewrites of From happen, but not always to e.164s. We're either going to have to have those rewrites occur always to an e.164, include a full e.164 in a new header, or use P-A-I and require it be a full e.164 (or a combination). Brian On Jul 3, 2013, at 11:13 AM, Michael Hammer wrote: > All, > > It helps to read E.164. > It is a string of digits, max 15, no other characters, with CC, NDC,=20 > and SN. > (There are variations on the names for those parts, but the concept is=20 > the > same.) > If you provide a specification that unambiguously delimits that, you=20 > are golden. > > Do not inject confusion by introducing dialing sting prefixes. > Do not inject confusion by introducing trunking indicators. > Do not inject confusion by introducing methods to group digits. > > If you want the phone number to get anywhere globally, you need to=20 > know how to generate the E.164. > Any domain worth its salt knows how to go from a local representation=20 > to a canonical one. > (And there are local representation secret sauce folks who know how to=20 > do > that.) > > Mike > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 > Of Brian Rosen > Sent: Wednesday, July 03, 2013 10:55 AM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org; dcrocker@bbiw.net > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for > STIR) > > The From problem is lack of country codes, and maybe worse. Consider=20 > these possible From: contents > 5551212 > 2025551212 > 12025551212 > +12025551212 > and of course all the variations with parens, spaces, hyphens, commas,=20 > periods, etc. > > Although the first is getting really rare, I think it still happens > > The problem with these is when they appear in From on an international=20 > call > - the first 2 are the real problems. They would have to be rewritten. > > With To:, you get the variations with dial 9/8/... in enterprise=20 > systems, and the 011 style prefix > > Brian > > > > On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" > wrote: > >> Could someone provide a few examples? I have to say I find this=20 >> thread > hard to follow. I trust the individuals making the arguments to be=20 > knowledgeable and honest, but personally I have little experience with=20 > this "FROM header manipulation" that I'm told is so rampant. >> >> The only example I can think of is the "SIP trunking" use case I=20 >> raised > previously (user part of URI in FROM and/or TO header may be=20 > significant only within the dial plan of the associated Enterprise)=20 > which was ruled out of scope for this activity. So I'm puzzled, what=20 > use cases there are that > (a) are in scope for this exercise, and (b) involve manipulation of=20 > the user part of the URI in the FROM header. >> >> Apologies in advance if this is obvious to everyone else and I'm the=20 >> only > one who doesn't "get it". >> >> Thanks, >> >> Tim >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of > Brian Rosen >> Sent: Wednesday, July 03, 2013 9:23 AM >> To: dcrocker@bbiw.net >> Cc: stir@ietf.org >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for >> STIR) >> >> There are a lot of local variations out there, but they all have the > property that in order to route them, you need to be able to figure=20 > out at least the "left" part of the e.164 is, and the right part has=20 > to pass unscathed in order to work. Since everyone, and I mean=20 > everyone, dealing with these systems knows what e.164s are, and how=20 > they work, I don't think it's necessary, or even possible to describe=20 > all of the various ways the strings might appear and what to do with them= . >> >> All we need say is that in order to work, the header contents has to=20 >> be > able to have the canonical e.164 extracted with no knowledge at the=20 > validator, and validations can occur anywhere in the call path. We'll=20 > dress up that text a lot I am sure, but the notion that we could=20 > write, or need a document describing all possible variations of how=20 > telephone numbers may appear and how to extract the e.164 in each of=20 > them seems to me to be silly. >> >> It may be possible to specify an algorithm however. >> >> Brian >> >> On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >> >>> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>>> Catching up (I was out for a week) >>>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>> >>>>> The experience with canonicalization algorithms for DKIM -- and=20 >>>>> it, > too, had to deal with in-transit modifications -- makes clear that=20 > it's a topic with challenges and compromises. (Hmmm. "compromises" > might be a pun, here.) >>>> e.164s are much more constrained than the email address issues DKIM=20 >>>> has > to deal with. We could have challenges with local dial plans, and=20 > we've been discussing those issues, but the easy way out on those is=20 > that they may not be covered if both ends don't understand the dial=20 > plan the same way. >>>> >>>> So far, while we have one issue I'm concerned with (verifier not=20 >>>> being > able to extract a canonical e.164 from the content of "From"), I don't=20 > think the DKIM experience is particularly relevant. >>> >>> >>> Brian, >>> >>> Thanks. Good to hear. >>> >>> I assume there is a document that specifies all of the variations=20 >>> that > will be encountered and how to deterministically and successfully=20 > transform them into the single, canonical representation? >>> >>> Absent that, this topic remains a likely source of non-interoperability= . >>> >>> 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 timothy.dwight@verizon.com Wed Jul 3 12: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 69B6811E8227 for ; Wed, 3 Jul 2013 12:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 i5gCz0yHOX5H for ; Wed, 3 Jul 2013 12:52:49 -0700 (PDT) Received: from fldsmtpe03.verizon.com (fldsmtpe03.verizon.com [140.108.26.142]) by ietfa.amsl.com (Postfix) with ESMTP id EFE2611E80D7 for ; Wed, 3 Jul 2013 12:52:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe03.verizon.com with ESMTP; 03 Jul 2013 19:52:48 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.87,990,1363132800"; d="scan'208";a="510503262" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi01.verizon.com with ESMTP; 03 Jul 2013 19:52:43 +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, 3 Jul 2013 15:52:43 -0400 To: Michael Hammer , "Henning.Schulzrinne@fcc.gov" Date: Wed, 3 Jul 2013 15:52:41 -0400 Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qWRsjPKQFYKEy7+8dmUhlONZlLu4UAgAArZAD//42y0IAAgQkAgABB8ACABz9zAIAABZQAgAADigCAAAR8gIAABGkA//+NhfCAAHktAP//i4pgAA83oYAAAp5oAAACn0yAAA5BnQAAGZGXkA== Message-ID: <2B0F677F0B95454297753F58D4A07FA3012801EF30@FHDP1LUMXC7V31.us.one.verizon.com> References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> <2B0F677F0B95454297753F58D4A07FA3012801ED45@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC1126B@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC1126B@EX2K10MB1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] 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: Wed, 03 Jul 2013 19:52:54 -0000 I'm not sure if you're serious, but calls "from" an 800 number aren't neces= sarily invalid. Call center phones may be set up that way, for example, be= cause they don't want their agents taking incoming calls directly. Messes = up their call distribution algorithms :-). If you get a harassing call from such a number, call your carrier. They ca= n track down who owns the 800 number. If it's spoofed, of course, you'll g= et the same [lack of] satisfaction you get when you complain about any call= from a spoofed number. Toll free numbers do present us with an interesting tangent in the certific= ate chain though... particularly since their 'ownership' can be split acros= s multiple entities and change quite rapidly. For example if I'm Joe's Fis= h Market I may get an 800 number 1-800-eat-fish and have it set up so that = AT&T handles half the calls and Verizon handles the other half. I can spli= t the calls by day of week, time of day, or even every-other-call. I wonde= r if this challenges any assumptions people are making, e.g., about the len= gth of time that a certificate would be valid. If Verizon only has the rig= ht to assert that number when it's Verizon's "turn", does that mean that th= e certificate ceases to be valid the next time anybody calls that 800 numbe= r? If so the cert may not be valid by the time the verifier wants to use i= t... Tim -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20 Sent: Wednesday, July 03, 2013 1:20 PM To: Henning.Schulzrinne@fcc.gov; Dwight, Timothy M (Tim) Cc: stir@ietf.org Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Ummm.... who do I call to complain about calls from 800 numbers? :) Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Wednesday, July 03, 2013 2:08 PM To: 'Dwight, Timothy M (Tim)' Cc: stir@ietf.org Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) If they don't, both numeric and textual callerID won't work at all, most likely (or will show random garbage). Large companies presumably want their calls to show usable callerID, so that people pick up the calls. (And individuals and small businesses will complain to the state PUC or the FCC.= ) I suspect that if United Airlines calls up their carrier and complains abou= t mangled callerIDs, somebody at that carrier will try to get this fixed - at least at your company... -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] Sent: Wednesday, July 03, 2013 12:53 PM To: Henning Schulzrinne; 'Michael Hammer'; br@brianrosen.net Cc: stir@ietf.org; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Ah, so I wasn't as confused as I thought. Good to know. We are talking about being able to translate the value in the FROM header to an International E.164 number, on the terminating side of the call. Not over-write the value in the message, but the 'convert-to-E.164' function ha= s to return the same value on the terminating side as it did on the originating side. So I'm back to my previous position - this is indeed possible, assuming enough contextual information is present. Which in general it must be sinc= e as Hadriel repeatedly assures us, this all (usually) works today. =20 The nature of the contextual information is different in SIP though. If people are going to signal FROM headers with national significant numbers i= n the user part, they (or something in the path on the originating leg) had better be religious about appending the phone-context parameter, so that on the terminating leg it's possible to know what they meant. tim=20 -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 10:38 AM To: 'Michael Hammer'; br@brianrosen.net Cc: stir@ietf.org; Dwight, Timothy M (Tim); dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) We're retreading the same territory, but I don't think anybody is talking about rewriting From. The process is Identity =3D Hash-and-sign(convert-to-E.164(From)) As long as the receiver can perform the same operation and get the same result, this works. For the reasons now repeated several times, receivers d= o seem to be able to make sense of inter-provider From information, as they use it mechanically for a variety of purposes. I just don't see the real problem - if From (and their SS7 kin) didn't work= , callerID would fail altogether. It obviously doesn't, for almost all calls. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Wednesday, July 03, 2013 11:22 AM To: br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Then that tells me From is the wrong answer. Mike -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, July 03, 2013 11:19 AM To: Michael Hammer Cc: timothy.dwight@verizon.com; stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Sure, but you get that the To has to go through rewrite to get it routed, but the From doesn't. It's all well and good to wave your hands and say "all SIP UAs must put ful= l e.164s in From" but it doesn't happen, and it's not going to happen. Today, rewrites of From happen, but not always to e.164s. We're either going to have to have those rewrites occur always to an e.164, include a full e.164 in a new header, or use P-A-I and require it be a full e.164 (or a combination). Brian On Jul 3, 2013, at 11:13 AM, Michael Hammer wrote: > All, >=20 > It helps to read E.164. > It is a string of digits, max 15, no other characters, with CC, NDC,=20 > and SN. > (There are variations on the names for those parts, but the concept is=20 > the > same.) > If you provide a specification that unambiguously delimits that, you=20 > are golden. >=20 > Do not inject confusion by introducing dialing sting prefixes. > Do not inject confusion by introducing trunking indicators. > Do not inject confusion by introducing methods to group digits. >=20 > If you want the phone number to get anywhere globally, you need to=20 > know how to generate the E.164. > Any domain worth its salt knows how to go from a local representation=20 > to a canonical one. > (And there are local representation secret sauce folks who know how to=20 > do > that.) >=20 > Mike >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 > Of Brian Rosen > Sent: Wednesday, July 03, 2013 10:55 AM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org; dcrocker@bbiw.net > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for > STIR) >=20 > The From problem is lack of country codes, and maybe worse. Consider=20 > these possible From: contents > 5551212 > 2025551212 > 12025551212 > +12025551212 > and of course all the variations with parens, spaces, hyphens, commas,=20 > periods, etc. >=20 > Although the first is getting really rare, I think it still happens >=20 > The problem with these is when they appear in From on an international=20 > call > - the first 2 are the real problems. They would have to be rewritten. >=20 > With To:, you get the variations with dial 9/8/... in enterprise=20 > systems, and the 011 style prefix >=20 > Brian >=20 >=20 >=20 > On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" > wrote: >=20 >> Could someone provide a few examples? I have to say I find this=20 >> thread > hard to follow. I trust the individuals making the arguments to be=20 > knowledgeable and honest, but personally I have little experience with=20 > this "FROM header manipulation" that I'm told is so rampant. >>=20 >> The only example I can think of is the "SIP trunking" use case I=20 >> raised > previously (user part of URI in FROM and/or TO header may be=20 > significant only within the dial plan of the associated Enterprise)=20 > which was ruled out of scope for this activity. So I'm puzzled, what=20 > use cases there are that > (a) are in scope for this exercise, and (b) involve manipulation of=20 > the user part of the URI in the FROM header. >>=20 >> Apologies in advance if this is obvious to everyone else and I'm the=20 >> only > one who doesn't "get it". >>=20 >> Thanks, >>=20 >> Tim >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of > Brian Rosen >> Sent: Wednesday, July 03, 2013 9:23 AM >> To: dcrocker@bbiw.net >> Cc: stir@ietf.org >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for >> STIR) >>=20 >> There are a lot of local variations out there, but they all have the > property that in order to route them, you need to be able to figure=20 > out at least the "left" part of the e.164 is, and the right part has=20 > to pass unscathed in order to work. Since everyone, and I mean=20 > everyone, dealing with these systems knows what e.164s are, and how=20 > they work, I don't think it's necessary, or even possible to describe=20 > all of the various ways the strings might appear and what to do with them= . >>=20 >> All we need say is that in order to work, the header contents has to=20 >> be > able to have the canonical e.164 extracted with no knowledge at the=20 > validator, and validations can occur anywhere in the call path. We'll=20 > dress up that text a lot I am sure, but the notion that we could=20 > write, or need a document describing all possible variations of how=20 > telephone numbers may appear and how to extract the e.164 in each of=20 > them seems to me to be silly. >>=20 >> It may be possible to specify an algorithm however. >>=20 >> Brian >>=20 >> On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >>=20 >>> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>>> Catching up (I was out for a week) >>>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>>=20 >>>>> The experience with canonicalization algorithms for DKIM -- and=20 >>>>> it, > too, had to deal with in-transit modifications -- makes clear that=20 > it's a topic with challenges and compromises. (Hmmm. "compromises" > might be a pun, here.) >>>> e.164s are much more constrained than the email address issues DKIM=20 >>>> has > to deal with. We could have challenges with local dial plans, and=20 > we've been discussing those issues, but the easy way out on those is=20 > that they may not be covered if both ends don't understand the dial=20 > plan the same way. >>>>=20 >>>> So far, while we have one issue I'm concerned with (verifier not=20 >>>> being > able to extract a canonical e.164 from the content of "From"), I don't=20 > think the DKIM experience is particularly relevant. >>>=20 >>>=20 >>> Brian, >>>=20 >>> Thanks. Good to hear. >>>=20 >>> I assume there is a document that specifies all of the variations=20 >>> that > will be encountered and how to deterministically and successfully=20 > transform them into the single, canonical representation? >>>=20 >>> Absent that, this topic remains a likely source of non-interoperability= . >>>=20 >>> d/ >>>=20 >>>=20 >>> -- >>> Dave Crocker >>> Brandenburg InternetWorking >>> bbiw.net >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing 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 Jul 3 13:21: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 2299611E8226 for ; Wed, 3 Jul 2013 13:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 XLq0iFIdTesa for ; Wed, 3 Jul 2013 13:21: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 D60D111E8220 for ; Wed, 3 Jul 2013 13:21: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; Wed, 3 Jul 2013 13:21:06 -0700 From: Michael Hammer To: "Henning.Schulzrinne@fcc.gov" , "br@brianrosen.net" Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qWRsjPKQFYKEy7+8dmUhlONZlLu4UAgAArZAD//42y0IAAgQkAgABB8ACABz9zAIAABZQAgAADigCAAAR8gIAABGkA//+NhfCAAHktAP//i4pgAA83oYAADZW/QP//oI2AgABqTFD//7FMAIAAcfAw//+WN4CAAFdJcA== Date: Wed, 3 Jul 2013 20:21:05 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC11382@EX2K10MB1.corp.yaanatech.com> References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> , <00C069FD01E0324C9FFCADF539701DB3BBC11043@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC110E6@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC1124D@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.96] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0133_01CE7809.50814150" MIME-Version: 1.0 Cc: "stir@ietf.org" , "timothy.dwight@verizon.com" , "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: Wed, 03 Jul 2013 20:21:15 -0000 ------=_NextPart_000_0133_01CE7809.50814150 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I only use mobile phone, so not sure I can extrapolate my personal experience. Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 2:33 PM To: Michael Hammer; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) I don't think anybody has complete statistical data, but from what I can tell, for almost all domestic calls, callerID tends to work (whether it's spoofed or not). Given that a significant fraction of call origination is now VoIP (in some areas, close to 50%), courtesy of MSOs, there's usually some SIP in the call path. Is your experience that a large fraction of your incoming calls have mangled callerID? -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Wednesday, July 03, 2013 2:18 PM To: Henning Schulzrinne; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) My impression from this thread was that (3) was more often the case, and (1) was the minority. And, that there was little incentive thus far to change that. Thus, absence some "encouragement" from regulators, call completion is not impeded, since $$ come from call completion, not from valid caller ID. Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 2:04 PM To: Michael Hammer; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) I'm probably missing something, but as far as I can tell, the situation today is: (1) Most calls have well-formatted "From" (CgN, ANI, ...) information that is truthful. (2) Some calls have well-formatted origin information that is spoofed. (3) A very small fraction of calls have ill-formatted caller ID information, typically inserted by entities with something to hide or the occasionally clueless/bad-combination-of-circumstances cases. With validation, (1) would succeed, (2) would fail, as it should, and (3) would remain as-is (and also fail validation, most likely). If anything, as validation increases, since the originator of a call, particularly on the commercial side, has every incentive for the call to complete, legitimate (3) calls should move into (1). -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Wednesday, July 03, 2013 1:07 PM To: Henning Schulzrinne; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Yes, but where are the false data being injected? Also, these are links in a chain, that if one fails, the follow-on checks will also fail. If you have a large number of failures for valid users, then the recipient cannot rely on the feature. And, the end result is the same, meager adoption. Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 12:25 PM To: Michael Hammer; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) I don't see the contradiction: Today, we get perfectly-formatted, but substantially-false, callerID. Just because it's fake doesn't mean it's bad-looking... Indeed, the bad guys have every incentive to provide well-formatted numbers as otherwise the CNAM lookup will fail, defeating the purpose of rendering plausible textual caller ID information. ________________________________________ From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Michael Hammer [michael.hammer@yaanatech.com] Sent: Wednesday, July 03, 2013 12:11 PM To: Henning Schulzrinne; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Henning, The Caller-ID argument seems to run along these lines: SS7 PTSN works well, we get good caller ID. SIP world is problematic, we get robo-calling. Because we get good caller ID, we don't need to change how SIP operates today. That is a disconnect for me. Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 11:38 AM To: Michael Hammer; br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) We're retreading the same territory, but I don't think anybody is talking about rewriting From. The process is Identity = Hash-and-sign(convert-to-E.164(From)) As long as the receiver can perform the same operation and get the same result, this works. For the reasons now repeated several times, receivers do seem to be able to make sense of inter-provider From information, as they use it mechanically for a variety of purposes. I just don't see the real problem - if From (and their SS7 kin) didn't work, callerID would fail altogether. It obviously doesn't, for almost all calls. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Wednesday, July 03, 2013 11:22 AM To: br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Then that tells me From is the wrong answer. Mike -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, July 03, 2013 11:19 AM To: Michael Hammer Cc: timothy.dwight@verizon.com; stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Sure, but you get that the To has to go through rewrite to get it routed, but the From doesn't. It's all well and good to wave your hands and say "all SIP UAs must put full e.164s in From" but it doesn't happen, and it's not going to happen. Today, rewrites of From happen, but not always to e.164s. We're either going to have to have those rewrites occur always to an e.164, include a full e.164 in a new header, or use P-A-I and require it be a full e.164 (or a combination). Brian On Jul 3, 2013, at 11:13 AM, Michael Hammer wrote: > All, > > It helps to read E.164. > It is a string of digits, max 15, no other characters, with CC, NDC, > and SN. > (There are variations on the names for those parts, but the concept is > the > same.) > If you provide a specification that unambiguously delimits that, you > are golden. > > Do not inject confusion by introducing dialing sting prefixes. > Do not inject confusion by introducing trunking indicators. > Do not inject confusion by introducing methods to group digits. > > If you want the phone number to get anywhere globally, you need to > know how to generate the E.164. > Any domain worth its salt knows how to go from a local representation > to a canonical one. > (And there are local representation secret sauce folks who know how to > do > that.) > > Mike > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: Wednesday, July 03, 2013 10:55 AM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org; dcrocker@bbiw.net > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for > STIR) > > The From problem is lack of country codes, and maybe worse. Consider > these possible From: contents > 5551212 > 2025551212 > 12025551212 > +12025551212 > and of course all the variations with parens, spaces, hyphens, commas, > periods, etc. > > Although the first is getting really rare, I think it still happens > > The problem with these is when they appear in From on an international > call > - the first 2 are the real problems. They would have to be rewritten. > > With To:, you get the variations with dial 9/8/... in enterprise > systems, and the 011 style prefix > > Brian > > > > On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" > wrote: > >> Could someone provide a few examples? I have to say I find this >> thread > hard to follow. I trust the individuals making the arguments to be > knowledgeable and honest, but personally I have little experience with > this "FROM header manipulation" that I'm told is so rampant. >> >> The only example I can think of is the "SIP trunking" use case I >> raised > previously (user part of URI in FROM and/or TO header may be > significant only within the dial plan of the associated Enterprise) > which was ruled out of scope for this activity. So I'm puzzled, what > use cases there are that > (a) are in scope for this exercise, and (b) involve manipulation of > the user part of the URI in the FROM header. >> >> Apologies in advance if this is obvious to everyone else and I'm the >> only > one who doesn't "get it". >> >> Thanks, >> >> Tim >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of > Brian Rosen >> Sent: Wednesday, July 03, 2013 9:23 AM >> To: dcrocker@bbiw.net >> Cc: stir@ietf.org >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for >> STIR) >> >> There are a lot of local variations out there, but they all have the > property that in order to route them, you need to be able to figure > out at least the "left" part of the e.164 is, and the right part has > to pass unscathed in order to work. Since everyone, and I mean > everyone, dealing with these systems knows what e.164s are, and how > they work, I don't think it's necessary, or even possible to describe > all of the various ways the strings might appear and what to do with them. >> >> All we need say is that in order to work, the header contents has to >> be > able to have the canonical e.164 extracted with no knowledge at the > validator, and validations can occur anywhere in the call path. We'll > dress up that text a lot I am sure, but the notion that we could > write, or need a document describing all possible variations of how > telephone numbers may appear and how to extract the e.164 in each of > them seems to me to be silly. >> >> It may be possible to specify an algorithm however. >> >> Brian >> >> On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >> >>> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>>> Catching up (I was out for a week) >>>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>> >>>>> 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.) >>>> e.164s are much more constrained than the email address issues DKIM >>>> has > to deal with. We could have challenges with local dial plans, and > we've been discussing those issues, but the easy way out on those is > that they may not be covered if both ends don't understand the dial > plan the same way. >>>> >>>> So far, while we have one issue I'm concerned with (verifier not >>>> being > able to extract a canonical e.164 from the content of "From"), I don't > think the DKIM experience is particularly relevant. >>> >>> >>> Brian, >>> >>> Thanks. Good to hear. >>> >>> I assume there is a document that specifies all of the variations >>> that > will be encountered and how to deterministically and successfully > transform them into the single, canonical representation? >>> >>> Absent that, this topic remains a likely source of non-interoperability. >>> >>> 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_0133_01CE7809.50814150 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcw MzIwMjEwNFowIwYJKoZIhvcNAQkEMRYEFL77RINy9sb+4FSs6VJGUP6JemY+MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAXHFuSqBwV4drF4h96JtE+E+LLqij1VWCoJuz4KsU KoaSBNCPMrWDu2cRX8s15++yiVoYUmoCPnO4eIYkbOH9oI/uZebXWrLKLXZTsTwwuazEKLeXpCCX mTfGy0H9is7FZ1GXTDriob9FC/BaEmLbnKK8IJn/eNQp51ldId3o8tAfdWVMp4wpjj0r8qhuPZse e+gdF8FN0UpBUMyrCmLeQ4AX9/7tfZ9QqyCuL8H8GrXYX0bmaVyl2O9nfJqRL8yEZdSpNTHYWpT9 drDSdtZR6mb79U3yE+rj/83jpkF6VDChGBdEsKALTyNH1muJru7ibiCbNmb12qWRAbb6vmGLoQAA AAAAAA== ------=_NextPart_000_0133_01CE7809.50814150-- From michael.hammer@yaanatech.com Wed Jul 3 13:25: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 AED0321F9C90 for ; Wed, 3 Jul 2013 13:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 8NkI0NyU5m+Z for ; Wed, 3 Jul 2013 13:25: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 5C99621F9C85 for ; Wed, 3 Jul 2013 13:25:16 -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, 3 Jul 2013 13:25:16 -0700 From: Michael Hammer To: "timothy.dwight@verizon.com" , "Henning.Schulzrinne@fcc.gov" Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qWRsjPKQFYKEy7+8dmUhlONZlLu4UAgAArZAD//42y0IAAgQkAgABB8ACABz9zAIAABZQAgAADigCAAAR8gIAABGkA//+NhfCAAHktAP//i4pgAA83oYAAAp5oAAACn0yAAA5BnQAAGZGXkAAxuycA Date: Wed, 3 Jul 2013 20:25:14 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC113A3@EX2K10MB1.corp.yaanatech.com> References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> <2B0F677F0B95454297753F58D4A07FA3012801ED45@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC1126B@EX2K10MB1.corp.yaanatech.com> <2B0F677F0B95454297753F58D4A07FA3012801EF30@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3012801EF30@FHDP1LUMXC7V31.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.96] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_014C_01CE7809.E5079040" 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: Wed, 03 Jul 2013 20:25:20 -0000 ------=_NextPart_000_014C_01CE7809.E5079040 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I was half-joking. But, most of my annoying calls are from such numbers. But, at same time when United or Amtrak tells me something is up with my travel plans, it is 800 as well. Mike -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] Sent: Wednesday, July 03, 2013 3:53 PM To: Michael Hammer; Henning.Schulzrinne@fcc.gov Cc: stir@ietf.org Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) I'm not sure if you're serious, but calls "from" an 800 number aren't necessarily invalid. Call center phones may be set up that way, for example, because they don't want their agents taking incoming calls directly. Messes up their call distribution algorithms :-). If you get a harassing call from such a number, call your carrier. They can track down who owns the 800 number. If it's spoofed, of course, you'll get the same [lack of] satisfaction you get when you complain about any call from a spoofed number. Toll free numbers do present us with an interesting tangent in the certificate chain though... particularly since their 'ownership' can be split across multiple entities and change quite rapidly. For example if I'm Joe's Fish Market I may get an 800 number 1-800-eat-fish and have it set up so that AT&T handles half the calls and Verizon handles the other half. I can split the calls by day of week, time of day, or even every-other-call. I wonder if this challenges any assumptions people are making, e.g., about the length of time that a certificate would be valid. If Verizon only has the right to assert that number when it's Verizon's "turn", does that mean that the certificate ceases to be valid the next time anybody calls that 800 number? If so the cert may not be valid by the time the verifier wants to use it... Tim -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Wednesday, July 03, 2013 1:20 PM To: Henning.Schulzrinne@fcc.gov; Dwight, Timothy M (Tim) Cc: stir@ietf.org Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Ummm.... who do I call to complain about calls from 800 numbers? :) Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Wednesday, July 03, 2013 2:08 PM To: 'Dwight, Timothy M (Tim)' Cc: stir@ietf.org Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) If they don't, both numeric and textual callerID won't work at all, most likely (or will show random garbage). Large companies presumably want their calls to show usable callerID, so that people pick up the calls. (And individuals and small businesses will complain to the state PUC or the FCC.) I suspect that if United Airlines calls up their carrier and complains about mangled callerIDs, somebody at that carrier will try to get this fixed - at least at your company... -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] Sent: Wednesday, July 03, 2013 12:53 PM To: Henning Schulzrinne; 'Michael Hammer'; br@brianrosen.net Cc: stir@ietf.org; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Ah, so I wasn't as confused as I thought. Good to know. We are talking about being able to translate the value in the FROM header to an International E.164 number, on the terminating side of the call. Not over-write the value in the message, but the 'convert-to-E.164' function has to return the same value on the terminating side as it did on the originating side. So I'm back to my previous position - this is indeed possible, assuming enough contextual information is present. Which in general it must be since as Hadriel repeatedly assures us, this all (usually) works today. The nature of the contextual information is different in SIP though. If people are going to signal FROM headers with national significant numbers in the user part, they (or something in the path on the originating leg) had better be religious about appending the phone-context parameter, so that on the terminating leg it's possible to know what they meant. tim -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 10:38 AM To: 'Michael Hammer'; br@brianrosen.net Cc: stir@ietf.org; Dwight, Timothy M (Tim); dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) We're retreading the same territory, but I don't think anybody is talking about rewriting From. The process is Identity = Hash-and-sign(convert-to-E.164(From)) As long as the receiver can perform the same operation and get the same result, this works. For the reasons now repeated several times, receivers do seem to be able to make sense of inter-provider From information, as they use it mechanically for a variety of purposes. I just don't see the real problem - if From (and their SS7 kin) didn't work, callerID would fail altogether. It obviously doesn't, for almost all calls. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Wednesday, July 03, 2013 11:22 AM To: br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Then that tells me From is the wrong answer. Mike -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, July 03, 2013 11:19 AM To: Michael Hammer Cc: timothy.dwight@verizon.com; stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Sure, but you get that the To has to go through rewrite to get it routed, but the From doesn't. It's all well and good to wave your hands and say "all SIP UAs must put full e.164s in From" but it doesn't happen, and it's not going to happen. Today, rewrites of From happen, but not always to e.164s. We're either going to have to have those rewrites occur always to an e.164, include a full e.164 in a new header, or use P-A-I and require it be a full e.164 (or a combination). Brian On Jul 3, 2013, at 11:13 AM, Michael Hammer wrote: > All, > > It helps to read E.164. > It is a string of digits, max 15, no other characters, with CC, NDC, > and SN. > (There are variations on the names for those parts, but the concept is > the > same.) > If you provide a specification that unambiguously delimits that, you > are golden. > > Do not inject confusion by introducing dialing sting prefixes. > Do not inject confusion by introducing trunking indicators. > Do not inject confusion by introducing methods to group digits. > > If you want the phone number to get anywhere globally, you need to > know how to generate the E.164. > Any domain worth its salt knows how to go from a local representation > to a canonical one. > (And there are local representation secret sauce folks who know how to > do > that.) > > Mike > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: Wednesday, July 03, 2013 10:55 AM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org; dcrocker@bbiw.net > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for > STIR) > > The From problem is lack of country codes, and maybe worse. Consider > these possible From: contents > 5551212 > 2025551212 > 12025551212 > +12025551212 > and of course all the variations with parens, spaces, hyphens, commas, > periods, etc. > > Although the first is getting really rare, I think it still happens > > The problem with these is when they appear in From on an international > call > - the first 2 are the real problems. They would have to be rewritten. > > With To:, you get the variations with dial 9/8/... in enterprise > systems, and the 011 style prefix > > Brian > > > > On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" > wrote: > >> Could someone provide a few examples? I have to say I find this >> thread > hard to follow. I trust the individuals making the arguments to be > knowledgeable and honest, but personally I have little experience with > this "FROM header manipulation" that I'm told is so rampant. >> >> The only example I can think of is the "SIP trunking" use case I >> raised > previously (user part of URI in FROM and/or TO header may be > significant only within the dial plan of the associated Enterprise) > which was ruled out of scope for this activity. So I'm puzzled, what > use cases there are that > (a) are in scope for this exercise, and (b) involve manipulation of > the user part of the URI in the FROM header. >> >> Apologies in advance if this is obvious to everyone else and I'm the >> only > one who doesn't "get it". >> >> Thanks, >> >> Tim >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of > Brian Rosen >> Sent: Wednesday, July 03, 2013 9:23 AM >> To: dcrocker@bbiw.net >> Cc: stir@ietf.org >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for >> STIR) >> >> There are a lot of local variations out there, but they all have the > property that in order to route them, you need to be able to figure > out at least the "left" part of the e.164 is, and the right part has > to pass unscathed in order to work. Since everyone, and I mean > everyone, dealing with these systems knows what e.164s are, and how > they work, I don't think it's necessary, or even possible to describe > all of the various ways the strings might appear and what to do with them. >> >> All we need say is that in order to work, the header contents has to >> be > able to have the canonical e.164 extracted with no knowledge at the > validator, and validations can occur anywhere in the call path. We'll > dress up that text a lot I am sure, but the notion that we could > write, or need a document describing all possible variations of how > telephone numbers may appear and how to extract the e.164 in each of > them seems to me to be silly. >> >> It may be possible to specify an algorithm however. >> >> Brian >> >> On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >> >>> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>>> Catching up (I was out for a week) >>>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>> >>>>> 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.) >>>> e.164s are much more constrained than the email address issues DKIM >>>> has > to deal with. We could have challenges with local dial plans, and > we've been discussing those issues, but the easy way out on those is > that they may not be covered if both ends don't understand the dial > plan the same way. >>>> >>>> So far, while we have one issue I'm concerned with (verifier not >>>> being > able to extract a canonical e.164 from the content of "From"), I don't > think the DKIM experience is particularly relevant. >>> >>> >>> Brian, >>> >>> Thanks. Good to hear. >>> >>> I assume there is a document that specifies all of the variations >>> that > will be encountered and how to deterministically and successfully > transform them into the single, canonical representation? >>> >>> Absent that, this topic remains a likely source of non-interoperability. >>> >>> 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_014C_01CE7809.E5079040 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcw MzIwMjUxM1owIwYJKoZIhvcNAQkEMRYEFPWzJgQgiAmmZamglCoGoFWgG2xwMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAYO8g8T/Zl2z8n469gHUcVfzFv1WJSBRanhBd8BSD 1KzFLaLOpZ9mHfKG/G/rhNYGMLAYktH1dGommkDwMKISgyEVh2nOHymkinmMOpcqQrjdhkfd9NDo u7RcLdDPOCKer6TuXfn8OM/5fUxQfPelLoQ7ZuiPGbI0X92cwx/Uwsatetk3lLba0HjPUU7Yb/bo 21pL4uSpe11UIViE1DpNWYjjMf1Y48sNTyq//YYpPMBy7kmT7m9vEPYpSMVPNkWsccDQVuiGOUtG cu1iGrZ5/Du/9CJ2wZHluwG2pUjlMZkmKe3yFWGpMvYKqmoRd2gyBLJWzhQlDD43kFwbM1uzbAAA AAAAAA== ------=_NextPart_000_014C_01CE7809.E5079040-- From Henning.Schulzrinne@fcc.gov Wed Jul 3 13:28: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 B6A1A21F9C72 for ; Wed, 3 Jul 2013 13:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=0.777, 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 xQ9BYjsXz2GE for ; Wed, 3 Jul 2013 13:28:16 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 6931511E80CC for ; Wed, 3 Jul 2013 13:28:16 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "'Dwight, Timothy M (Tim)'" Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qfju36ah9Ux0e2HxhSF1PQN5lLiToAgAArZACAAAM/gIAAC30AgABB8ACABz9yAIAABZQAgAADigCAAAR8gIAABGkAgAAFRQCAAAFtAIAAAQiA//+/2HCAAAx98IAAHdIwgABHcICAABnpgP//xY/Q Date: Wed, 3 Jul 2013 20:28:14 +0000 References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> <2B0F677F0B95454297753F58D4A07FA3012801ED45@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC1126B@EX2K10MB1.corp.yaanatech.com> <2B0F677F0B95454297753F58D4A07FA3012801EF30@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3012801EF30@FHDP1LUMXC7V31.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] 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: Wed, 03 Jul 2013 20:28:20 -0000 My understanding is that 800 numbers are assigned by SMS/800 via RespOrgs. = They might handle the certificates. (Each 800# is, as far as I know, only a= t one RespOrg at a time.) This would only apply to outbound calls that show= that 800 number, which probably doesn't include Joe's Fish Market. If Unit= ed Airlines uses multiple outbound call centers, they can use the same Resp= Org-issued certificate to sign their outbound calls. (We can discuss variou= s delegation mechanisms, with SMS/800 as the root, but that's getting into = irrelevant operational details.) -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com]=20 Sent: Wednesday, July 03, 2013 3:53 PM To: Michael Hammer; Henning Schulzrinne Cc: stir@ietf.org Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) I'm not sure if you're serious, but calls "from" an 800 number aren't neces= sarily invalid. Call center phones may be set up that way, for example, be= cause they don't want their agents taking incoming calls directly. Messes = up their call distribution algorithms :-). If you get a harassing call from such a number, call your carrier. They ca= n track down who owns the 800 number. If it's spoofed, of course, you'll g= et the same [lack of] satisfaction you get when you complain about any call= from a spoofed number. Toll free numbers do present us with an interesting tangent in the certific= ate chain though... particularly since their 'ownership' can be split acros= s multiple entities and change quite rapidly. For example if I'm Joe's Fis= h Market I may get an 800 number 1-800-eat-fish and have it set up so that = AT&T handles half the calls and Verizon handles the other half. I can spli= t the calls by day of week, time of day, or even every-other-call. I wonde= r if this challenges any assumptions people are making, e.g., about the len= gth of time that a certificate would be valid. If Verizon only has the rig= ht to assert that number when it's Verizon's "turn", does that mean that th= e certificate ceases to be valid the next time anybody calls that 800 numbe= r? If so the cert may not be valid by the time the verifier wants to use i= t... Tim -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Wednesday, July 03, 2013 1:20 PM To: Henning.Schulzrinne@fcc.gov; Dwight, Timothy M (Tim) Cc: stir@ietf.org Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Ummm.... who do I call to complain about calls from 800 numbers? :) Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hen= ning Schulzrinne Sent: Wednesday, July 03, 2013 2:08 PM To: 'Dwight, Timothy M (Tim)' Cc: stir@ietf.org Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) If they don't, both numeric and textual callerID won't work at all, most l= ikely (or will show random garbage). Large companies presumably want their = calls to show usable callerID, so that people pick up the calls. (And indiv= iduals and small businesses will complain to the state PUC or the FCC.) I s= uspect that if United Airlines calls up their carrier and complains about m= angled callerIDs, somebody at that carrier will try to get this fixed - at = least at your company... -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] Sent: Wednesday, July 03, 2013 12:53 PM To: Henning Schulzrinne; 'Michael Hammer'; br@brianrosen.net Cc: stir@ietf.org; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Ah, so I wasn't as confused as I thought. Good to know. We are talking ab= out being able to translate the value in the FROM header to an Internationa= l E.164 number, on the terminating side of the call. Not over-write the va= lue in the message, but the 'convert-to-E.164' function has to return the s= ame value on the terminating side as it did on the originating side. So I'm back to my previous position - this is indeed possible, assuming eno= ugh contextual information is present. Which in general it must be since a= s Hadriel repeatedly assures us, this all (usually) works today. =20 The nature of the contextual information is different in SIP though. If pe= ople are going to signal FROM headers with national significant numbers in = the user part, they (or something in the path on the originating leg) had b= etter be religious about appending the phone-context parameter, so that on = the terminating leg it's possible to know what they meant. tim=20 -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 10:38 AM To: 'Michael Hammer'; br@brianrosen.net Cc: stir@ietf.org; Dwight, Timothy M (Tim); dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) We're retreading the same territory, but I don't think anybody is talking a= bout rewriting From. The process is Identity =3D Hash-and-sign(convert-to-E.164(From)) As long as the receiver can perform the same operation and get the same res= ult, this works. For the reasons now repeated several times, receivers do s= eem to be able to make sense of inter-provider From information, as they us= e it mechanically for a variety of purposes. I just don't see the real problem - if From (and their SS7 kin) didn't work= , callerID would fail altogether. It obviously doesn't, for almost all call= s. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Mic= hael Hammer Sent: Wednesday, July 03, 2013 11:22 AM To: br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Then that tells me From is the wrong answer. Mike -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, July 03, 2013 11:19 AM To: Michael Hammer Cc: timothy.dwight@verizon.com; stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Sure, but you get that the To has to go through rewrite to get it routed, b= ut the From doesn't. It's all well and good to wave your hands and say "all SIP UAs must put ful= l e.164s in From" but it doesn't happen, and it's not going to happen. Today, rewrites of From happen, but not always to e.164s. We're either goi= ng to have to have those rewrites occur always to an e.164, include a full = e.164 in a new header, or use P-A-I and require it be a full e.164 (or a co= mbination). Brian On Jul 3, 2013, at 11:13 AM, Michael Hammer wrote: > All, >=20 > It helps to read E.164. > It is a string of digits, max 15, no other characters, with CC, NDC,=20 > and SN. > (There are variations on the names for those parts, but the concept is=20 > the > same.) > If you provide a specification that unambiguously delimits that, you=20 > are golden. >=20 > Do not inject confusion by introducing dialing sting prefixes. > Do not inject confusion by introducing trunking indicators. > Do not inject confusion by introducing methods to group digits. >=20 > If you want the phone number to get anywhere globally, you need to=20 > know how to generate the E.164. > Any domain worth its salt knows how to go from a local representation=20 > to a canonical one. > (And there are local representation secret sauce folks who know how to=20 > do > that.) >=20 > Mike >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 > Of Brian Rosen > Sent: Wednesday, July 03, 2013 10:55 AM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org; dcrocker@bbiw.net > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for > STIR) >=20 > The From problem is lack of country codes, and maybe worse. Consider=20 > these possible From: contents > 5551212 > 2025551212 > 12025551212 > +12025551212 > and of course all the variations with parens, spaces, hyphens, commas,=20 > periods, etc. >=20 > Although the first is getting really rare, I think it still happens >=20 > The problem with these is when they appear in From on an international=20 > call > - the first 2 are the real problems. They would have to be rewritten. >=20 > With To:, you get the variations with dial 9/8/... in enterprise=20 > systems, and the 011 style prefix >=20 > Brian >=20 >=20 >=20 > On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" > wrote: >=20 >> Could someone provide a few examples? I have to say I find this=20 >> thread > hard to follow. I trust the individuals making the arguments to be=20 > knowledgeable and honest, but personally I have little experience with=20 > this "FROM header manipulation" that I'm told is so rampant. >>=20 >> The only example I can think of is the "SIP trunking" use case I=20 >> raised > previously (user part of URI in FROM and/or TO header may be=20 > significant only within the dial plan of the associated Enterprise)=20 > which was ruled out of scope for this activity. So I'm puzzled, what=20 > use cases there are that > (a) are in scope for this exercise, and (b) involve manipulation of=20 > the user part of the URI in the FROM header. >>=20 >> Apologies in advance if this is obvious to everyone else and I'm the=20 >> only > one who doesn't "get it". >>=20 >> Thanks, >>=20 >> Tim >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of > Brian Rosen >> Sent: Wednesday, July 03, 2013 9:23 AM >> To: dcrocker@bbiw.net >> Cc: stir@ietf.org >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for >> STIR) >>=20 >> There are a lot of local variations out there, but they all have the > property that in order to route them, you need to be able to figure=20 > out at least the "left" part of the e.164 is, and the right part has=20 > to pass unscathed in order to work. Since everyone, and I mean=20 > everyone, dealing with these systems knows what e.164s are, and how=20 > they work, I don't think it's necessary, or even possible to describe=20 > all of the various ways the strings might appear and what to do with them= . >>=20 >> All we need say is that in order to work, the header contents has to=20 >> be > able to have the canonical e.164 extracted with no knowledge at the=20 > validator, and validations can occur anywhere in the call path. We'll=20 > dress up that text a lot I am sure, but the notion that we could=20 > write, or need a document describing all possible variations of how=20 > telephone numbers may appear and how to extract the e.164 in each of=20 > them seems to me to be silly. >>=20 >> It may be possible to specify an algorithm however. >>=20 >> Brian >>=20 >> On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >>=20 >>> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>>> Catching up (I was out for a week) >>>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>>=20 >>>>> The experience with canonicalization algorithms for DKIM -- and=20 >>>>> it, > too, had to deal with in-transit modifications -- makes clear that=20 > it's a topic with challenges and compromises. (Hmmm. "compromises" > might be a pun, here.) >>>> e.164s are much more constrained than the email address issues DKIM=20 >>>> has > to deal with. We could have challenges with local dial plans, and=20 > we've been discussing those issues, but the easy way out on those is=20 > that they may not be covered if both ends don't understand the dial=20 > plan the same way. >>>>=20 >>>> So far, while we have one issue I'm concerned with (verifier not=20 >>>> being > able to extract a canonical e.164 from the content of "From"), I don't=20 > think the DKIM experience is particularly relevant. >>>=20 >>>=20 >>> Brian, >>>=20 >>> Thanks. Good to hear. >>>=20 >>> I assume there is a document that specifies all of the variations=20 >>> that > will be encountered and how to deterministically and successfully=20 > transform them into the single, canonical representation? >>>=20 >>> Absent that, this topic remains a likely source of non-interoperability= . >>>=20 >>> d/ >>>=20 >>>=20 >>> -- >>> Dave Crocker >>> Brandenburg InternetWorking >>> bbiw.net >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing 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 fluffy@cisco.com Wed Jul 3 13:42: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 061D211E8224 for ; Wed, 3 Jul 2013 13:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 oXtqO4DFnQ0b for ; Wed, 3 Jul 2013 13:42:43 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2D17211E80E7 for ; Wed, 3 Jul 2013 13:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9947; q=dns/txt; s=iport; t=1372884163; x=1374093763; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Rn7/bnpXeUDBoNval2E52bSsnr7hvb74Vy+5RgDNrRk=; b=Duk4CrVsfKLVZpHvjwZYsNExtSdRCeAhuiU1ff6lNj2K9SIoM2GXf4to favXgfqTRNm0KrYleX2Vj+DpIJcZhoXqpnowvVwYVUDbfiTuSekok/IHW cQn7hTnWy6NVz9gtyDtFv9TQ1lM3/aXk3ZS3sKgwYNJWQmf2PUeu6gn1X o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAMSL1FGtJV2d/2dsb2JhbABRCYMJMknAOIEIFnSCIwEBAQMBAQEBNzQLBQcEAgEIDgMEAQEBChQJBycLFAkIAgQOBQiHdQMJBgyrDY8NjQCBKQeBCAIGKwcCBIJ+aQOTd4R7kByDEYFqBxcGGg X-IronPort-AV: E=Sophos;i="4.87,990,1363132800"; d="scan'208";a="230710814" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 03 Jul 2013 20:42:39 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r63KgcNf012963 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Jul 2013 20:42:39 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Wed, 3 Jul 2013 15:42:38 -0500 From: "Cullen Jennings (fluffy)" To: Brian Rosen Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qWltYnZvv95kaD94jU8Kryd5lLmgGAgAArYQCAAAM+gIAAC30AgABB8ACABz9zAIAABZQAgAADigCAAAR8gIAABGkAgAAFRQCAAAFtAIAAAQeAgAAEP4CAAAHDgIAAU3KA Date: Wed, 3 Jul 2013 20:42:38 +0000 Message-ID: References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.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.21.147.38] Content-Type: text/plain; charset="us-ascii" Content-ID: <46E27DB92E66814CAC463B33DB7236BA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dcrocker@bbiw.net" , "stir@ietf.org" , Michael Hammer , "timothy.dwight@verizon.com" , Henning Schulzrinne 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: Wed, 03 Jul 2013 20:42:48 -0000 Lets have the side that would know how to fix the number either fix it or r= eject it until so it can be globally understandable by the algorithm Henni= ng proposed below. Clearly systems are willing to make the SIP request URI = globally routable, I think they need to make the From be sort of globally u= nderstandable too. From the stats I can see, most calls already do have re= asonable formatted caller id (ignoring the issue of it it is spoofed or not= ). If someone sets their PSTN phone number in caller ID to "quack like a du= ck" there is nothing we can do to help that regardless of if it is a From h= eader or some other place.=20 On Jul 3, 2013, at 8:43 AM, Brian Rosen wrote: > Here is an example of where I think we have a problem: >=20 > From: 2025551212 >=20 > To: +44 800 505555 >=20 > Any entity on the origination side, including an SS7 GW, would know that = the e.164 for From is +12025551212 >=20 > The problem is if the call arrives as all SIP, the UK phone or SP won't k= now that. >=20 > Brian >=20 > On Jul 3, 2013, at 11:37 AM, Henning Schulzrinne wrote: >=20 >> We're retreading the same territory, but I don't think anybody is talkin= g about rewriting From. The process is >>=20 >> Identity =3D Hash-and-sign(convert-to-E.164(From)) >>=20 >> As long as the receiver can perform the same operation and get the same = result, this works. For the reasons now repeated several times, receivers d= o seem to be able to make sense of inter-provider From information, as they= use it mechanically for a variety of purposes. >>=20 >> I just don't see the real problem - if From (and their SS7 kin) didn't w= ork, callerID would fail altogether. It obviously doesn't, for almost all c= alls. >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Michael Hammer >> Sent: Wednesday, July 03, 2013 11:22 AM >> To: br@brianrosen.net >> Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STI= R) >>=20 >> Then that tells me From is the wrong answer. >>=20 >> Mike >>=20 >>=20 >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Wednesday, July 03, 2013 11:19 AM >> To: Michael Hammer >> Cc: timothy.dwight@verizon.com; stir@ietf.org; dcrocker@bbiw.net >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STI= R) >>=20 >> Sure, but you get that the To has to go through rewrite to get it routed= , but the From doesn't. >>=20 >> It's all well and good to wave your hands and say "all SIP UAs must put = full e.164s in From" but it doesn't happen, and it's not going to happen. >>=20 >> Today, rewrites of From happen, but not always to e.164s. We're either = going to have to have those rewrites occur always to an e.164, include a fu= ll e.164 in a new header, or use P-A-I and require it be a full e.164 (or a= combination). >>=20 >> Brian >>=20 >> On Jul 3, 2013, at 11:13 AM, Michael Hammer >> wrote: >>=20 >>> All, >>>=20 >>> It helps to read E.164. >>> It is a string of digits, max 15, no other characters, with CC, NDC,=20 >>> and >> SN. >>> (There are variations on the names for those parts, but the concept is= =20 >>> the >>> same.) >>> If you provide a specification that unambiguously delimits that, you=20 >>> are golden. >>>=20 >>> Do not inject confusion by introducing dialing sting prefixes. >>> Do not inject confusion by introducing trunking indicators. >>> Do not inject confusion by introducing methods to group digits. >>>=20 >>> If you want the phone number to get anywhere globally, you need to=20 >>> know how to generate the E.164. >>> Any domain worth its salt knows how to go from a local representation=20 >>> to a canonical one. >>> (And there are local representation secret sauce folks who know how to= =20 >>> do >>> that.) >>>=20 >>> Mike >>>=20 >>>=20 >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >>> Of Brian Rosen >>> Sent: Wednesday, July 03, 2013 10:55 AM >>> To: Dwight, Timothy M (Tim) >>> Cc: stir@ietf.org; dcrocker@bbiw.net >>> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for >>> STIR) >>>=20 >>> The From problem is lack of country codes, and maybe worse. Consider=20 >>> these possible From: contents >>> 5551212 >>> 2025551212 >>> 12025551212 >>> +12025551212 >>> and of course all the variations with parens, spaces, hyphens, commas,= =20 >>> periods, etc. >>>=20 >>> Although the first is getting really rare, I think it still happens >>>=20 >>> The problem with these is when they appear in From on an international= =20 >>> call >>> - the first 2 are the real problems. They would have to be rewritten. >>>=20 >>> With To:, you get the variations with dial 9/8/... in enterprise=20 >>> systems, and the 011 style prefix >>>=20 >>> Brian >>>=20 >>>=20 >>>=20 >>> On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" >>> wrote: >>>=20 >>>> Could someone provide a few examples? I have to say I find this=20 >>>> thread >>> hard to follow. I trust the individuals making the arguments to be=20 >>> knowledgeable and honest, but personally I have little experience with= =20 >>> this "FROM header manipulation" that I'm told is so rampant. >>>>=20 >>>> The only example I can think of is the "SIP trunking" use case I=20 >>>> raised >>> previously (user part of URI in FROM and/or TO header may be=20 >>> significant only within the dial plan of the associated Enterprise)=20 >>> which was ruled out of scope for this activity. So I'm puzzled, what=20 >>> use cases there are that >>> (a) are in scope for this exercise, and (b) involve manipulation of=20 >>> the user part of the URI in the FROM header. >>>>=20 >>>> Apologies in advance if this is obvious to everyone else and I'm the=20 >>>> only >>> one who doesn't "get it". >>>>=20 >>>> Thanks, >>>>=20 >>>> Tim >>>>=20 >>>> -----Original Message----- >>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >>>> Of >>> Brian Rosen >>>> Sent: Wednesday, July 03, 2013 9:23 AM >>>> To: dcrocker@bbiw.net >>>> Cc: stir@ietf.org >>>> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for >>>> STIR) >>>>=20 >>>> There are a lot of local variations out there, but they all have the >>> property that in order to route them, you need to be able to figure=20 >>> out at least the "left" part of the e.164 is, and the right part has=20 >>> to pass unscathed in order to work. Since everyone, and I mean=20 >>> everyone, dealing with these systems knows what e.164s are, and how=20 >>> they work, I don't think it's necessary, or even possible to describe=20 >>> all of the various ways the strings might appear and what to do with th= em. >>>>=20 >>>> All we need say is that in order to work, the header contents has to=20 >>>> be >>> able to have the canonical e.164 extracted with no knowledge at the=20 >>> validator, and validations can occur anywhere in the call path. We'll= =20 >>> dress up that text a lot I am sure, but the notion that we could=20 >>> write, or need a document describing all possible variations of how=20 >>> telephone numbers may appear and how to extract the e.164 in each of=20 >>> them >> seems to me to be silly. >>>>=20 >>>> It may be possible to specify an algorithm however. >>>>=20 >>>> Brian >>>>=20 >>>> On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >>>>=20 >>>>> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>>>>> Catching up (I was out for a week) >>>>>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>>>>=20 >>>>>>> The experience with canonicalization algorithms for DKIM -- and=20 >>>>>>> it, >>> too, had to deal with in-transit modifications -- makes clear that=20 >>> it's a topic with challenges and compromises. (Hmmm. "compromises" >>> might be a pun, here.) >>>>>> e.164s are much more constrained than the email address issues DKIM= =20 >>>>>> has >>> to deal with. We could have challenges with local dial plans, and=20 >>> we've been discussing those issues, but the easy way out on those is=20 >>> that they may not be covered if both ends don't understand the dial=20 >>> plan >> the same way. >>>>>>=20 >>>>>> So far, while we have one issue I'm concerned with (verifier not=20 >>>>>> being >>> able to extract a canonical e.164 from the content of "From"), I don't= =20 >>> think the DKIM experience is particularly relevant. >>>>>=20 >>>>>=20 >>>>> Brian, >>>>>=20 >>>>> Thanks. Good to hear. >>>>>=20 >>>>> I assume there is a document that specifies all of the variations=20 >>>>> that >>> will be encountered and how to deterministically and successfully=20 >>> transform them into the single, canonical representation? >>>>>=20 >>>>> Absent that, this topic remains a likely source of non-interoperabili= ty. >>>>>=20 >>>>> d/ >>>>>=20 >>>>>=20 >>>>> -- >>>>> Dave Crocker >>>>> Brandenburg InternetWorking >>>>> bbiw.net >>>>=20 >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>> _______________________________________________ >>> 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 timothy.dwight@verizon.com Wed Jul 3 13:45: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 CAEF321F9983 for ; Wed, 3 Jul 2013 13:45: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=[AWL=0.000, 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 9ZlF+eqdBmus for ; Wed, 3 Jul 2013 13:45:30 -0700 (PDT) Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) by ietfa.amsl.com (Postfix) with ESMTP id 8644121F9B8B for ; Wed, 3 Jul 2013 13:45:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by omzsmtpe02.verizonbusiness.com with ESMTP; 03 Jul 2013 20:45:24 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.87,990,1363132800"; d="scan'208";a="502479227" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi03.verizon.com with ESMTP; 03 Jul 2013 20:45:17 +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, 3 Jul 2013 16:45:17 -0400 To: Henning Schulzrinne Date: Wed, 3 Jul 2013 16:45:15 -0400 Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qfju36ah9Ux0e2HxhSF1PQN5lLiToAgAArZACAAAM/gIAAC30AgABB8ACABz9yAIAABZQAgAADigCAAAR8gIAABGkAgAAFRQCAAAFtAIAAAQiA//+/2HCAAAx98IAAHdIwgABHcICAABnpgP//xY/QgAAEkdA= Message-ID: <2B0F677F0B95454297753F58D4A07FA3012801EFA4@FHDP1LUMXC7V31.us.one.verizon.com> References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> <2B0F677F0B95454297753F58D4A07FA3012801ED45@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC1126B@EX2K10MB1.corp.yaanatech.com> <2B0F677F0B95454297753F58D4A07FA3012801EF30@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] 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: Wed, 03 Jul 2013 20:45:35 -0000 Yes, toll free numbers 'belong to' responsible organizations (RespOrg's). = It is the routing of the calls that can be allocated across multiple carrie= rs, not the ownership of the number. My mistake. I agree also that in thi= s case the carrier(s) would not be in the certificate chain. tim -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Wednesday, July 03, 2013 3:28 PM To: Dwight, Timothy M (Tim) Cc: stir@ietf.org Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) My understanding is that 800 numbers are assigned by SMS/800 via RespOrgs. = They might handle the certificates. (Each 800# is, as far as I know, only a= t one RespOrg at a time.) This would only apply to outbound calls that show= that 800 number, which probably doesn't include Joe's Fish Market. If Unit= ed Airlines uses multiple outbound call centers, they can use the same Resp= Org-issued certificate to sign their outbound calls. (We can discuss variou= s delegation mechanisms, with SMS/800 as the root, but that's getting into = irrelevant operational details.) -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] Sent: Wednesday, July 03, 2013 3:53 PM To: Michael Hammer; Henning Schulzrinne Cc: stir@ietf.org Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) I'm not sure if you're serious, but calls "from" an 800 number aren't neces= sarily invalid. Call center phones may be set up that way, for example, be= cause they don't want their agents taking incoming calls directly. Messes = up their call distribution algorithms :-). If you get a harassing call from such a number, call your carrier. They ca= n track down who owns the 800 number. If it's spoofed, of course, you'll g= et the same [lack of] satisfaction you get when you complain about any call= from a spoofed number. Toll free numbers do present us with an interesting tangent in the certific= ate chain though... particularly since their 'ownership' can be split acros= s multiple entities and change quite rapidly. For example if I'm Joe's Fis= h Market I may get an 800 number 1-800-eat-fish and have it set up so that = AT&T handles half the calls and Verizon handles the other half. I can spli= t the calls by day of week, time of day, or even every-other-call. I wonde= r if this challenges any assumptions people are making, e.g., about the len= gth of time that a certificate would be valid. If Verizon only has the rig= ht to assert that number when it's Verizon's "turn", does that mean that th= e certificate ceases to be valid the next time anybody calls that 800 numbe= r? If so the cert may not be valid by the time the verifier wants to use i= t... Tim -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Wednesday, July 03, 2013 1:20 PM To: Henning.Schulzrinne@fcc.gov; Dwight, Timothy M (Tim) Cc: stir@ietf.org Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Ummm.... who do I call to complain about calls from 800 numbers? :) Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hen= ning Schulzrinne Sent: Wednesday, July 03, 2013 2:08 PM To: 'Dwight, Timothy M (Tim)' Cc: stir@ietf.org Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) If they don't, both numeric and textual callerID won't work at all, most l= ikely (or will show random garbage). Large companies presumably want their = calls to show usable callerID, so that people pick up the calls. (And indiv= iduals and small businesses will complain to the state PUC or the FCC.) I s= uspect that if United Airlines calls up their carrier and complains about m= angled callerIDs, somebody at that carrier will try to get this fixed - at = least at your company... -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] Sent: Wednesday, July 03, 2013 12:53 PM To: Henning Schulzrinne; 'Michael Hammer'; br@brianrosen.net Cc: stir@ietf.org; dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Ah, so I wasn't as confused as I thought. Good to know. We are talking ab= out being able to translate the value in the FROM header to an Internationa= l E.164 number, on the terminating side of the call. Not over-write the va= lue in the message, but the 'convert-to-E.164' function has to return the s= ame value on the terminating side as it did on the originating side. So I'm back to my previous position - this is indeed possible, assuming eno= ugh contextual information is present. Which in general it must be since a= s Hadriel repeatedly assures us, this all (usually) works today. =20 The nature of the contextual information is different in SIP though. If pe= ople are going to signal FROM headers with national significant numbers in = the user part, they (or something in the path on the originating leg) had b= etter be religious about appending the phone-context parameter, so that on = the terminating leg it's possible to know what they meant. tim=20 -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 03, 2013 10:38 AM To: 'Michael Hammer'; br@brianrosen.net Cc: stir@ietf.org; Dwight, Timothy M (Tim); dcrocker@bbiw.net Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR) We're retreading the same territory, but I don't think anybody is talking a= bout rewriting From. The process is Identity =3D Hash-and-sign(convert-to-E.164(From)) As long as the receiver can perform the same operation and get the same res= ult, this works. For the reasons now repeated several times, receivers do s= eem to be able to make sense of inter-provider From information, as they us= e it mechanically for a variety of purposes. I just don't see the real problem - if From (and their SS7 kin) didn't work= , callerID would fail altogether. It obviously doesn't, for almost all call= s. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Mic= hael Hammer Sent: Wednesday, July 03, 2013 11:22 AM To: br@brianrosen.net Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Then that tells me From is the wrong answer. Mike -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, July 03, 2013 11:19 AM To: Michael Hammer Cc: timothy.dwight@verizon.com; stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Sure, but you get that the To has to go through rewrite to get it routed, b= ut the From doesn't. It's all well and good to wave your hands and say "all SIP UAs must put ful= l e.164s in From" but it doesn't happen, and it's not going to happen. Today, rewrites of From happen, but not always to e.164s. We're either goi= ng to have to have those rewrites occur always to an e.164, include a full = e.164 in a new header, or use P-A-I and require it be a full e.164 (or a co= mbination). Brian On Jul 3, 2013, at 11:13 AM, Michael Hammer wrote: > All, >=20 > It helps to read E.164. > It is a string of digits, max 15, no other characters, with CC, NDC,=20 > and SN. > (There are variations on the names for those parts, but the concept is=20 > the > same.) > If you provide a specification that unambiguously delimits that, you=20 > are golden. >=20 > Do not inject confusion by introducing dialing sting prefixes. > Do not inject confusion by introducing trunking indicators. > Do not inject confusion by introducing methods to group digits. >=20 > If you want the phone number to get anywhere globally, you need to=20 > know how to generate the E.164. > Any domain worth its salt knows how to go from a local representation=20 > to a canonical one. > (And there are local representation secret sauce folks who know how to=20 > do > that.) >=20 > Mike >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 > Of Brian Rosen > Sent: Wednesday, July 03, 2013 10:55 AM > To: Dwight, Timothy M (Tim) > Cc: stir@ietf.org; dcrocker@bbiw.net > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for > STIR) >=20 > The From problem is lack of country codes, and maybe worse. Consider=20 > these possible From: contents > 5551212 > 2025551212 > 12025551212 > +12025551212 > and of course all the variations with parens, spaces, hyphens, commas,=20 > periods, etc. >=20 > Although the first is getting really rare, I think it still happens >=20 > The problem with these is when they appear in From on an international=20 > call > - the first 2 are the real problems. They would have to be rewritten. >=20 > With To:, you get the variations with dial 9/8/... in enterprise=20 > systems, and the 011 style prefix >=20 > Brian >=20 >=20 >=20 > On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" > wrote: >=20 >> Could someone provide a few examples? I have to say I find this=20 >> thread > hard to follow. I trust the individuals making the arguments to be=20 > knowledgeable and honest, but personally I have little experience with=20 > this "FROM header manipulation" that I'm told is so rampant. >>=20 >> The only example I can think of is the "SIP trunking" use case I=20 >> raised > previously (user part of URI in FROM and/or TO header may be=20 > significant only within the dial plan of the associated Enterprise)=20 > which was ruled out of scope for this activity. So I'm puzzled, what=20 > use cases there are that > (a) are in scope for this exercise, and (b) involve manipulation of=20 > the user part of the URI in the FROM header. >>=20 >> Apologies in advance if this is obvious to everyone else and I'm the=20 >> only > one who doesn't "get it". >>=20 >> Thanks, >>=20 >> Tim >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of > Brian Rosen >> Sent: Wednesday, July 03, 2013 9:23 AM >> To: dcrocker@bbiw.net >> Cc: stir@ietf.org >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for >> STIR) >>=20 >> There are a lot of local variations out there, but they all have the > property that in order to route them, you need to be able to figure=20 > out at least the "left" part of the e.164 is, and the right part has=20 > to pass unscathed in order to work. Since everyone, and I mean=20 > everyone, dealing with these systems knows what e.164s are, and how=20 > they work, I don't think it's necessary, or even possible to describe=20 > all of the various ways the strings might appear and what to do with them= . >>=20 >> All we need say is that in order to work, the header contents has to=20 >> be > able to have the canonical e.164 extracted with no knowledge at the=20 > validator, and validations can occur anywhere in the call path. We'll=20 > dress up that text a lot I am sure, but the notion that we could=20 > write, or need a document describing all possible variations of how=20 > telephone numbers may appear and how to extract the e.164 in each of=20 > them seems to me to be silly. >>=20 >> It may be possible to specify an algorithm however. >>=20 >> Brian >>=20 >> On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >>=20 >>> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>>> Catching up (I was out for a week) >>>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>>=20 >>>>> The experience with canonicalization algorithms for DKIM -- and=20 >>>>> it, > too, had to deal with in-transit modifications -- makes clear that=20 > it's a topic with challenges and compromises. (Hmmm. "compromises" > might be a pun, here.) >>>> e.164s are much more constrained than the email address issues DKIM=20 >>>> has > to deal with. We could have challenges with local dial plans, and=20 > we've been discussing those issues, but the easy way out on those is=20 > that they may not be covered if both ends don't understand the dial=20 > plan the same way. >>>>=20 >>>> So far, while we have one issue I'm concerned with (verifier not=20 >>>> being > able to extract a canonical e.164 from the content of "From"), I don't=20 > think the DKIM experience is particularly relevant. >>>=20 >>>=20 >>> Brian, >>>=20 >>> Thanks. Good to hear. >>>=20 >>> I assume there is a document that specifies all of the variations=20 >>> that > will be encountered and how to deterministically and successfully=20 > transform them into the single, canonical representation? >>>=20 >>> Absent that, this topic remains a likely source of non-interoperability= . >>>=20 >>> d/ >>>=20 >>>=20 >>> -- >>> Dave Crocker >>> Brandenburg InternetWorking >>> bbiw.net >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing 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 Wed Jul 3 14:04: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 B71F421F8756 for ; Wed, 3 Jul 2013 14:04:15 -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 RMo9KAwZj09V for ; Wed, 3 Jul 2013 14:04:11 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 786A611E8247 for ; Wed, 3 Jul 2013 14:04:09 -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=7SKn2wleKUt6NW5rS8KWioFcm2xfBk4eZmLvilLjkR0=; b=T4CjMq6RZXwrOXjbrHgUlr3tmbRHm3jajRpCrovVn+swKTG4mo8g5ZJ5s7vVNySSEtpG0gv85zDWyRfUVZq19WN9jguGPquhzZQZpC7VPRlrxbApFZYIaHFhwTPf/l4iWugd1vwHip7IxJU0idSlIwAOevOuPlwxk+AvMkviKZU=; Received: from neustargw.va.neustar.com ([209.173.53.233]:46057 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UuUDf-0002Ee-El; Wed, 03 Jul 2013 17:04:07 -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: Wed, 3 Jul 2013 17:04:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.corp.yaanatech.com> To: Cullen Jennings (fluffy) 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: "dcrocker@bbiw.net" , "stir@ietf.org" , Michael Hammer , "timothy.dwight@verizon.com" , Henning Schulzrinne 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: Wed, 03 Jul 2013 21:04:16 -0000 I don't know if that is more likely to be able to be deployed any time = soon than any other solution, but I agree it's the most desirable. I've seen a lot of U.S. numbers in =46rom that did not have a country = code. Less common elsewhere I believe. Brian On Jul 3, 2013, at 4:42 PM, Cullen Jennings (fluffy) = wrote: >=20 > Lets have the side that would know how to fix the number either fix it = or reject it until so it can be globally understandable by the = algorithm Henning proposed below. Clearly systems are willing to make = the SIP request URI globally routable, I think they need to make the = =46rom be sort of globally understandable too. =46rom the stats I can = see, most calls already do have reasonable formatted caller id (ignoring = the issue of it it is spoofed or not). If someone sets their PSTN phone = number in caller ID to "quack like a duck" there is nothing we can do to = help that regardless of if it is a =46rom header or some other place.=20 >=20 >=20 > On Jul 3, 2013, at 8:43 AM, Brian Rosen wrote: >=20 >> Here is an example of where I think we have a problem: >>=20 >> From: 2025551212 >>=20 >> To: +44 800 505555 >>=20 >> Any entity on the origination side, including an SS7 GW, would know = that the e.164 for =46rom is +12025551212 >>=20 >> The problem is if the call arrives as all SIP, the UK phone or SP = won't know that. >>=20 >> Brian >>=20 >> On Jul 3, 2013, at 11:37 AM, Henning Schulzrinne = wrote: >>=20 >>> We're retreading the same territory, but I don't think anybody is = talking about rewriting From. The process is >>>=20 >>> Identity =3D Hash-and-sign(convert-to-E.164(From)) >>>=20 >>> As long as the receiver can perform the same operation and get the = same result, this works. For the reasons now repeated several times, = receivers do seem to be able to make sense of inter-provider =46rom = information, as they use it mechanically for a variety of purposes. >>>=20 >>> I just don't see the real problem - if =46rom (and their SS7 kin) = didn't work, callerID would fail altogether. It obviously doesn't, for = almost all calls. >>>=20 >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Michael Hammer >>> Sent: Wednesday, July 03, 2013 11:22 AM >>> To: br@brianrosen.net >>> Cc: stir@ietf.org; timothy.dwight@verizon.com; dcrocker@bbiw.net >>> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for = STIR) >>>=20 >>> Then that tells me =46rom is the wrong answer. >>>=20 >>> Mike >>>=20 >>>=20 >>> -----Original Message----- >>> From: Brian Rosen [mailto:br@brianrosen.net] >>> Sent: Wednesday, July 03, 2013 11:19 AM >>> To: Michael Hammer >>> Cc: timothy.dwight@verizon.com; stir@ietf.org; dcrocker@bbiw.net >>> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for = STIR) >>>=20 >>> Sure, but you get that the To has to go through rewrite to get it = routed, but the =46rom doesn't. >>>=20 >>> It's all well and good to wave your hands and say "all SIP UAs must = put full e.164s in From" but it doesn't happen, and it's not going to = happen. >>>=20 >>> Today, rewrites of =46rom happen, but not always to e.164s. We're = either going to have to have those rewrites occur always to an e.164, = include a full e.164 in a new header, or use P-A-I and require it be a = full e.164 (or a combination). >>>=20 >>> Brian >>>=20 >>> On Jul 3, 2013, at 11:13 AM, Michael Hammer = >>> wrote: >>>=20 >>>> All, >>>>=20 >>>> It helps to read E.164. >>>> It is a string of digits, max 15, no other characters, with CC, = NDC,=20 >>>> and >>> SN. >>>> (There are variations on the names for those parts, but the concept = is=20 >>>> the >>>> same.) >>>> If you provide a specification that unambiguously delimits that, = you=20 >>>> are golden. >>>>=20 >>>> Do not inject confusion by introducing dialing sting prefixes. >>>> Do not inject confusion by introducing trunking indicators. >>>> Do not inject confusion by introducing methods to group digits. >>>>=20 >>>> If you want the phone number to get anywhere globally, you need to=20= >>>> know how to generate the E.164. >>>> Any domain worth its salt knows how to go from a local = representation=20 >>>> to a canonical one. >>>> (And there are local representation secret sauce folks who know how = to=20 >>>> do >>>> that.) >>>>=20 >>>> Mike >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = Behalf=20 >>>> Of Brian Rosen >>>> Sent: Wednesday, July 03, 2013 10:55 AM >>>> To: Dwight, Timothy M (Tim) >>>> Cc: stir@ietf.org; dcrocker@bbiw.net >>>> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text = for >>>> STIR) >>>>=20 >>>> The =46rom problem is lack of country codes, and maybe worse. = Consider=20 >>>> these possible From: contents >>>> 5551212 >>>> 2025551212 >>>> 12025551212 >>>> +12025551212 >>>> and of course all the variations with parens, spaces, hyphens, = commas,=20 >>>> periods, etc. >>>>=20 >>>> Although the first is getting really rare, I think it still happens >>>>=20 >>>> The problem with these is when they appear in =46rom on an = international=20 >>>> call >>>> - the first 2 are the real problems. They would have to be = rewritten. >>>>=20 >>>> With To:, you get the variations with dial 9/8/... in enterprise=20 >>>> systems, and the 011 style prefix >>>>=20 >>>> Brian >>>>=20 >>>>=20 >>>>=20 >>>> On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" >>>> wrote: >>>>=20 >>>>> Could someone provide a few examples? I have to say I find this=20= >>>>> thread >>>> hard to follow. I trust the individuals making the arguments to be=20= >>>> knowledgeable and honest, but personally I have little experience = with=20 >>>> this "FROM header manipulation" that I'm told is so rampant. >>>>>=20 >>>>> The only example I can think of is the "SIP trunking" use case I=20= >>>>> raised >>>> previously (user part of URI in FROM and/or TO header may be=20 >>>> significant only within the dial plan of the associated Enterprise)=20= >>>> which was ruled out of scope for this activity. So I'm puzzled, = what=20 >>>> use cases there are that >>>> (a) are in scope for this exercise, and (b) involve manipulation of=20= >>>> the user part of the URI in the FROM header. >>>>>=20 >>>>> Apologies in advance if this is obvious to everyone else and I'm = the=20 >>>>> only >>>> one who doesn't "get it". >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Tim >>>>>=20 >>>>> -----Original Message----- >>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = Behalf=20 >>>>> Of >>>> Brian Rosen >>>>> Sent: Wednesday, July 03, 2013 9:23 AM >>>>> To: dcrocker@bbiw.net >>>>> Cc: stir@ietf.org >>>>> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text = for >>>>> STIR) >>>>>=20 >>>>> There are a lot of local variations out there, but they all have = the >>>> property that in order to route them, you need to be able to figure=20= >>>> out at least the "left" part of the e.164 is, and the right part = has=20 >>>> to pass unscathed in order to work. Since everyone, and I mean=20 >>>> everyone, dealing with these systems knows what e.164s are, and how=20= >>>> they work, I don't think it's necessary, or even possible to = describe=20 >>>> all of the various ways the strings might appear and what to do = with them. >>>>>=20 >>>>> All we need say is that in order to work, the header contents has = to=20 >>>>> be >>>> able to have the canonical e.164 extracted with no knowledge at the=20= >>>> validator, and validations can occur anywhere in the call path. = We'll=20 >>>> dress up that text a lot I am sure, but the notion that we could=20 >>>> write, or need a document describing all possible variations of how=20= >>>> telephone numbers may appear and how to extract the e.164 in each = of=20 >>>> them >>> seems to me to be silly. >>>>>=20 >>>>> It may be possible to specify an algorithm however. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Jul 3, 2013, at 10:10 AM, Dave Crocker = wrote: >>>>>=20 >>>>>> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>>>>>> Catching up (I was out for a week) >>>>>>> On Jun 28, 2013, at 7:09 PM, Dave Crocker = wrote: >>>>>>>=20 >>>>>>>> The experience with canonicalization algorithms for DKIM -- and=20= >>>>>>>> it, >>>> too, had to deal with in-transit modifications -- makes clear that=20= >>>> it's a topic with challenges and compromises. (Hmmm. = "compromises" >>>> might be a pun, here.) >>>>>>> e.164s are much more constrained than the email address issues = DKIM=20 >>>>>>> has >>>> to deal with. We could have challenges with local dial plans, and=20= >>>> we've been discussing those issues, but the easy way out on those = is=20 >>>> that they may not be covered if both ends don't understand the dial=20= >>>> plan >>> the same way. >>>>>>>=20 >>>>>>> So far, while we have one issue I'm concerned with (verifier not=20= >>>>>>> being >>>> able to extract a canonical e.164 from the content of "From"), I = don't=20 >>>> think the DKIM experience is particularly relevant. >>>>>>=20 >>>>>>=20 >>>>>> Brian, >>>>>>=20 >>>>>> Thanks. Good to hear. >>>>>>=20 >>>>>> I assume there is a document that specifies all of the variations=20= >>>>>> that >>>> will be encountered and how to deterministically and successfully=20= >>>> transform them into the single, canonical representation? >>>>>>=20 >>>>>> Absent that, this topic remains a likely source of = non-interoperability. >>>>>>=20 >>>>>> d/ >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> Dave Crocker >>>>>> Brandenburg InternetWorking >>>>>> bbiw.net >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>=20 >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >>>> _______________________________________________ >>>> 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 fluffy@cisco.com Wed Jul 3 14:12: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 9CB2711E8254 for ; Wed, 3 Jul 2013 14:12:05 -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 3clQFkOxgXA1 for ; Wed, 3 Jul 2013 14:11:58 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 74F8B11E8233 for ; Wed, 3 Jul 2013 14:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3301; q=dns/txt; s=iport; t=1372885918; x=1374095518; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=rrBQrKlte5oRixa/hfe8CHnq9uZvpROJnEMh5hvZ7BY=; b=IadhRU+qFWD5iiXVeulu80BdRDydbWi+8hX2+sGAck2rUG+nTrwM+jG8 WITT+tecaAotCaAAC+f+iUqhsEzU/zb+zy7p3A5VJJmoqghfv8eXZZsSg wCkwysKWibili/q6WnFNn6U38vL/JwsoO+o5oC2pZGheR5xJLhCj26Fn0 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAFADqT1FGtJXHB/2dsb2JhbABagwl7wDiBCRZ0giMBAQEDAWciAgEIGAokMiUCBBMIiAEGqxiPC45GcgIGMoMEaQOpDoMRgWo+ X-IronPort-AV: E=Sophos;i="4.87,990,1363132800"; d="scan'208";a="230734787" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 03 Jul 2013 21:11:58 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r63LBuqp008038 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 3 Jul 2013 21:11: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; Wed, 3 Jul 2013 16:11:56 -0500 From: "Cullen Jennings (fluffy)" To: "stir@ietf.org" Thread-Topic: [stir] Out of band Thread-Index: AQHOdE7ffZ5Xbw7SLk6bvvvHo6hNJZlTzxYA Date: Wed, 3 Jul 2013 21:11: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: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.147.38] Content-Type: text/plain; charset="Windows-1252" Content-ID: <586263E0A4464E4FBB8A5056E670D280@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 03 Jul 2013 21:12:05 -0000 On Jun 28, 2013, at 3:28 PM, Cullen Jennings (fluffy) wr= ote: >=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 I got asked to be a bit more specific on this =85. let me give two example= s.=20 Take a situation were a US based servicer provider A perhaps contracts out = the voice termination to Europe and Africa to larger international carrier = B. Now B may not actually terminate traffic in some specific country in Afr= ica but instead uses service provider C. The type of requirements I have se= en from the "B" company for SBCs include that their SBC can strip out a mes= sages that C put in to SIP to say "hey this is actually being terminated at= carrier C for 0.01 cents / minute and if you want to cut out the middle ma= n please give us a call and SIP trunk to us directly"=20 Now I have always been a bit skeptical that carrier A could not manage to f= ind out that carrier C existed but none the less, this does seem to be a re= quirements from some folks. In the second example, imagine you have an vendor of mobile phone handsets = that would like to deliver SMS like messages for free to handsets using a c= arriers 3G network and not paying for it. They come up with the brilliant i= dea to send an INVITE to the handset that includes the header like "X-IOS-S= MS: Here is the message" and have the handset look for this and if the head= er is there, then the handset does not ring but instead just displays the m= essage "Here is the message".=20 Clearly something needs to block these type "bit smuggling" in the signalin= g. This is a requirement that comes up to SBC that a SP might use to police= traffic that was coming from an enterprise user into the SP network.=20 It has always seemed to me that someone that was really determined might fi= nd a way to smuggle the bits but none the less the requirements exist to no= t allow stuff like this. I'm sure the SBCs can be configured many different= ways but many do have the capability to be configured like this.=20 It's hard for me to test what data actually makes it from one SP to another= but it's not that hard to test what makes it End to End for specific paths= . Some tests of that of that would suggest, as a vague generalization, that= much stuff in SIP that is not understood by the SBCs does not survive end = to end.=20 On related note, if we defined a new header and carriers wanted that header= to make it thought there network, I think for many cases they could probab= ly do that only by changing configuration of equipment. I realize that even= a configuration change is a big deal but it's a smaller deal that software= upgrades.=20 =20 From fluffy@cisco.com Wed Jul 3 15:04: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 AF34621F9D00 for ; Wed, 3 Jul 2013 15:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.535 X-Spam-Level: X-Spam-Status: No, score=-110.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 rhupH-7Eh-pT for ; Wed, 3 Jul 2013 15:03:56 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 22B1E11E80F6 for ; Wed, 3 Jul 2013 15:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=460; q=dns/txt; s=iport; t=1372889036; x=1374098636; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=s8Rk0QlXHp77qZ27CFIHPR1xIaUxShXPJQsVDGFFUuI=; b=Rplx9rtvvt9fa1d/pcWRMCO3vnGz3vBbONcFuwdBCJ5Q/bP0k49lafCE XGao8+6eBh/ktihqtUuIMpP424Qzv8pA3jds971eTuR9uMegaeEIY6nb7 kIW3XSEWxa69P6onoKed89Aq8xVp4+PZNIgJd/KHd9O9wq+v13HxWYuFy o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4FAP+e1FGtJXG8/2dsb2JhbABagwl7gkG9eIEJFnSCIwEBAQMBOj8FCwIBCA4UFBAyJQIEDgUIiAEGqyOPEY84AjEHgwRpA6kOgxGCKA X-IronPort-AV: E=Sophos;i="4.87,991,1363132800"; d="scan'208";a="230744460" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 03 Jul 2013 22:03:55 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r63M3tR7026716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Jul 2013 22:03:55 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Wed, 3 Jul 2013 17:03:55 -0500 From: "Cullen Jennings (fluffy)" To: Brian Rosen Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qWltYnZvv95kaD94jU8Kryd5lLmgGAgAArYQCAAAM+gIAAC30AgABB8ACABz9zAIAABZQAgAADigCAAAR8gIAABGkAgAAFRQCAAAFtAIAAAQeAgAAEP4CAAAHDgIAAU3KAgAAGAICAABC2AA== Date: Wed, 3 Jul 2013 22:03:54 +0000 Message-ID: References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC10EE3@EX2K10MB1.corp.yaanatech.com> <1499C170-3693-46B7-ADDB-9556165304B8@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC10F87@EX2K10MB1.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.21.147.38] Content-Type: text/plain; charset="us-ascii" Content-ID: <078B3887C322644B89A8B9E6B45BCCEF@emea.cisco.com> 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: Wed, 03 Jul 2013 22:04:01 -0000 On Jul 3, 2013, at 2:04 PM, Brian Rosen wrote: > I've seen a lot of U.S. numbers in From that did not have a country code.= Less common elsewhere I believe. yah, I agree - as sad as this is to say, the pragmatic thing to do is, if i= t 10 digit number with no country code and does not start in 0, assume it i= s +1 country code. I realize there are cases this fails but it works often = enough there are people doing it.=20 From hadriel.kaplan@oracle.com Wed Jul 3 15:12: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 BFB4311E80F6 for ; Wed, 3 Jul 2013 15:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.504 X-Spam-Level: X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCzBL2R35dsB for ; Wed, 3 Jul 2013 15:12:32 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0E511E80E2 for ; Wed, 3 Jul 2013 15:12:32 -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 r63M6ANK018039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Jul 2013 22:06:11 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 r63MCTfI009304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jul 2013 22:12:30 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 r63MCTJ4029493; Wed, 3 Jul 2013 22:12:29 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Jul 2013 15:12:29 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Wed, 3 Jul 2013 18:12:27 -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: 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: Wed, 03 Jul 2013 22:12:37 -0000 I'd argue that actually the number one reason SBCs remove things is to = make calls work - because systems other than SBCs can't seem to handle = unknown headers. But yes the number two reason is for security-related = purposes. In my experience, though, while SBC's have had a = whitelist-model for removing all unknown headers for years, it's not = nearly as popular/commonly-used as the blacklist model of only removing = specific headers. What I find most ironic about your statement is that while at least = SBC's can be configured to pass/drop headers, most of the *other* B2BUAs = in the call path don't pass along unknown headers at all, and can't even = be configured to do so. They've been getting better - at least some = B2BUAs can now be configured with what headers to pass through - but = that's a relatively new feature for B2BUAs afaict, while it's been = available to every SBC I've ever seen for over a decade. I think many people in the IETF tend to be from Enterprise-side PBX = vendors, for which they consider themselves the "end" for end-to-end = SIP, and then think the carriers they connect to are just SBCs getting = in their way of end-end SIP. Meanwhile the carriers all have the = logical equivalent of PBXs inside their networks, and think the same of = transit carriers getting in their way of end-end SIP. And of course the = transits also have the logical equivalent of PBXs inside their networks. = I find the debates in the IETF about end-end SIP transparency quite = humorous, when everyone considers themselves to be the "end". :) -hadriel On Jul 3, 2013, at 5:11 PM, Cullen Jennings (fluffy) = wrote: >=20 > On Jun 28, 2013, at 3:28 PM, Cullen Jennings (fluffy) = wrote: >=20 >>=20 >> 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. >>=20 >>=20 >=20 > I got asked to be a bit more specific on this =85. let me give two = examples.=20 >=20 > Take a situation were a US based servicer provider A perhaps contracts = out the voice termination to Europe and Africa to larger international = carrier B. Now B may not actually terminate traffic in some specific = country in Africa but instead uses service provider C. The type of = requirements I have seen from the "B" company for SBCs include that = their SBC can strip out a messages that C put in to SIP to say "hey this = is actually being terminated at carrier C for 0.01 cents / minute and if = you want to cut out the middle man please give us a call and SIP trunk = to us directly"=20 >=20 > Now I have always been a bit skeptical that carrier A could not manage = to find out that carrier C existed but none the less, this does seem to = be a requirements from some folks. >=20 >=20 > In the second example, imagine you have an vendor of mobile phone = handsets that would like to deliver SMS like messages for free to = handsets using a carriers 3G network and not paying for it. They come up = with the brilliant idea to send an INVITE to the handset that includes = the header like "X-IOS-SMS: Here is the message" and have the handset = look for this and if the header is there, then the handset does not ring = but instead just displays the message "Here is the message".=20 >=20 > Clearly something needs to block these type "bit smuggling" in the = signaling. This is a requirement that comes up to SBC that a SP might = use to police traffic that was coming from an enterprise user into the = SP network.=20 >=20 > It has always seemed to me that someone that was really determined = might find a way to smuggle the bits but none the less the requirements = exist to not allow stuff like this. I'm sure the SBCs can be configured = many different ways but many do have the capability to be configured = like this.=20 >=20 > It's hard for me to test what data actually makes it from one SP to = another but it's not that hard to test what makes it End to End for = specific paths. Some tests of that of that would suggest, as a vague = generalization, that much stuff in SIP that is not understood by the = SBCs does not survive end to end.=20 >=20 > On related note, if we defined a new header and carriers wanted that = header to make it thought there network, I think for many cases they = could probably do that only by changing configuration of equipment. I = realize that even a configuration change is a big deal but it's a = smaller deal that software upgrades.=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From dhc@dcrocker.net Wed Jul 3 16:24: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 DAAD611E80FF for ; Wed, 3 Jul 2013 16:24:06 -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 Dcdnj6hMOq-F for ; Wed, 3 Jul 2013 16:24:01 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E230111E8100 for ; Wed, 3 Jul 2013 16:24:01 -0700 (PDT) Received: from [192.168.19.2] (mbe0536d0.tmodns.net [208.54.5.190]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r63NNorK004905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Jul 2013 16:23:57 -0700 Message-ID: <51D4B1B7.1060509@dcrocker.net> Date: Wed, 03 Jul 2013 16:20:23 -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: <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: 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]); Wed, 03 Jul 2013 16:24:01 -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, 03 Jul 2013 23:24:07 -0000 On 7/3/2013 3:12 PM, Hadriel Kaplan wrote: > I find the debates in the IETF about end-end SIP transparency quite humorous, when everyone considers themselves to be the "end".:) It was pretty obvious that email really /was/ end-to-end, until I started working with the EDI and fax communities that used email as a subordinate layer for transport, often with significant additional transferring, after email was done. The meta-lesson is that end-to-end can't be guaranteed. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Wed Jul 3 16:36: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 7075A21F9CA7 for ; Wed, 3 Jul 2013 16:36: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 R+TbNR7uURbO for ; Wed, 3 Jul 2013 16:36:53 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8201C21F9C85 for ; Wed, 3 Jul 2013 16:36:53 -0700 (PDT) Received: from [192.168.19.2] (mbe0536d0.tmodns.net [208.54.5.190]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r63Nalcq005168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Jul 2013 16:36:51 -0700 Message-ID: <51D4B4B4.9050404@dcrocker.net> Date: Wed, 03 Jul 2013 16:33:08 -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: <011501ce7676$79b756c0$6d260440$@shockey.us> <01bc01ce7691$e73f8bc0$b5bea340$@shockey.us> <51D1DC32.1080308@dcrocker.net> <520DE022-7E21-4B31-82E1-D332A2A94E63@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, 03 Jul 2013 16:36:51 -0700 (PDT) Cc: "'dcrocker@bbiw.net'" Subject: [stir] Follow the bouncing requirements (was - Re: 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, 03 Jul 2013 23:36:58 -0000 > For reasons mentioned earlier by others, I suspect that this would be > private DNS (or servers) regardless of the number visibility issue, > but that doesn't seem like something we need to prescribe. This is an example of a core issue that keeps prompting conflicting statements. What I heard early in discussion was that validation was to be possible by enterprises and SIP UAs. That requires a public external service for retrieving validation parameters. The larger point is that it really is important to establish a stable, small, clear set of basic functional requirements so that design discussions (and debates) can rely on them. And to anticipate one line of logic that also has shown up a number of times, whatever is done initially is what's likely to stay in place forever. Projections that something will be done one way at first and then somehow, later, be done differently, has little precedent on the Internet. (Marc Anthony got it right: the evil men do really does live after them.) So, for example, having the external query service be private initially means it will stay private. d/ ps. One issue that I've been unclear about is how the validated telephone number will get used. That is, the processing agent now has a validated number. So what? What can/will be done differently and why are we sure that it really will be? -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Wed Jul 3 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 8F7D121F9B9E for ; Wed, 3 Jul 2013 16:46: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 V2EMzr3sa+AP for ; Wed, 3 Jul 2013 16:45:48 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E020B21F8B21 for ; Wed, 3 Jul 2013 16:45:48 -0700 (PDT) Received: from [192.168.19.2] (mbe0536d0.tmodns.net [208.54.5.190]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r63NjhwK005446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 3 Jul 2013 16:45:47 -0700 Message-ID: <51D4B768.5090503@dcrocker.net> Date: Wed, 03 Jul 2013 16:44:40 -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: <011501ce7676$79b756c0$6d260440$@shockey.us> <01bc01ce7691$e73f8bc0$b5bea340$@shockey.us> <51D1DC32.1080308@dcrocker.net> <520DE022-7E21-4B31-82E1-D332A2A94E63@oracle.com> <2B0F677F0B95454297753F58D4A07FA30127F61718@FHDP1LUMXC7V31.us.one.verizon.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, 03 Jul 2013 16:45:48 -0700 (PDT) Subject: [stir] response-time window ( was Re: 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, 03 Jul 2013 23:46:07 -0000 On 7/2/2013 10:57 AM, Henning Schulzrinne wrote: > Vaguely related: On the government side, we make numerous entity-related items available to the public via HTTP APIs HTTP-based queries require a tcp open, at least one http exchange, and a tcp close. I never get the count right, but that's somewhere around 5-7 round-trip times. Since the current requirement is for queries from anywhere on the net to anywhere on the net, these aggregate round-trip latencies can be significant. Measured in seconds. My understanding is that verification needs to be performed within the final stages of call set up. I assume that's a window of less than a second, and presumably quite a bit less. One of the functional requirements that would be helpful to specify is the performance window that must be met by the validation mechanism. d/ ps. A facile response to response-time concerns is to invoke various optimizations such as caching connections, or the like. That's fine, except when it isn't, which is frequently. Designing for best-case scenarios is a tad fragile. -- Dave Crocker Brandenburg InternetWorking bbiw.net From richard@shockey.us Thu Jul 4 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 4DD7D11E812E for ; Thu, 4 Jul 2013 09:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.356 X-Spam-Level: X-Spam-Status: No, score=-101.356 tagged_above=-999 required=5 tests=[AWL=0.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 Ieb7VNwO7yJC for ; Thu, 4 Jul 2013 09:12:13 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 9FE9F21F9FD5 for ; Thu, 4 Jul 2013 09:12:13 -0700 (PDT) Received: (qmail 4081 invoked by uid 0); 4 Jul 2013 16:11:52 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.bluehost.com with SMTP; 4 Jul 2013 16:11:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=GF99EDUBkGZxeRiUj2RGR81iYXdBiU5DENjommwgIU0=; b=ZoBNsjSMMTGPNPVW1n8BkKZVPyvxRTvQHQitapPdL6IRNiaspZyLe30V+pROVkMJ2a9R6P6dSyPz8zUSdv8ZYXYB47q2WjnN6RYv6jNcPrKMpiQIdTjdcUQnVVuS3cer; Received: from [72.66.111.124] (port=52616 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Uum8N-0005H7-63; Thu, 04 Jul 2013 10:11:51 -0600 From: "Richard Shockey" To: , References: <011501ce7676$79b756c0$6d260440$@shockey.us> <01bc01ce7691$e73f8bc0$b5bea340$@shockey.us> <51D1DC32.1080308@dcrocker.net> <520DE022-7E21-4B31-82E1-D332A2A94E63@oracle.com> <2B0F677F0B95454297753F58D4A07FA30127F61718@FHDP1LUMXC7V31.us.one.verizon.com> <51D4B768.5090503@dcrocker.net> In-Reply-To: <51D4B768.5090503@dcrocker.net> Date: Thu, 4 Jul 2013 12:11:48 -0400 Message-ID: <003d01ce78d1$306ed170$914c7450$@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: AQJPaVevflNMLqdh3roRBhUdD15G1QHDOB5LAuG5k5wBtTliXwNgAUs5AjSXZZ4AjlIjrwGLBWzvAp9ufcICmKNg0Je4zJFA 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] response-time window ( was Re: 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, 04 Jul 2013 16:12:18 -0000 Excellent point and a very good reminder. If memory serves me correctly in SS7 based CNAM the data retrieval is performed literally between the first and second ring on the terminating carrier networks. Less than .5 seconds. One of the important points here is we are trying to maintain the existing QoS QoE consumers and enterprises have come to expect. Call set up and delay is different in mobile networks. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dave Crocker Sent: Wednesday, July 03, 2013 7:45 PM To: stir@ietf.org Subject: [stir] response-time window ( was Re: Out-of-band vs. in-band On 7/2/2013 10:57 AM, Henning Schulzrinne wrote: > Vaguely related: On the government side, we make numerous > entity-related items available to the public via HTTP APIs HTTP-based queries require a tcp open, at least one http exchange, and a tcp close. I never get the count right, but that's somewhere around 5-7 round-trip times. Since the current requirement is for queries from anywhere on the net to anywhere on the net, these aggregate round-trip latencies can be significant. Measured in seconds. My understanding is that verification needs to be performed within the final stages of call set up. I assume that's a window of less than a second, and presumably quite a bit less. One of the functional requirements that would be helpful to specify is the performance window that must be met by the validation mechanism. d/ ps. A facile response to response-time concerns is to invoke various optimizations such as caching connections, or the like. That's fine, except when it isn't, which is frequently. Designing for best-case scenarios is a tad fragile. -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From dhc@dcrocker.net Thu Jul 4 10: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 4919921F9DB6 for ; Thu, 4 Jul 2013 10:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcXls0BAe+cV for ; Thu, 4 Jul 2013 10:41:04 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 62AE821F9D90 for ; Thu, 4 Jul 2013 10:41:03 -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 r64Hf0ng031425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 4 Jul 2013 10:41:03 -0700 Message-ID: <51D5B39D.5020006@dcrocker.net> Date: Thu, 04 Jul 2013 10:40:45 -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: <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: 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, 04 Jul 2013 10:41:03 -0700 (PDT) Subject: [stir] munging header munging (was Re: 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, 04 Jul 2013 17:41:09 -0000 On 7/3/2013 3:12 PM, Hadriel Kaplan wrote: > What I find most ironic about your statement is that while at least > SBC's can be configured to pass/drop headers, most of the *other* > B2BUAs in the call path don't pass along unknown headers at all, ... >> On Jun 28, 2013, at 3:28 PM, Cullen Jennings (fluffy) >> wrote: >>> On Jun 20, 2013, at 8:46 AM, "Rosen, Brian" >>> wrote: >>> I'll add to that with AFAIC, the bulk of deployed SBC are >>> configured to remove anything they don't understand. ... >> On related note, if we defined a new header and carriers wanted >> that header to make it thought there network, I think for many >> cases they could probably do that only by changing configuration of >> equipment. I realize that even a configuration change is a big deal >> but it's a smaller deal that software upgrades. The question of what header fields can or cannot make it through which devices and when is another source of entropy in the current discussions. The group needs to settle on some basic assertions of fact about the way header fields are treated along various paths. The group then needs to settle on the basic ways of resolving these. The are 'meta' issues, in that they are getting in the way of lower-level debates about specific design choices. IMO, the worst possible choice will be to define two -- oh what the heck, maybe more -- parallel mechanisms. There's no precedent for such a thing working at scale and the complexities, fragilities and incentives make it unlikely it will in this case. Some localized issues might be handled by specialized, /localized/ hacks. Some issues might be handled by obtaining changes in the problem devices. Some issues might be handled by excluding some cases from the architecture. (Yes, I mean explicitly admitting from the start that specific scenarios won't be haled.) And so on. If the group can settle on these matters of fact and these strategic scenario choices, figuring out what one, integrated design is likely to be viable will get quite a bit easier. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Henning.Schulzrinne@fcc.gov Fri Jul 5 08:19: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 3106411E811E for ; Fri, 5 Jul 2013 08:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.859 X-Spam-Level: X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.740, 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 4fV0mKZGltDf for ; Fri, 5 Jul 2013 08:19:54 -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 0B28D11E8131 for ; Fri, 5 Jul 2013 08:19:53 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "'dcrocker@bbiw.net'" , "stir@ietf.org" Thread-Topic: [stir] response-time window ( was Re: Out-of-band vs. in-band Thread-Index: AQHOeEd/5C1NbQZuLUSOHqVukoWfIJlWMrRQ Date: Fri, 5 Jul 2013 15:19:20 +0000 References: <011501ce7676$79b756c0$6d260440$@shockey.us> <01bc01ce7691$e73f8bc0$b5bea340$@shockey.us> <51D1DC32.1080308@dcrocker.net> <520DE022-7E21-4B31-82E1-D332A2A94E63@oracle.com> <2B0F677F0B95454297753F58D4A07FA30127F61718@FHDP1LUMXC7V31.us.one.verizon.com> <51D4B768.5090503@dcrocker.net> In-Reply-To: <51D4B768.5090503@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 Subject: Re: [stir] response-time window ( was Re: 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, 05 Jul 2013 15:19:58 -0000 There are two cases: If a carrier validates, the TCP/HTTP connection to the= server will most likely be reused, i.e., no TCP or TLS overhead on a per-q= uery basis. The query overhead would be essentially the same as a UDP-based= query, i.e., one RTT. For end system validation, which is almost invariabl= y going to occur on mobile devices (smartphones), any query overhead would = add to the post-dial delay and indeed incur the setup cost you mention. As = Richard alludes to, there are no standards for PDD, but I did find http://www.niccstandards.org.uk/files/current/ND1704v1_2_2.pdf?type=3Dpdf It postulates a PDD of 10 seconds for mobile connections, so 1-2 seconds fo= r the query are annoying but hardly a deal breaker. This would only likely = occur for calls not in the user's address book. Just to re-iterate: I suspect all or almost all of us would prefer an infra= structure solution. If no such solution is forthcoming, however, I suspect = that there is a market for consumers who are willing to trade off increased= delay for what are mostly robocalls for a bit of peace-and-quiet. There ar= e millions that do this today, despite rather limited functionality. Henning -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dav= e Crocker Sent: Wednesday, July 03, 2013 7:45 PM To: stir@ietf.org Subject: [stir] response-time window ( was Re: Out-of-band vs. in-band On 7/2/2013 10:57 AM, Henning Schulzrinne wrote: > Vaguely related: On the government side, we make numerous=20 > entity-related items available to the public via HTTP APIs HTTP-based queries require a tcp open, at least one http exchange, and a tc= p close. I never get the count right, but that's somewhere around 5-7 roun= d-trip times. Since the current requirement is for queries from anywhere o= n the net to anywhere on the net, these aggregate round-trip latencies can = be significant. Measured in seconds. My understanding is that verification needs to be performed within the fina= l stages of call set up. I assume that's a window of less than a second, a= nd presumably quite a bit less. One of the functional requirements that would be helpful to specify is the = performance window that must be met by the validation mechanism. d/ ps. A facile response to response-time concerns is to invoke various=20 optimizations such as caching connections, or the like. That's fine,=20 except when it isn't, which is frequently. Designing for best-case=20 scenarios is a tad fragile. --=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 Fri Jul 5 08:40: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 BB4E411E8314 for ; Fri, 5 Jul 2013 08:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.706, 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 Q8SBq+6ElLSG for ; Fri, 5 Jul 2013 08:40:27 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 3800A21F9FD9 for ; Fri, 5 Jul 2013 08:40:13 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "'dcrocker@bbiw.net'" , "stir@ietf.org" Thread-Topic: [stir] Follow the bouncing requirements (was - Re: Out-of-band vs. in-band) Thread-Index: AQHOeEY33FmBhhMOHkOJL8RPECq6SplWNa/g Date: Fri, 5 Jul 2013 15:40:12 +0000 References: <011501ce7676$79b756c0$6d260440$@shockey.us> <01bc01ce7691$e73f8bc0$b5bea340$@shockey.us> <51D1DC32.1080308@dcrocker.net> <520DE022-7E21-4B31-82E1-D332A2A94E63@oracle.com> <51D4B4B4.9050404@dcrocker.net> In-Reply-To: <51D4B4B4.9050404@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 Subject: Re: [stir] Follow the bouncing requirements (was - Re: 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, 05 Jul 2013 15:40:31 -0000 I'm not sure I follow this generalization.=20 DNS (not just for ENUM) clearly has evolved into both a private and a publi= c service; similarly, for LDAP and (obviously) HTTP, so almost any query se= rvice seems to eventually develop both modes. I think this goes back as far= as the old Unix "finger" protocol... In some cases, support is explicit (e.g., by baking authentication/authoriz= ation into the protocol), in others, it's implicit (e.g., by various VPN, f= irewalling and network address filtering solutions, as in local general DNS= and private ENUM), and in many cases, both. (HTTP servers restrict access = both based on explicit and address-based criteria.) If your argument is that it would be a good requirement to anticipate that = both modes will invariably arise, I tend to agree. The overall requirement is pretty simple, I think: as many authorized entit= ies as possible should be able to assert number usage and as many entities = as possible along the call path should be able to validate. As a minimum re= quirement, all SIP entities (UAs, proxies, SBCs and B2BUAs) should be able = to act as certifier and validator. As a desirable requirement, entities tha= t are separated by SS7 or other non-IP stretches should be able to validate= . As I've been trying to argue, this can and should be part of the same ove= rall architecture, i.e., it would be nice if neither certifier nor validato= r has to know about the nature of the other side. We have discussed two mod= els to make this happen: (1) in some cases, the SIP Identity-style information can be tunneled throu= gh SS7, via UUI, and re-inserted into the SIP call, if needed. As far as I = can tell, this doesn't seem controversial. The only issue is how often this= is feasible. (2) In other cases, the SIP Identity-style information may be carried in IP= mechanisms even if the call itself is not signaled that way. I suspect we = need more concrete proposals here to see if this can be integrated into the= overall model, satisfying the "blissful ignorance" criteria I mentioned ea= rlier. In all cases, the fundamental model ("number assignment authority provides = certificate directly or indirectly", as well as the protection realm) is th= e same and the assertion ("Caller X is entitled to use number N for this ca= ll") as well. Logically, I think this leads to 4 drafts: (1) The certificate or cryptographic object (if not X.509) structure. (2) The SIP headers. (3) How to embed (2) into SS7 UUI. (4) How to deal with non-IP stretches. Henning -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dav= e Crocker Sent: Wednesday, July 03, 2013 7:33 PM To: stir@ietf.org Cc: 'dcrocker@bbiw.net' Subject: [stir] Follow the bouncing requirements (was - Re: Out-of-band vs.= in-band) > For reasons mentioned earlier by others, I suspect that this would be=20 > private DNS (or servers) regardless of the number visibility issue,=20 > but that doesn't seem like something we need to prescribe. This is an example of a core issue that keeps prompting conflicting stateme= nts. What I heard early in discussion was that validation was to be possible by = enterprises and SIP UAs. That requires a public external service for retri= eving validation parameters. The larger point is that it really is important to establish a stable, smal= l, clear set of basic functional requirements so that design discussions (a= nd debates) can rely on them. And to anticipate one line of logic that also has shown up a number of time= s, whatever is done initially is what's likely to stay in place forever. P= rojections that something will be done one way at first and then somehow, l= ater, be done differently, has little precedent on the Internet. (Marc Ant= hony got it right: the evil men do really does live after them.) So, for example, having the external query service be private initially mea= ns it will stay private. d/ ps. One issue that I've been unclear about is how the validated telephone n= umber will get used. That is, the processing agent now has a validated num= ber. So what? What can/will be done differently and why are we sure that = it really will be? -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From Henning.Schulzrinne@fcc.gov Fri Jul 5 08: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 6F1B311E8302 for ; Fri, 5 Jul 2013 08:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.623 X-Spam-Level: X-Spam-Status: No, score=-0.623 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j69d-ISKrc18 for ; Fri, 5 Jul 2013 08:43:43 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id F3E2E11E8321 for ; Fri, 5 Jul 2013 08:43:42 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "stir@ietf.org" Thread-Topic: U.S. Senate hearing on robocalls July 10, 2013 Thread-Index: Ac55ll2Rp2J08HAPQF6sU8EdWKmeUA== Date: Fri, 5 Jul 2013 15:43:42 +0000 Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E6A16181E5FD2F46B962315BB05962D01FB6FD0Ep2pxmb13fccnetw_" MIME-Version: 1.0 Subject: [stir] U.S. Senate hearing on robocalls July 10, 2013 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 15:43:47 -0000 --_000_E6A16181E5FD2F46B962315BB05962D01FB6FD0Ep2pxmb13fccnetw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://www.commerce.senate.gov/public/index.cfm?p=3DHearings Stopping Fraudulent Robocall Scams: Can More Be Done? Democratic Press Office - (202) 224-8374 Jul 10 2013 10:00 AM Russell Senate Office Building - 253 --_000_E6A16181E5FD2F46B962315BB05962D01FB6FD0Ep2pxmb13fccnetw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

http://www.commerce.senate.gov/public/index.cfm?p=3DHe= arings

 

Stopping Fraudulent Robocall Scams: Can More Be Done?<= /h1>

Democratic Press Office - (202) 224-8374=

Jul 10 2013 10:00 AM

Russell Senate Office Building - 253

 

--_000_E6A16181E5FD2F46B962315BB05962D01FB6FD0Ep2pxmb13fccnetw_-- From richard@shockey.us Fri Jul 5 09:11: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 B107611E82F1 for ; Fri, 5 Jul 2013 09:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.457 X-Spam-Level: X-Spam-Status: No, score=-101.457 tagged_above=-999 required=5 tests=[AWL=0.807, 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 F-KsCgRh7u7L for ; Fri, 5 Jul 2013 09:11:09 -0700 (PDT) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id B92C911E813D for ; Fri, 5 Jul 2013 09:11:08 -0700 (PDT) Received: (qmail 32002 invoked by uid 0); 5 Jul 2013 16:10:46 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy13.unifiedlayer.com with SMTP; 5 Jul 2013 16:10:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=q8TvkpnRCG0iuq6RUyFR6xoglMT45X6FD3ptyguqY1c=; b=BCu90A3MGVs56kBTgPDh6ifVEKlIbqWZcp418F99OXuXouzXydOKDtsie1+Fi+0qEGlWukLHdc7USZ2Fzuz4W8/qvwhFsOfR9p31oTlCox6NddkIesXW49PJlbTv1Rjt; Received: from [72.66.111.124] (port=49747 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Uv8as-0001H5-62; Fri, 05 Jul 2013 10:10:46 -0600 From: "Richard Shockey" To: "'Henning Schulzrinne'" , References: In-Reply-To: Date: Fri, 5 Jul 2013 12:10:43 -0400 Message-ID: <007201ce799a$34539360$9cfaba20$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0073_01CE7978.AD437A00" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHodzCA9LgCAfhuWd/FCK4mTC0xc5kiRbbA 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] U.S. Senate hearing on robocalls July 10, 2013 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 16:11:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0073_01CE7978.AD437A00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Any agenda? Who is testifying . From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Friday, July 05, 2013 11:44 AM To: stir@ietf.org Subject: [stir] U.S. Senate hearing on robocalls July 10, 2013 http://www.commerce.senate.gov/public/index.cfm?p=Hearings Stopping Fraudulent Robocall Scams: Can More Be Done? Democratic Press Office - (202) 224-8374 Jul 10 2013 10:00 AM Russell Senate Office Building - 253 ------=_NextPart_000_0073_01CE7978.AD437A00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Any agenda?  Who is testifying … =

 

From: stir-bounces@ietf.org = [mailto:stir-bounces@ietf.org] On Behalf Of Henning = Schulzrinne
Sent: Friday, July 05, 2013 11:44 AM
To: = stir@ietf.org
Subject: [stir] U.S. Senate hearing on robocalls = July 10, 2013

 

htt= p://www.commerce.senate.gov/public/index.cfm?p=3DHearings<= /p>

 

Stopping Fraudulent Robocall = Scams: Can More Be Done?

Democratic = Press Office - (202) 224-8374

Jul 10 2013 10:00 AM

Russell Senate Office Building - 253

 

------=_NextPart_000_0073_01CE7978.AD437A00-- From pkyzivat@alum.mit.edu Fri Jul 5 10:40: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 D10AB11E811A for ; Fri, 5 Jul 2013 10:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.007 X-Spam-Level: X-Spam-Status: No, score=0.007 tagged_above=-999 required=5 tests=[AWL=0.444, 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 eyDlPzRID-4B for ; Fri, 5 Jul 2013 10:40:51 -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 66F8211E80A5 for ; Fri, 5 Jul 2013 10:40:50 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta15.westchester.pa.mail.comcast.net with comcast id wgf01l0070mv7h05FhgqG2; Fri, 05 Jul 2013 17:40:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id whgq1l00Z3ZTu2S3Xhgq31; Fri, 05 Jul 2013 17:40:50 +0000 Message-ID: <51D70521.1020908@alum.mit.edu> Date: Fri, 05 Jul 2013 13:40:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: stir@ietf.org References: <51CE17A6.2090605@dcrocker.net> <622DD31F-896F-4352-B811-7AFA0083758D@brianrosen.net> <51D430CA.2030300@dcrocker.net> <2B0F677F0B95454297753F58D4A07FA3012801EBF3@FHDP1LUMXC7V31.us.one.verizon.com> <2B0F677F0B95454297753F58D4A07FA3012801ECEB@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3012801ECEB@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=1373046050; bh=KRi8XI695JW86rHTwdJM2Nsgs40f7mzaHUiA9aXJtJM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=afW3o1/t9ZxylP65LsOTYb1ul/0ChwICtl2q+DL6KWQo9Llr+MkxxlbOvcQoK7iV/ v96RMtbzxWhvF+vY7B711WmtmTpQCOboRIr4g9D09wYkqC8iBNWPc7ZTF1EQpdU2wc 82CKNK4wYR1KeZrIjU+NbRlQ8GngFterkTkebbRGq6ot8wtad8qDvLDoJ2uiUaPeEm iwO+5FIJCgpGOAljHu7wU2qlXxMyFRUc4k5Y5DewMwJkQtImjykX8sPrUi2cBCZyEo nqqggB3FaVeK/hpKNJlX563CoPO1oJdhvr+ubfthmkDytaUmCHci3t5cBzoZpfJREP vTm78Eax2F8YA== Subject: Re: [stir] Replacing rfc4474 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 05 Jul 2013 17:41:00 -0000 On 7/3/13 12:10 PM, Dwight, Timothy M (Tim) wrote: > I don't see a problem with any of those, assuming the phone-context URI parameter is properly used. Of course if it's not, and you don't otherwise know where the call came from (e.g., by a trunk group parameter) you're in trouble. But in that case the problem's unsolvable... which contradicts Hadriel's "trust me it works today" assertion. Does anybody actually use phone-context? How many implementations will do anything reasonable if they see it? Thanks, Paul > Tim > > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, July 03, 2013 9:55 AM > To: Dwight, Timothy M (Tim) > Cc: dcrocker@bbiw.net; stir@ietf.org > Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) > > The From problem is lack of country codes, and maybe worse. Consider these possible From: contents > 5551212 > 2025551212 > 12025551212 > +12025551212 > and of course all the variations with parens, spaces, hyphens, commas, periods, etc. > > Although the first is getting really rare, I think it still happens > > The problem with these is when they appear in From on an international call - the first 2 are the real problems. They would have to be rewritten. > > With To:, you get the variations with dial 9/8/... in enterprise systems, and the 011 style prefix > > Brian > > > > On Jul 3, 2013, at 10:39 AM, "Dwight, Timothy M (Tim)" wrote: > >> Could someone provide a few examples? I have to say I find this thread hard to follow. I trust the individuals making the arguments to be knowledgeable and honest, but personally I have little experience with this "FROM header manipulation" that I'm told is so rampant. >> >> The only example I can think of is the "SIP trunking" use case I raised previously (user part of URI in FROM and/or TO header may be significant only within the dial plan of the associated Enterprise) which was ruled out of scope for this activity. So I'm puzzled, what use cases there are that (a) are in scope for this exercise, and (b) involve manipulation of the user part of the URI in the FROM header. >> >> Apologies in advance if this is obvious to everyone else and I'm the only one who doesn't "get it". >> >> Thanks, >> >> Tim >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen >> Sent: Wednesday, July 03, 2013 9:23 AM >> To: dcrocker@bbiw.net >> Cc: stir@ietf.org >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) >> >> There are a lot of local variations out there, but they all have the property that in order to route them, you need to be able to figure out at least the "left" part of the e.164 is, and the right part has to pass unscathed in order to work. Since everyone, and I mean everyone, dealing with these systems knows what e.164s are, and how they work, I don't think it's necessary, or even possible to describe all of the various ways the strings might appear and what to do with them. >> >> All we need say is that in order to work, the header contents has to be able to have the canonical e.164 extracted with no knowledge at the validator, and validations can occur anywhere in the call path. We'll dress up that text a lot I am sure, but the notion that we could write, or need a document describing all possible variations of how telephone numbers may appear and how to extract the e.164 in each of them seems to me to be silly. >> >> It may be possible to specify an algorithm however. >> >> Brian >> >> On Jul 3, 2013, at 10:10 AM, Dave Crocker wrote: >> >>> On 7/3/2013 6:50 AM, Brian Rosen wrote: >>>> Catching up (I was out for a week) >>>> On Jun 28, 2013, at 7:09 PM, Dave Crocker wrote: >>>> >>>>> 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.) >>>> e.164s are much more constrained than the email address issues DKIM has to deal with. We could have challenges with local dial plans, and we've been discussing those issues, but the easy way out on those is that they may not be covered if both ends don't understand the dial plan the same way. >>>> >>>> So far, while we have one issue I'm concerned with (verifier not being able to extract a canonical e.164 from the content of "From"), I don't think the DKIM experience is particularly relevant. >>> >>> >>> Brian, >>> >>> Thanks. Good to hear. >>> >>> I assume there is a document that specifies all of the variations that will be encountered and how to deterministically and successfully transform them into the single, canonical representation? >>> >>> Absent that, this topic remains a likely source of non-interoperability. >>> >>> 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 richard@shockey.us Fri Jul 5 11: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 1BA8621F9FFB for ; Fri, 5 Jul 2013 11:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.538 X-Spam-Level: X-Spam-Status: No, score=-101.538 tagged_above=-999 required=5 tests=[AWL=0.727, 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 REuunIDOynRR for ; Fri, 5 Jul 2013 11:17:59 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 8033C21F9FF6 for ; Fri, 5 Jul 2013 11:17:59 -0700 (PDT) Received: (qmail 24999 invoked by uid 0); 5 Jul 2013 16:24:23 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy14.unifiedlayer.com with SMTP; 5 Jul 2013 16:24:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=OAnNZyo8PRsg5JLbeLpIM/rNIlTCj/TEQhUU2VHYPwQ=; b=hfAaKgnNeYCtBHwfTcI3lw0DJykP3SWqSD14ChhYp8r3b9QLo3GjBQ2N+vvnJHrO/nyjVWJhxNfhPFMCGlD61t5rQ/V9RB9AGuHA3bU8zYDD764/W4500TAnm6bR2M+4; Received: from [72.66.111.124] (port=49789 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Uv8o3-0004Ii-5E; Fri, 05 Jul 2013 10:24:23 -0600 From: "Richard Shockey" To: "'Henning Schulzrinne'" , References: <011501ce7676$79b756c0$6d260440$@shockey.us> <01bc01ce7691$e73f8bc0$b5bea340$@shockey.us> <51D1DC32.1080308@dcrocker.net> <520DE022-7E21-4B31-82E1-D332A2A94E63@oracle.com> <51D4B4B4.9050404@dcrocker.net> In-Reply-To: Date: Fri, 5 Jul 2013 12:24:20 -0400 Message-ID: <007701ce799c$1b474e00$51d5ea00$@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: AQJPaVevflNMLqdh3roRBhUdD15G1QHDOB5LAuG5k5wBtTliXwNgAUs5AjSXZZ4AjlIjrwIyV+bgAuNOPTOXx8xmkA== 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] Follow the bouncing requirements (was - Re: 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, 05 Jul 2013 18:18:04 -0000 As a series of phase one drafts .. I completely agree. >From that you naturally lead to A. Number Translation HTTP vs DNS 6116 B. Certificate Discovery HTTP vs DNS 6116 C. Transport that should be relatively easy. Oh ... regulatory enforcement/encouragement mechanisms. This is Tim Dwight's point. We can certainly build this thing but the rules as written leave US carriers few options. As it stands they cannot block an offending call center. "The Call must go through". What limitations of liability would the carrier be offered under these circumstances? Ok yes this is a US centric view and it seems that some national jurisdictions have considerably more leeway in how to deal with bad actors. The Germans for instance. We need better data on what is happening in the EC Asia etc. I've certainly been convinced from the outset that any IETF solution is no silver bullet there has to be some cooperation from the regulators since its their namespace after all. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Friday, July 05, 2013 11:40 AM To: 'dcrocker@bbiw.net'; stir@ietf.org Subject: Re: [stir] Follow the bouncing requirements (was - Re: Out-of-band vs. in-band) I'm not sure I follow this generalization. DNS (not just for ENUM) clearly has evolved into both a private and a public service; similarly, for LDAP and (obviously) HTTP, so almost any query service seems to eventually develop both modes. I think this goes back as far as the old Unix "finger" protocol... In some cases, support is explicit (e.g., by baking authentication/authorization into the protocol), in others, it's implicit (e.g., by various VPN, firewalling and network address filtering solutions, as in local general DNS and private ENUM), and in many cases, both. (HTTP servers restrict access both based on explicit and address-based criteria.) If your argument is that it would be a good requirement to anticipate that both modes will invariably arise, I tend to agree. The overall requirement is pretty simple, I think: as many authorized entities as possible should be able to assert number usage and as many entities as possible along the call path should be able to validate. As a minimum requirement, all SIP entities (UAs, proxies, SBCs and B2BUAs) should be able to act as certifier and validator. As a desirable requirement, entities that are separated by SS7 or other non-IP stretches should be able to validate. As I've been trying to argue, this can and should be part of the same overall architecture, i.e., it would be nice if neither certifier nor validator has to know about the nature of the other side. We have discussed two models to make this happen: (1) in some cases, the SIP Identity-style information can be tunneled through SS7, via UUI, and re-inserted into the SIP call, if needed. As far as I can tell, this doesn't seem controversial. The only issue is how often this is feasible. (2) In other cases, the SIP Identity-style information may be carried in IP mechanisms even if the call itself is not signaled that way. I suspect we need more concrete proposals here to see if this can be integrated into the overall model, satisfying the "blissful ignorance" criteria I mentioned earlier. In all cases, the fundamental model ("number assignment authority provides certificate directly or indirectly", as well as the protection realm) is the same and the assertion ("Caller X is entitled to use number N for this call") as well. Logically, I think this leads to 4 drafts: (1) The certificate or cryptographic object (if not X.509) structure. (2) The SIP headers. (3) How to embed (2) into SS7 UUI. (4) How to deal with non-IP stretches. Henning -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dave Crocker Sent: Wednesday, July 03, 2013 7:33 PM To: stir@ietf.org Cc: 'dcrocker@bbiw.net' Subject: [stir] Follow the bouncing requirements (was - Re: Out-of-band vs. in-band) > For reasons mentioned earlier by others, I suspect that this would be > private DNS (or servers) regardless of the number visibility issue, > but that doesn't seem like something we need to prescribe. This is an example of a core issue that keeps prompting conflicting statements. What I heard early in discussion was that validation was to be possible by enterprises and SIP UAs. That requires a public external service for retrieving validation parameters. The larger point is that it really is important to establish a stable, small, clear set of basic functional requirements so that design discussions (and debates) can rely on them. And to anticipate one line of logic that also has shown up a number of times, whatever is done initially is what's likely to stay in place forever. Projections that something will be done one way at first and then somehow, later, be done differently, has little precedent on the Internet. (Marc Anthony got it right: the evil men do really does live after them.) So, for example, having the external query service be private initially means it will stay private. d/ ps. One issue that I've been unclear about is how the validated telephone number will get used. That is, the processing agent now has a validated number. So what? What can/will be done differently and why are we sure that it really will be? -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From york@isoc.org Sat Jul 6 03:59: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 E3DC721F89A6 for ; Sat, 6 Jul 2013 03:59: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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESKSLhaDq3aP for ; Sat, 6 Jul 2013 03:59:26 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id 02B2421F894E for ; Sat, 6 Jul 2013 03:59:26 -0700 (PDT) Received: from BLUPR06MB067.namprd06.prod.outlook.com (10.242.187.146) by BLUPR06MB067.namprd06.prod.outlook.com (10.242.187.146) with Microsoft SMTP Server (TLS) id 15.0.702.21; Sat, 6 Jul 2013 10:59:24 +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; Sat, 6 Jul 2013 10:59:24 +0000 From: Dan York To: Richard Shockey Thread-Topic: [stir] U.S. Senate hearing on robocalls July 10, 2013 Thread-Index: Ac55ll2Rp2J08HAPQF6sU8EdWKmeUAAA9WOAACdq/rU= Date: Sat, 6 Jul 2013 10:59:22 +0000 Message-ID: References: , <007201ce799a$34539360$9cfaba20$@shockey.us> In-Reply-To: <007201ce799a$34539360$9cfaba20$@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:470:1f07:309:28e6:d577:74db:3ab1] x-forefront-prvs: 0899B47777 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(377454003)(199002)(124975003)(24454002)(74366001)(81542001)(74662001)(83072001)(56816003)(53806001)(74706001)(76482001)(79102001)(47976001)(47736001)(15202345003)(33656001)(16406001)(31966008)(56776001)(59766001)(76786001)(47446002)(65816001)(4396001)(49866001)(77982001)(36756003)(80022001)(77096001)(46102001)(76796001)(74876001)(63696002)(54316002)(81342001)(16236675002)(51856001)(69226001)(50986001)(54356001)(74502001)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB067; H:BLUPR06MB067.namprd06.prod.outlook.com; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_AC54F3DE75A8432FBE6F14415B12C66Cisocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org Cc: "stir@ietf.org" , Henning Schulzrinne Subject: Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 10:59:31 -0000 --_000_AC54F3DE75A8432FBE6F14415B12C66Cisocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Will anyone be able to watch this and perhaps post a summary? I will unfor= tunately be in transit (heading to ICANN 47) but would be interested to lea= rn what was said. Dan On Jul 5, 2013, at 12:11 PM, "Richard Shockey" > wrote: Any agenda? Who is testifying ... From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Friday, July 05, 2013 11:44 AM To: stir@ietf.org Subject: [stir] U.S. Senate hearing on robocalls July 10, 2013 http://www.commerce.senate.gov/public/index.cfm?p=3DHearings Stopping Fraudulent Robocall Scams: Can More Be Done? Democratic Press Office - (202) 224-8374 Jul 10 2013 10:00 AM Russell Senate Office Building - 253 _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_AC54F3DE75A8432FBE6F14415B12C66Cisocorg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Will anyone be able to watch this and perhaps post a summary?  I = will unfortunately be in transit (heading to ICANN 47) but would be interes= ted to learn what was said. 

Dan


On Jul 5, 2013, at 12:11 PM, "Richard Shockey" <richard@shockey.us> wrote:

Any agenda?  Who = is testifying …

 

From: stir-bounces@ietf.org [mailt= o:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne
Sent: Friday, July 05, 2013 11:44 AM
To: stir@ietf.org
Subject: [stir] U.S. Senate hearing on robocalls July 10, 2013<= /o:p>

 

http://www.commerce.senate.gov/public/index.cfm?p=3DHe= arings

 

Stopping Fraudulent Robocall Scams: Can More Be Done?<= /h1>

Democratic Press Office - (202) 224-8374=

Jul 10 2013 10:00 AM

Russell Senate Office Building - 253

 

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ie= tf.org/mailman/listinfo/stir
--_000_AC54F3DE75A8432FBE6F14415B12C66Cisocorg_-- From Henning.Schulzrinne@fcc.gov Sat Jul 6 10:02: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 ED27021F9C7D for ; Sat, 6 Jul 2013 10:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.702, 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 Q+L7mc6Fd0gw for ; Sat, 6 Jul 2013 10:02:00 -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 E992321F9C7C for ; Sat, 6 Jul 2013 10:01:59 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Dan York , Richard Shockey Thread-Topic: [stir] U.S. Senate hearing on robocalls July 10, 2013 Thread-Index: Ac55ll2Rp2J08HAPQF6sU8EdWKmeUAAJVyiAACdq6wAABELmgw== Date: Sat, 6 Jul 2013 17:01:56 +0000 References: , <007201ce799a$34539360$9cfaba20$@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] U.S. Senate hearing on robocalls July 10, 2013 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 17:02:04 -0000 Usually, either CSPAN and/or the Senate web site will have a video recordin= g. ________________________________ From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Dan York [= york@isoc.org] Sent: Saturday, July 06, 2013 6:59 AM To: Richard Shockey Cc: stir@ietf.org; Henning Schulzrinne Subject: Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 Will anyone be able to watch this and perhaps post a summary? I will unfor= tunately be in transit (heading to ICANN 47) but would be interested to lea= rn what was said. Dan On Jul 5, 2013, at 12:11 PM, "Richard Shockey" > wrote: Any agenda? Who is testifying =85 From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Friday, July 05, 2013 11:44 AM To: stir@ietf.org Subject: [stir] U.S. Senate hearing on robocalls July 10, 2013 http://www.commerce.senate.gov/public/index.cfm?p=3DHearings Stopping Fraudulent Robocall Scams: Can More Be Done? Democratic Press Office - (202) 224-8374 Jul 10 2013 10:00 AM Russell Senate Office Building - 253 _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From pkyzivat@alum.mit.edu Sun Jul 7 11:07: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 651FA11E80F0 for ; Sun, 7 Jul 2013 11:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.015 X-Spam-Level: X-Spam-Status: No, score=-0.015 tagged_above=-999 required=5 tests=[AWL=0.422, 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 zQG-0zIqtOdc for ; Sun, 7 Jul 2013 11:07:47 -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 78E2311E80EE for ; Sun, 7 Jul 2013 11:07:46 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta05.westchester.pa.mail.comcast.net with comcast id xVtt1l0091vXlb855W7mbN; Sun, 07 Jul 2013 18:07:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id xW7m1l0013ZTu2S3dW7m1W; Sun, 07 Jul 2013 18:07:46 +0000 Message-ID: <51D9AE70.2010104@alum.mit.edu> Date: Sun, 07 Jul 2013 14:07:44 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: stir@ietf.org References: <51D1D424.8000003@dcrocker.net> In-Reply-To: <51D1D424.8000003@dcrocker.net> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373220466; bh=bWKu7My1bmzMb1bG800/UxUwAXJ4fOCvGsuqYwxnD+8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=M+caT+3x/OvsSfWj7Yi1xJie6L3X1YJGPYGZbDpvVKWJlvU7McpXD1VFkapbYCYd4 wAEH+ALAEks/JpJvg4zi9f+HENuOdxO+treRDHEoe1eGpCVoySXT7jbBEVvGmST6Kv uIK8BkJk7Z/O34wDh3/WQJJ3W0GEcrn8R8lZqfeNOC9baJt4quU5jfoxp/dW1ER4MV /nBn0e946f9ffb4FPEjWj+SZ8/8n3j6P1tp+TtzXBnL/8gey5foMpBAL5++ygLiSL/ FnI7zqw8DxyzBCpiHdXNxnFbGD4KsXO1EHaujumkr8/aDio2r6HBL00nMKcPslKTRX lP2mgweeNXGHg== Subject: Re: [stir] Replacing rfc4474 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jul 2013 18:07:53 -0000 On 7/1/13 3:10 PM, Dave Crocker wrote: >> Being able to differentiate a user part that is a phone number from a >> user part that is not is not entirely trivial, as has been previously >> discussed in this thread. A verifier that receives a request needs to >> figure out if the user part is a telephone number or not. Ideally, >> the verifier would understand the handling of the case where it is >> not. Won't the presence of a phone-number-based signature serve as an differentiator that From is intended, by the signer, to be interpreted as a phone number? Thanks, Paul From dhc@dcrocker.net Mon Jul 8 10:04: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 8FD5721F9C7A for ; Mon, 8 Jul 2013 10:04:13 -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 Xkyz+ehEnecM for ; Mon, 8 Jul 2013 10:04:08 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E3FB021F9D0A for ; Mon, 8 Jul 2013 10:04: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 r68H41f1013191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Jul 2013 10:04:04 -0700 Message-ID: <51DAF0EB.5000508@dcrocker.net> Date: Mon, 08 Jul 2013 10:03:39 -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: Paul Kyzivat References: <51D1D424.8000003@dcrocker.net> <51D9AE70.2010104@alum.mit.edu> In-Reply-To: <51D9AE70.2010104@alum.mit.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]); Mon, 08 Jul 2013 10:04:04 -0700 (PDT) Cc: stir@ietf.org 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: Mon, 08 Jul 2013 17:04:13 -0000 On 7/7/2013 11:07 AM, Paul Kyzivat wrote: > On 7/1/13 3:10 PM, Dave Crocker wrote: > >>> Being able to differentiate a user part that is a phone number from a >>> user part that is not is not entirely trivial, as has been previously >>> discussed in this thread. A verifier that receives a request needs to >>> figure out if the user part is a telephone number or not. Ideally, >>> the verifier would understand the handling of the case where it is >>> not. > > Won't the presence of a phone-number-based signature serve as an > differentiator that From is intended, by the signer, to be interpreted > as a phone number? From an information theoretic standpoint, I suppose you might be right. However in terms of protocol simplicity and clarity, having to go outside a field, to understand what is meant inside it, is fragile at best and likely problematic. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From pkyzivat@alum.mit.edu Mon Jul 8 15:03: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 B9C6D21F9E6D for ; Mon, 8 Jul 2013 15:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.059 X-Spam-Level: X-Spam-Status: No, score=-0.059 tagged_above=-999 required=5 tests=[AWL=0.378, 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 kz5cT+xB9QRv for ; Mon, 8 Jul 2013 15:03:15 -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 3C3D221F9E51 for ; Mon, 8 Jul 2013 15:03:08 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta08.westchester.pa.mail.comcast.net with comcast id xnoz1l0031GhbT858y384Q; Mon, 08 Jul 2013 22:03:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id xy371l02K3ZTu2S3Ty38eM; Mon, 08 Jul 2013 22:03:08 +0000 Message-ID: <51DB371B.6060607@alum.mit.edu> Date: Mon, 08 Jul 2013 18:03:07 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <51D1D424.8000003@dcrocker.net> <51D9AE70.2010104@alum.mit.edu> <51DAF0EB.5000508@dcrocker.net> In-Reply-To: <51DAF0EB.5000508@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=1373320988; bh=M+P9RB5SeAqHBzvpbypmrjeLJR3P2rQ/kteCM/uWW4o=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=RiWAB39BuNcjJhSafUSvIhxIGsdX7lwaHLvHCUwaMLRJBIQQZyiuYwlyngwEdKond NM0DZABmY3Pqp9+1cvI6G2+sUSw8EnloKFzrbkRPr2AlyRJmS7t1Bj5lowggy6TMhr yoQJU4iRYtbkreCF1cHHbBGGdQAJNtm4HFtCRtLZuW7Ih4ndext+vgWnJWB/ehW4Lw tedLUO9tCDr6jyX+iAOvdO7xus+ydlbC8RD872wqAYqh4lKcpeosmrwf10NPFP3YWs TrgAWiQhIHca1Lq+8ztGaMdBZBp7r67pJeJ7MeF09lP3bt3MTN18DTUzmuSjfUY0r/ yw8vL6FAcucVQ== Cc: stir@ietf.org, Dave Crocker Subject: Re: [stir] Replacing rfc4474 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 08 Jul 2013 22:03:20 -0000 On 7/8/13 1:03 PM, Dave Crocker wrote: > On 7/7/2013 11:07 AM, Paul Kyzivat wrote: >> On 7/1/13 3:10 PM, Dave Crocker wrote: >> >>>> Being able to differentiate a user part that is a phone number from a >>>> user part that is not is not entirely trivial, as has been previously >>>> discussed in this thread. A verifier that receives a request needs to >>>> figure out if the user part is a telephone number or not. Ideally, >>>> the verifier would understand the handling of the case where it is >>>> not. >> >> Won't the presence of a phone-number-based signature serve as an >> differentiator that From is intended, by the signer, to be interpreted >> as a phone number? > > > From an information theoretic standpoint, I suppose you might be right. > > However in terms of protocol simplicity and clarity, having to go > outside a field, to understand what is meant inside it, is fragile at > best and likely problematic. ISTM there are several distinct, though closely related, issues here: 1) Does From contain a phone number that the sender of the request is entitled to assert? 2) What should be displayed as callerid? 3) What should the receiver of a request with a particular From value save and use in the future for initiating requests to the caller? ISTM that the presence of a phone-number-based signature should be sufficient for an authenticator to attempt to authenticate in order to answer (1). And I think that is mostly what STIR is about. Dealing with (2) and (3) is tricky, and not something that has been standardized to date. The answer to (1) is one data point for answering (2) and (3), but IMO it is far from sufficient. *If* the decision is to take the "phone number" from From and display it as the callerid, then there are a lot of cases where that is what will be captured and used for making callbacks. (E.g., I copy the number off the phone and manually enter it into an address book.) If that is done, then when the phone number is used to initiate a new call, then the URI from From is likely to *not* be replicated. Instead, some arbitrary routing though telephony infrastructure may be used to get to that number. In many cases that will be "good enough", but not in all cases. The rules for sip routing say that a request addressed to a sip URI is to be routed solely based on the domain name until it reaches a server responsible for that domain. *Then* it may be translated/routed based on the user part. So the sender of a sip request with a SIP URI containing a phone number *should* be able to count on callbacks coming to its domain, via SIP. IMO the *right* answer (that nobody likes) is that if you want to have your phone number displayed as callerid, then you should put a TEL URI in From. If the From URI contains a sip URI, then that URI should be captured for use in callbacks. And probably the URI should be displaed as the callerid. It *might* be acceptable for some devices to capture the full URI but *display* the phone number. Unfortunately, that answer seems to be universally unpopular. If the intent is that (3) and (3) should be just the phone number, then we have broken the existing sip routing rules. If we want to do that, then we are carving out a reserved portion of the address space of the user-part of sip URIs in *every* domain, whether they want that or not. A middle ground is to use the ';user=phone' paramter to make the decision. (So that sip:number@domain;user=phone is officially equivalent to tel:number.) But that won't be enough for many/most people, and it won't work for non-e.164 number strings. I guess a way to sidestep this is to say that if you can authenticate as a phone number then you MAY display the number as a trusted callerid, but you aren't required to do so. And then leave the rest to implementations. Thanks, Paul From sanjay.mishra@verizon.com Wed Jul 10 10:26: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 20F4C21F9DEC for ; Wed, 10 Jul 2013 10:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.184 X-Spam-Level: X-Spam-Status: No, score=-1.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGiNyyLZ5NQu for ; Wed, 10 Jul 2013 10:26:27 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id DC80921F9963 for ; Wed, 10 Jul 2013 10:26:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe01.verizon.com with ESMTP; 10 Jul 2013 17:25:50 +0000 From: "Mishra, Sanjay" X-IronPort-AV: E=Sophos;i="4.87,1037,1363132800"; d="scan'208,217";a="506044891" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi03.verizon.com with ESMTP; 10 Jul 2013 17:25:50 +0000 Received: from fhdp1lumxc7v23.us.one.verizon.com ([166.68.59.159]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Wed, 10 Jul 2013 13:25:50 -0400 To: Dan York , Richard Shockey Date: Wed, 10 Jul 2013 13:25:49 -0400 Thread-Topic: [stir] U.S. Senate hearing on robocalls July 10, 2013 Thread-Index: Ac55ll2Rp2J08HAPQF6sU8EdWKmeUAAA9WOAACdq/rUA1INuUA== Message-ID: <900A1E2059ADB149B905E3C8FA0046A62C77C39220@FHDP1LUMXC7V23.us.one.verizon.com> References: , <007201ce799a$34539360$9cfaba20$@shockey.us> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_900A1E2059ADB149B905E3C8FA0046A62C77C39220FHDP1LUMXC7V2_" MIME-Version: 1.0 Cc: "stir@ietf.org" , Henning Schulzrinne Subject: Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 17:26:32 -0000 --_000_900A1E2059ADB149B905E3C8FA0046A62C77C39220FHDP1LUMXC7V2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dan - The archived Senate hearing is available at the following URL: http://www.commerce.senate.gov/public/index.cfm?p=3DHearings&ContentRecord_= id=3Dc1eec086-3512-4182-ae63-d60e68f4a532 The hearing were about 2 hours long. Ms Greisman and Mr. Bash were the firs= t of the two witness panel. They introduced the issue of Robocalling and ca= ller id spoofing. Nothing more said here that folks on this distro are not = already overly aware. But, perhaps a good high-level summary to the US Sena= te. (I think I spotted Henning sitting just behind Mr. Bash but had only partia= l camera view, so I could be wrong) Senator McCaskill (chair) played/referred to following typical telemarketer= (robocalls): * "This is Rachel from the Card holder services - Calling in refere= nces to your credit card to lower your interest rate..." * "Warning automotive warranty is about to expire, press 1 to speak= to a Rep or press 2 and your file will be removed..." * Reference to the USA Today article on June 9, 2013 on Seniors get= a warning on Medical Alert scam (http://www.usatoday.com/story/money/pers= onalfinance/2013/06/09/scam-medical-alert/2397189/) The second panel included Mr. Rupy from USTA and Mr. Altschul of CTIA. Both= these gentlemen essentially echoed same theme as earlier witnesses, but ad= ded more color, nothing new added...This was then followed by two last witn= esses, Mr. Stein (Primus) and Mr. Foss, who spoke about solution each have= to identify spoofed telemarketer calls. Mr. Stein talked about Telemarketi= ng guard (in short, it supposedly automatically identify suspected frequent= , mass telemarketing calls) and Mr. Foss talked about nomorobo (identifyi= ng caller id + calling pattern) which he had previously presented to FTC an= d won a $50,000 award (FTC Robocall Challenge). Mr. Foss said, he is now wo= rking on the solution to be ready by end of summer.... Lastly, there was of course a mention of "common carriers can do more...." >From the sub-committee website, here are the details on the speakers: Witness Panel 1 Ms. Lois Greisman Associate Director, Division of Marketing Practices Bureau of Consumer Protection, Federal Trade Commission Mr. Eric Bash Associate Bureau Chief, Enforcement Bureau Federal Communications Commission Witness Panel 2 Mr. Kevin G. Rupy Senior Director, Law and Policy United States Telecom Association Mr. Michael F. Altschul Senior Vice President and General Counsel CTIA - The Wireless Association Mr. Matthew Stein Chief Technology Officer Primus Telecommunications Inc. Mr. Aaron Foss Freelance Software Developer Nomorobo Thanks Sanjay From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dan= York Sent: Saturday, July 06, 2013 6:59 AM To: Richard Shockey Cc: stir@ietf.org; Henning Schulzrinne Subject: Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 Will anyone be able to watch this and perhaps post a summary? I will unfor= tunately be in transit (heading to ICANN 47) but would be interested to lea= rn what was said. Dan On Jul 5, 2013, at 12:11 PM, "Richard Shockey" > wrote: Any agenda? Who is testifying ... From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Friday, July 05, 2013 11:44 AM To: stir@ietf.org Subject: [stir] U.S. Senate hearing on robocalls July 10, 2013 http://www.commerce.senate.gov/public/index.cfm?p=3DHearings Stopping Fraudulent Robocall Scams: Can More Be Done? Democratic Press Office - (202) 224-8374 Jul 10 2013 10:00 AM Russell Senate Office Building - 253 _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_900A1E2059ADB149B905E3C8FA0046A62C77C39220FHDP1LUMXC7V2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dan – The archived Senate hearing is available at the f= ollowing URL:

 

ht= tp://www.commerce.senate.gov/public/index.cfm?p=3DHearings&ContentRecor= d_id=3Dc1eec086-3512-4182-ae63-d60e68f4a532

 

The hearing were about 2 h= ours long. Ms Greisman and Mr. Bash were the first of the two witness panel= . They introduced the issue of Robocalling and caller id spoofing. Nothing = more said here that folks on this distro are not already overly aware. But,= perhaps a good high-level summary to the US Senate.

<= p class=3DMsoNormal> <= /p>

(I think I spotted He= nning sitting just behind Mr. Bash but had only partial camera view, so I c= ould be wrong)

 

Senator McCaskill (chair) played/referred to following typi= cal telemarketer (robocalls):

 

· &nb= sp;       “This is Rachel from the Card holder servic= es – Calling in references to your credit card to lower your interest= rate…”

= ·   &nbs= p;     “Warning automotive warranty is about to expire, press 1= to speak to a Rep or press 2 and your file will be removed…”

·       &n= bsp; Reference= to the USA Today article on June 9, 2013 on Seniors get a warning on Medic= al Alert  scam (http://www.usatoday.com/story/money/personalfinance/20= 13/06/09/scam-medical-alert/2397189/)

 

The second panel included Mr. Rupy f= rom USTA and Mr. Altschul of CTIA. Both these gentlemen essentially echoed = same theme as earlier witnesses, but added more color, nothing new added= 230;This was then followed by two last witnesses, Mr. Stein (Primus) and Mr= . Foss,  who spoke about solution each have to identify spoofed telema= rketer calls. Mr. Stein talked about Telemarketing guard (in short, it supp= osedly automatically identify suspected frequent, mass telemarketing calls)=  and Mr. Foss talked about nomor= obo  (identifying caller id + calling pattern) which he had previously= presented to FTC and won a $50,000 award (FTC Robocall Challenge). Mr. Fos= s said, he is now working on the solution to be ready by end of summer̷= 0;.

 

Lastly, there was of course a mention of “common carriers can d= o more….”

 

From the sub-committee website, here are the details= on the speakers:

Witness Panel 1

Ms. Lois Greisman
Associate = Director, Division of Marketing Practices
Bureau of Consumer Protection= , Federal Trade Commission<= /span>

 

Mr. Eric Bash
As= sociate Bureau Chief, Enforcement Bureau
Federal Communications Commiss= ion

 

Witness Panel 2

 

=

Mr. Kevin G. Rupy
Senior Dire= ctor, Law and Policy
United States Telecom Association

 

Mr. Michael F. Al= tschul
Senior Vice President and Genera= l Counsel
CTIA - The Wireless Association

 

<= a href=3D"http://www.commerce.senate.gov/public/index.cfm?p=3DHearings&= ContentRecord_id=3Dc1eec086-3512-4182-ae63-d60e68f4a532&Statement_id=3D= fbe25126-3be7-4654-a03f-3e480c8d7400&ContentType_id=3D14f995b9-dfa5-407= a-9d35-56cc7152a7ed&Group_id=3Db06c39af-e033-4cba-9221-de668ca1978a&= ;MonthDisplay=3D7&YearDisplay=3D2013">Mr. Matthew Stein
Chief Technology Officer
Primus Telecommunications= Inc.

 

Mr. Aaron Foss
Fr= eelance Software Developer
Nomorobo

 

Thanks

Sanjay

=

 =

From: stir-bounces@ietf.org [mailto:st= ir-bounces@ietf.org] On Behalf Of Dan York
Sent: Saturday,= July 06, 2013 6:59 AM
To: Richard Shockey
Cc: stir@iet= f.org; Henning Schulzrinne
Subject: Re: [stir] U.S. Senate hearin= g on robocalls July 10, 2013

 

Will anyone be able = to watch this and perhaps post a summary?  I will unfortunately be in = transit (heading to ICANN 47) but would be interested to learn what was sai= d. 

 

Dan


O= n Jul 5, 2013, at 12:11 PM, "Richard Shockey" <richard@shockey.us> wrote:

Any agenda?  Who is testify= ing …

 

 

http://www.commerce.senate.gov/public/index.cfm?p=3DHearing= s

 

Stopping= Fraudulent Robocall Scams: Can More Be Done?<= /h1>

Democratic Press Office - (202) 224-8374<= /o:p>

Jul = ;10 2= 013 10:00 AM

Russell Senate Office Building - 253<= /span>

 

_______________________________________________
stir mailin= g list
stir@ietf.org
https://www.ietf.org/mailman/li= stinfo/stir

= --_000_900A1E2059ADB149B905E3C8FA0046A62C77C39220FHDP1LUMXC7V2_-- From Henning.Schulzrinne@fcc.gov Wed Jul 10 11: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 E8DF121F9DBC for ; Wed, 10 Jul 2013 11:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=0.673, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKfA0snE868M for ; Wed, 10 Jul 2013 11:02:22 -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 B8D6E21F9D50 for ; Wed, 10 Jul 2013 11:02:21 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "'Mishra, Sanjay'" , Dan York , Richard Shockey Thread-Topic: [stir] U.S. Senate hearing on robocalls July 10, 2013 Thread-Index: Ac55ll2Rp2J08HAPQF6sU8EdWKmeUAAJVyiAACdq6wAA1qmLgAAHLDXQ Date: Wed, 10 Jul 2013 18:01:40 +0000 References: , <007201ce799a$34539360$9cfaba20$@shockey.us> <900A1E2059ADB149B905E3C8FA0046A62C77C39220@FHDP1LUMXC7V23.us.one.verizon.com> In-Reply-To: <900A1E2059ADB149B905E3C8FA0046A62C77C39220@FHDP1LUMXC7V23.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E6A16181E5FD2F46B962315BB05962D01FB72F5Bp2pxmb13fccnetw_" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 18:02:26 -0000 --_000_E6A16181E5FD2F46B962315BB05962D01FB72F5Bp2pxmb13fccnetw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The full testimony, significantly longer than the 5 minute version on video= , is available by clicking on the name of the witness. You will see referen= ces to STIR in both the FCC and FTC testimony. From: Mishra, Sanjay [mailto:sanjay.mishra@verizon.com] Sent: Wednesday, July 10, 2013 1:26 PM To: Dan York; Richard Shockey Cc: stir@ietf.org; Henning Schulzrinne Subject: RE: [stir] U.S. Senate hearing on robocalls July 10, 2013 Dan - The archived Senate hearing is available at the following URL: http://www.commerce.senate.gov/public/index.cfm?p=3DHearings&ContentRecord_= id=3Dc1eec086-3512-4182-ae63-d60e68f4a532 The hearing were about 2 hours long. Ms Greisman and Mr. Bash were the firs= t of the two witness panel. They introduced the issue of Robocalling and ca= ller id spoofing. Nothing more said here that folks on this distro are not = already overly aware. But, perhaps a good high-level summary to the US Sena= te. (I think I spotted Henning sitting just behind Mr. Bash but had only partia= l camera view, so I could be wrong) Senator McCaskill (chair) played/referred to following typical telemarketer= (robocalls): * "This is Rachel from the Card holder services - Calling in refere= nces to your credit card to lower your interest rate..." * "Warning automotive warranty is about to expire, press 1 to speak= to a Rep or press 2 and your file will be removed..." * Reference to the USA Today article on June 9, 2013 on Seniors get= a warning on Medical Alert scam (http://www.usatoday.com/story/money/pers= onalfinance/2013/06/09/scam-medical-alert/2397189/) The second panel included Mr. Rupy from USTA and Mr. Altschul of CTIA. Both= these gentlemen essentially echoed same theme as earlier witnesses, but ad= ded more color, nothing new added...This was then followed by two last witn= esses, Mr. Stein (Primus) and Mr. Foss, who spoke about solution each have= to identify spoofed telemarketer calls. Mr. Stein talked about Telemarketi= ng guard (in short, it supposedly automatically identify suspected frequent= , mass telemarketing calls) and Mr. Foss talked about nomorobo (identifyi= ng caller id + calling pattern) which he had previously presented to FTC an= d won a $50,000 award (FTC Robocall Challenge). Mr. Foss said, he is now wo= rking on the solution to be ready by end of summer.... Lastly, there was of course a mention of "common carriers can do more...." >From the sub-committee website, here are the details on the speakers: Witness Panel 1 Ms. Lois Greisman Associate Director, Division of Marketing Practices Bureau of Consumer Protection, Federal Trade Commission Mr. Eric Bash Associate Bureau Chief, Enforcement Bureau Federal Communications Commission Witness Panel 2 Mr. Kevin G. Rupy Senior Director, Law and Policy United States Telecom Association Mr. Michael F. Altschul Senior Vice President and General Counsel CTIA - The Wireless Association Mr. Matthew Stein Chief Technology Officer Primus Telecommunications Inc. Mr. Aaron Foss Freelance Software Developer Nomorobo Thanks Sanjay From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Dan York Sent: Saturday, July 06, 2013 6:59 AM To: Richard Shockey Cc: stir@ietf.org; Henning Schulzrinne Subject: Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 Will anyone be able to watch this and perhaps post a summary? I will unfor= tunately be in transit (heading to ICANN 47) but would be interested to lea= rn what was said. Dan On Jul 5, 2013, at 12:11 PM, "Richard Shockey" > wrote: Any agenda? Who is testifying ... From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Friday, July 05, 2013 11:44 AM To: stir@ietf.org Subject: [stir] U.S. Senate hearing on robocalls July 10, 2013 http://www.commerce.senate.gov/public/index.cfm?p=3DHearings Stopping Fraudulent Robocall Scams: Can More Be Done? Democratic Press Office - (202) 224-8374 Jul 10 2013 10:00 AM Russell Senate Office Building - 253 _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_E6A16181E5FD2F46B962315BB05962D01FB72F5Bp2pxmb13fccnetw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The full testimony, si= gnificantly longer than the 5 minute version on video, is available by clic= king on the name of the witness. You will see references to STIR in both th= e FCC and FTC testimony.

 

From: Mishra, = Sanjay [mailto:sanjay.mishra@verizon.com]
Sent: Wednesday, July 10, 2013 1:26 PM
To: Dan York; Richard Shockey
Cc: stir@ietf.org; Henning Schulzrinne
Subject: RE: [stir] U.S. Senate hearing on robocalls July 10, 2013

 

Dan – The archiv= ed Senate hearing is available at the following URL:

 

http://www.commerce.senate.gov/public/i= ndex.cfm?p=3DHearings&ContentRecord_id=3Dc1eec086-3512-4182-ae63-d60e68= f4a532

 

The hearing were about= 2 hours long. Ms Greisman and Mr. Bash were the first of the two witness p= anel. They introduced the issue of Robocalling and caller id spoofing. Noth= ing more said here that folks on this distro are not already overly aware. But, perhaps a good high-level summar= y to the US Senate.

 

(I think I spotted Hen= ning sitting just behind Mr. Bash but had only partial camera view, so I co= uld be wrong)

 

Senator McCaskill (cha= ir) played/referred to following typical telemarketer (robocalls):

 

·         “This is= Rachel from the Card holder services – Calling in references to your= credit card to lower your interest rate…”

·         “Warning= automotive warranty is about to expire, press 1 to speak to a Rep or press= 2 and your file will be removed…”

·         Reference to t= he USA Today article on June 9, 2013 on Seniors get a warning on Medical Al= ert  scam (http://www.usatoday.com/story/m= oney/personalfinance/2013/06/09/scam-medical-alert/2397189/)=

 

The second panel inclu= ded Mr. Rupy from USTA and Mr. Altschul of CTIA. Both these gentlemen essen= tially echoed same theme as earlier witnesses, but added more color, nothin= g new added…This was then followed by two last witnesses, Mr. Stein (Primus) and Mr. Foss,  who spoke about= solution each have to identify spoofed telemarketer calls. Mr. Stein talke= d about Telemarketing guard (in short, it supposedly automatically identify= suspected frequent, mass telemarketing calls)  and Mr. Foss talked abou= t nomorobo  (identifying caller id + calling pattern) which he had= previously presented to FTC and won a $50,000 award (FTC Robocall Challeng= e). Mr. Foss said, he is now working on the solution to be ready by end of summer….

 

Lastly, there was of c= ourse a mention of “common carriers can do more….”

 

From the sub-committee= website, here are the details on the speakers:

Witness Panel 1

Ms. Lois Greisman
Associate Director, Division of Marketing Practices
Bureau of Consumer Protection, Federal Trade Commission

 

Mr. Eric Bash
Associate Bureau Chief, Enforcement Bureau
Federal Communications Commission=

 

Witness Pane= l 2

 

Mr. Kevin G. Rupy
Senior Director, Law and Policy
United States Telecom Association=

 

Mr. Michael F. Altschul =
Senior Vice President and General Counsel
CTIA - The Wireless Association

 

Mr. Matthew Stein
Chief Technology Officer
Primus Telecommunications Inc.

 <= /span>

Mr. Aaron Foss
Freelance Software Developer
Nomorobo

 

Thanks

Sanjay

 

From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dan York
Sent: Saturday, July 06, 2013 6:59 AM
To: Richard Shockey
Cc: stir@ietf.org; Henning Schu= lzrinne
Subject: Re: [stir] U.S. Senate hearing on robocalls July 10, 2013

 

Will anyone be able to watch this and perhaps post a= summary?  I will unfortunately be in transit (heading to ICANN 47) bu= t would be interested to learn what was said. 

 

Dan


On Jul 5, 2013, at 12:11 PM, "Richard Shockey" <richard@shockey.us> wrote:

Any agenda?  Who = is testifying …

 

From: stir-bounces@ietf.org [mailt= o:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne
Sent: Friday, July 05, 2013 11:44 AM
To: stir@ietf.org
Subject: [stir] U.S. Senate hearing on robocalls July 10, 2013<= /o:p>

 

http://www.commerce.senate.gov/public/index.cfm?p=3DHe= arings

 

Stopping Fraudulent Robocall Scams: Can More Be Done?<= /h1>

Democratic Press Office - (202) 224-8374=

Jul 10 2013 10:00 AM

Russell Senate Office Building - 253

 

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

--_000_E6A16181E5FD2F46B962315BB05962D01FB72F5Bp2pxmb13fccnetw_-- From richard@shockey.us Wed Jul 10 12:05: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 25F5011E80E1 for ; Wed, 10 Jul 2013 12:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.604 X-Spam-Level: X-Spam-Status: No, score=-101.604 tagged_above=-999 required=5 tests=[AWL=0.660, 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 ikiWJ+cvDPT0 for ; Wed, 10 Jul 2013 12:05:18 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 37A6521F9C15 for ; Wed, 10 Jul 2013 12:05:17 -0700 (PDT) Received: (qmail 12305 invoked by uid 0); 10 Jul 2013 19:04:54 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy9.bluehost.com with SMTP; 10 Jul 2013 19:04: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=WFQG2NMi/eCQ6FrzaEFzUP1zSRlRgDomH4DRVDavA9k=; b=EUrCKcve5GKD2j1YCih+FhZYizkTUVIBNfqrVwN4NT2gqSSA7uNp6SBGg7/z3uczvCVobQLVxXbE8uPsrHjqUmz3f8S7K1tpTWhEL+sl+0oeLpSqWqS68jNgrDG9JmWn; Received: from [72.66.111.124] (port=56206 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Uwzh7-0002t7-5L; Wed, 10 Jul 2013 13:04:53 -0600 From: "Richard Shockey" To: "'Henning Schulzrinne'" , "'Mishra, Sanjay'" , "'Dan York'" References: , <007201ce799a$34539360$9cfaba20$@shockey.us> <900A1E2059ADB149B905E3C8FA0046A62C77C39220@FHDP1LUMXC7V23.us.one.verizon.com> In-Reply-To: Date: Wed, 10 Jul 2013 15:04:46 -0400 Message-ID: <01ad01ce7da0$5af26f00$10d74d00$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01AE_01CE7D7E.D3E98190" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHodzCA9LgCAfhuWd/FCK4mTC0xcwHl+TKPAd+zOkYCZJUWewIb/khJmOge8HA= 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] U.S. Senate hearing on robocalls July 10, 2013 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 19:05:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01AE_01CE7D7E.D3E98190 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Not a bad hearing actually. What was clear to me was STIR is still no silver bullet here. Any reasonable solution has to be a combination of deployable technology and national legislative action. I got the clear sense from Senator McCaskill that if Congress passed legislation permitting the public hanging of RoboCallers and Caller ID spoofers it would pass by unanimous consent. From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Wednesday, July 10, 2013 2:02 PM To: 'Mishra, Sanjay'; Dan York; Richard Shockey Cc: stir@ietf.org Subject: Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 The full testimony, significantly longer than the 5 minute version on video, is available by clicking on the name of the witness. You will see references to STIR in both the FCC and FTC testimony. From: Mishra, Sanjay [mailto:sanjay.mishra@verizon.com] Sent: Wednesday, July 10, 2013 1:26 PM To: Dan York; Richard Shockey Cc: stir@ietf.org ; Henning Schulzrinne Subject: RE: [stir] U.S. Senate hearing on robocalls July 10, 2013 Dan - The archived Senate hearing is available at the following URL: http://www.commerce.senate.gov/public/index.cfm?p=Hearings &ContentRecord_id=c1eec086-3512-4182-ae63-d60e68f4a532 The hearing were about 2 hours long. Ms Greisman and Mr. Bash were the first of the two witness panel. They introduced the issue of Robocalling and caller id spoofing. Nothing more said here that folks on this distro are not already overly aware. But, perhaps a good high-level summary to the US Senate. (I think I spotted Henning sitting just behind Mr. Bash but had only partial camera view, so I could be wrong) Senator McCaskill (chair) played/referred to following typical telemarketer (robocalls): * "This is Rachel from the Card holder services - Calling in references to your credit card to lower your interest rate." * "Warning automotive warranty is about to expire, press 1 to speak to a Rep or press 2 and your file will be removed." * Reference to the USA Today article on June 9, 2013 on Seniors get a warning on Medical Alert scam (http://www.usatoday.com/story/money/personalfinance/2013/06/09/scam-medical -alert/2397189/) The second panel included Mr. Rupy from USTA and Mr. Altschul of CTIA. Both these gentlemen essentially echoed same theme as earlier witnesses, but added more color, nothing new added.This was then followed by two last witnesses, Mr. Stein (Primus) and Mr. Foss, who spoke about solution each have to identify spoofed telemarketer calls. Mr. Stein talked about Telemarketing guard (in short, it supposedly automatically identify suspected frequent, mass telemarketing calls) and Mr. Foss talked about nomorobo (identifying caller id + calling pattern) which he had previously presented to FTC and won a $50,000 award (FTC Robocall Challenge). Mr. Foss said, he is now working on the solution to be ready by end of summer.. Lastly, there was of course a mention of "common carriers can do more.." >From the sub-committee website, here are the details on the speakers: Witness Panel 1 Ms. Lois Greisman Associate Director, Division of Marketing Practices Bureau of Consumer Protection, Federal Trade Commission Mr. Eric Bash Associate Bureau Chief, Enforcement Bureau Federal Communications Commission Witness Panel 2 Mr. Kevin G. Rupy Senior Director, Law and Policy United States Telecom Association Mr. Michael F. Altschul Senior Vice President and General Counsel CTIA - The Wireless Association Mr. Matthew Stein Chief Technology Officer Primus Telecommunications Inc. Mr. Aaron Foss Freelance Software Developer Nomorobo Thanks Sanjay From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dan York Sent: Saturday, July 06, 2013 6:59 AM To: Richard Shockey Cc: stir@ietf.org ; Henning Schulzrinne Subject: Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 Will anyone be able to watch this and perhaps post a summary? I will unfortunately be in transit (heading to ICANN 47) but would be interested to learn what was said. Dan On Jul 5, 2013, at 12:11 PM, "Richard Shockey" > wrote: Any agenda? Who is testifying . From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Friday, July 05, 2013 11:44 AM To: stir@ietf.org Subject: [stir] U.S. Senate hearing on robocalls July 10, 2013 http://www.commerce.senate.gov/public/index.cfm?p=Hearings Stopping Fraudulent Robocall Scams: Can More Be Done? Democratic Press Office - (202) 224-8374 Jul 10 2013 10:00 AM Russell Senate Office Building - 253 _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_01AE_01CE7D7E.D3E98190 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Not a bad hearing = actually.  What was clear to me was STIR is still no silver bullet = here. Any reasonable solution has to be a combination of deployable = technology and national legislative action.

 

I got the clear sense = from Senator McCaskill that if Congress passed legislation permitting = the public hanging of RoboCallers and Caller ID spoofers it would pass = by unanimous consent.

 

From: stir-bounces@ietf.org = [mailto:stir-bounces@ietf.org] On Behalf Of Henning = Schulzrinne
Sent: Wednesday, July 10, 2013 2:02 = PM
To: 'Mishra, Sanjay'; Dan York; Richard = Shockey
Cc: stir@ietf.org
Subject: Re: [stir] U.S. = Senate hearing on robocalls July 10, 2013

 

The full testimony, significantly longer than = the 5 minute version on video, is available by clicking on the name of = the witness. You will see references to STIR in both the FCC and FTC = testimony.

 

From:= = Mishra, Sanjay [mailto:sanjay.mishra@verizon.co= m]
Sent: Wednesday, July 10, 2013 1:26 PM
To: = Dan York; Richard Shockey
Cc: stir@ietf.org; Henning = Schulzrinne
Subject: RE: [stir] U.S. Senate hearing on = robocalls July 10, 2013

 

Dan – The archived Senate hearing is = available at the following URL:

 

http://www.comme= rce.senate.gov/public/index.cfm?p=3DHearings&ContentRecord_id=3Dc1eec= 086-3512-4182-ae63-d60e68f4a532

 

The hearing were about 2 = hours long. Ms Greisman and Mr. Bash were the first of the two witness = panel. They introduced the issue of Robocalling and caller id spoofing. = Nothing more said here that folks on this distro are not already overly = aware. But, perhaps a good high-level summary to the US = Senate.

 

(I think I spotted = Henning sitting just behind Mr. Bash but had only partial camera view, = so I could be wrong)

 

Senator McCaskill = (chair) played/referred to following typical telemarketer = (robocalls):

 

·        = “This = is Rachel from the Card holder services – Calling in references to = your credit card to lower your interest = rate…”

·        = “Warning automotive warranty is about to = expire, press 1 to speak to a Rep or press 2 and your file will be = removed…”

·        = Reference = to the USA Today article on June 9, 2013 on Seniors get a warning on = Medical Alert  scam (http://www.usatoday.com/story/money/personalfi= nance/2013/06/09/scam-medical-alert/2397189/)

 

The second panel = included Mr. Rupy from USTA and Mr. Altschul of CTIA. Both these = gentlemen essentially echoed same theme as earlier witnesses, but added = more color, nothing new added…This was then followed by two last = witnesses, Mr. Stein (Primus) and Mr. Foss,  who spoke about = solution each have to identify spoofed telemarketer calls. Mr. Stein = talked about Telemarketing guard (in short, it supposedly automatically = identify suspected frequent, mass telemarketing calls) =  and Mr. Foss talked about nomorobo =  (identifying caller id + calling pattern) which he had previously = presented to FTC and won a $50,000 award (FTC Robocall Challenge). Mr. = Foss said, he is now working on the solution to be ready by end of = summer….

 

Lastly, there was of = course a mention of “common carriers can do = more….”

 

From the sub-committee = website, here are the details on the speakers:

Witness Panel 1

Ms. Lois Greisman = Associate Director, Division of Marketing Practices
Bureau of = Consumer Protection, Federal Trade Commission

 

Mr. Eric Bash = Associate Bureau Chief, Enforcement Bureau
Federal Communications = Commission

 

Witness Panel 2

=  

Mr. Kevin G. Rupy = Senior Director, Law and Policy
United States Telecom = Association

 

Mr. Michael F. Altschul = Senior Vice President and General Counsel
CTIA - The Wireless = Association

 

Mr. Matthew Stein = Chief Technology Officer
Primus Telecommunications = Inc.

 

Mr. Aaron Foss = Freelance Software Developer
Nomorobo

 

Thanks

Sanjay

 

From:= = stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] = On Behalf Of Dan York
Sent: Saturday, July 06, 2013 = 6:59 AM
To: Richard Shockey
Cc: stir@ietf.org; Henning = Schulzrinne
Subject: Re: [stir] U.S. Senate hearing on = robocalls July 10, 2013

 

Will = anyone be able to watch this and perhaps post a summary?  I will = unfortunately be in transit (heading to ICANN 47) but would be = interested to learn what was said. 

 

Dan


On Jul 5, 2013, at = 12:11 PM, "Richard Shockey" <richard@shockey.us> = wrote:

Any agenda?  Who is = testifying …

 

From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] = On Behalf Of Henning Schulzrinne
Sent: Friday, July 05, = 2013 11:44 AM
To: stir@ietf.org
Subject: = [stir] U.S. Senate hearing on robocalls July 10, = 2013

 

htt= p://www.commerce.senate.gov/public/index.cfm?p=3DHearings<= /p>

 

Stopping Fraudulent Robocall = Scams: Can More Be Done?

Democratic = Press Office - (202) 224-8374

Jul 10 2013 10:00 AM

Russell Senate Office Building - 253

 

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

<= /body> ------=_NextPart_000_01AE_01CE7D7E.D3E98190-- From br@brianrosen.net Wed Jul 10 12:22:57 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA6221F9E6C for ; Wed, 10 Jul 2013 12:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.738 X-Spam-Level: X-Spam-Status: No, score=-99.738 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 nt6fpp7aYmQy for ; Wed, 10 Jul 2013 12:22:50 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 485F721F9E34 for ; Wed, 10 Jul 2013 12:22: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:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=2+nYA+rHeI9hj8Z0x+JrgIMQUkYQOGz472Z4GUqk/Zc=; b=EzuhlhLWrx63pWeZME1qOAKkNTLkwJqurrrI1yGba6U6x6uliFPVecQllhR7Ubwmk0FfrVW5V+1mOA52GEujLpqSUb37x0NGo/CpvvaSQ6tjS2aU/S37mTa8lgDvVnGvb1MebpPZIRams16kfMclPDoReyk82+Tn1qeKNxXfeT0=; Received: from neustargw.va.neustar.com ([209.173.53.233]:48413 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UwzyO-00087k-Ki; Wed, 10 Jul 2013 15:22:44 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_020140F4-3BEA-4CAF-87D8-8EF1DF803D9E" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <01ad01ce7da0$5af26f00$10d74d00$@shockey.us> Date: Wed, 10 Jul 2013 15:22:43 -0400 Message-Id: References: , <007201ce799a$34539360$9cfaba20$@shockey.us> <900A1E2059ADB149B905E3C8FA0046A62C77C39220@FHDP1LUMXC7V23.us.one.verizon.com> <01ad01ce7da0$5af26f00$10d74d00$@shockey.us> To: Richard Shockey 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, 'Dan York' , "'Mishra, Sanjay'" , 'Henning Schulzrinne' Subject: Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 19:22:57 -0000 --Apple-Mail=_020140F4-3BEA-4CAF-87D8-8EF1DF803D9E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Given the direction we're going, it seems that what we need at least = minimally in the U.S. is a reg or interpretation when VoIP interconnect = occurs, the SPs may, at their discretion, refuse to accept calls that = don't have valid source identity. If we eventually got to a regulation that said all such calls MUST have = source identity, that might be better, but many service providers don't = want regulation if they can avoid it. Allowing them to refuse calls = that don't have good identity would get us a long way to our goal. Brian =20 On Jul 10, 2013, at 3:04 PM, Richard Shockey wrote: > =20 > Not a bad hearing actually. What was clear to me was STIR is still no = silver bullet here. Any reasonable solution has to be a combination of = deployable technology and national legislative action. > =20 > I got the clear sense from Senator McCaskill that if Congress passed = legislation permitting the public hanging of RoboCallers and Caller ID = spoofers it would pass by unanimous consent. > =20 > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Henning Schulzrinne > Sent: Wednesday, July 10, 2013 2:02 PM > To: 'Mishra, Sanjay'; Dan York; Richard Shockey > Cc: stir@ietf.org > Subject: Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 > =20 > The full testimony, significantly longer than the 5 minute version on = video, is available by clicking on the name of the witness. You will see = references to STIR in both the FCC and FTC testimony. > =20 > From: Mishra, Sanjay [mailto:sanjay.mishra@verizon.com]=20 > Sent: Wednesday, July 10, 2013 1:26 PM > To: Dan York; Richard Shockey > Cc: stir@ietf.org; Henning Schulzrinne > Subject: RE: [stir] U.S. Senate hearing on robocalls July 10, 2013 > =20 > Dan =96 The archived Senate hearing is available at the following URL: > =20 > = http://www.commerce.senate.gov/public/index.cfm?p=3DHearings&ContentRecord= _id=3Dc1eec086-3512-4182-ae63-d60e68f4a532 > =20 > The hearing were about 2 hours long. Ms Greisman and Mr. Bash were the = first of the two witness panel. They introduced the issue of Robocalling = and caller id spoofing. Nothing more said here that folks on this distro = are not already overly aware. But, perhaps a good high-level summary to = the US Senate. > =20 > (I think I spotted Henning sitting just behind Mr. Bash but had only = partial camera view, so I could be wrong) > =20 > Senator McCaskill (chair) played/referred to following typical = telemarketer (robocalls): > =20 > =B7 =93This is Rachel from the Card holder services =96 Calling = in references to your credit card to lower your interest rate=85=94 > =B7 =93Warning automotive warranty is about to expire, press 1 = to speak to a Rep or press 2 and your file will be removed=85=94 > =B7 Reference to the USA Today article on June 9, 2013 on = Seniors get a warning on Medical Alert scam = (http://www.usatoday.com/story/money/personalfinance/2013/06/09/scam-medic= al-alert/2397189/) > =20 > The second panel included Mr. Rupy from USTA and Mr. Altschul of CTIA. = Both these gentlemen essentially echoed same theme as earlier witnesses, = but added more color, nothing new added=85This was then followed by two = last witnesses, Mr. Stein (Primus) and Mr. Foss, who spoke about = solution each have to identify spoofed telemarketer calls. Mr. Stein = talked about Telemarketing guard (in short, it supposedly automatically = identify suspected frequent, mass telemarketing calls) and Mr. Foss = talked about nomorobo (identifying caller id + calling pattern) which = he had previously presented to FTC and won a $50,000 award (FTC Robocall = Challenge). Mr. Foss said, he is now working on the solution to be ready = by end of summer=85. > =20 > Lastly, there was of course a mention of =93common carriers can do = more=85.=94 > =20 > =46rom the sub-committee website, here are the details on the = speakers: > Witness Panel 1 >=20 > Ms. Lois Greisman=20 > Associate Director, Division of Marketing Practices=20 > Bureau of Consumer Protection, Federal Trade Commission > =20 > Mr. Eric Bash=20 > Associate Bureau Chief, Enforcement Bureau=20 > Federal Communications Commission > =20 > Witness Panel 2 > =20 > Mr. Kevin G. Rupy=20 > Senior Director, Law and Policy=20 > United States Telecom Association > =20 > Mr. Michael F. Altschul=20 > Senior Vice President and General Counsel=20 > CTIA - The Wireless Association > =20 > Mr. Matthew Stein=20 > Chief Technology Officer=20 > Primus Telecommunications Inc. > =20 > Mr. Aaron Foss=20 > Freelance Software Developer=20 > Nomorobo > =20 > Thanks > Sanjay > =20 > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Dan York > Sent: Saturday, July 06, 2013 6:59 AM > To: Richard Shockey > Cc: stir@ietf.org; Henning Schulzrinne > Subject: Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 > =20 > Will anyone be able to watch this and perhaps post a summary? I will = unfortunately be in transit (heading to ICANN 47) but would be = interested to learn what was said.=20 > =20 > Dan >=20 >=20 > On Jul 5, 2013, at 12:11 PM, "Richard Shockey" = wrote: >=20 > Any agenda? Who is testifying =85 > =20 > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Henning Schulzrinne > Sent: Friday, July 05, 2013 11:44 AM > To: stir@ietf.org > Subject: [stir] U.S. Senate hearing on robocalls July 10, 2013 > =20 > http://www.commerce.senate.gov/public/index.cfm?p=3DHearings > =20 > Stopping Fraudulent Robocall Scams: Can More Be Done? > Democratic Press Office - (202) 224-8374 > Jul 10 2013 10:00 AM > Russell Senate Office Building - 253 > =20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_020140F4-3BEA-4CAF-87D8-8EF1DF803D9E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Given the direction we're = going, it seems that what we need at least minimally in the U.S. is a = reg or interpretation when VoIP interconnect occurs, the SPs may, at = their discretion, refuse to accept calls that don't have valid source = identity.

If we eventually got to a regulation that = said all such calls MUST have source identity, that might be better, but = many service providers don't want regulation if they can avoid it. =  Allowing them to refuse calls that don't have good identity would = get us a long way to our = goal.

Brian
 
= On Jul 10, 2013, at 3:04 PM, Richard Shockey <richard@shockey.us> = wrote:

Not a bad hearing actually.  What was clear to me was = STIR is still no silver bullet here. Any reasonable solution has to be a = combination of deployable technology and national legislative = action.
 
I got the clear sense from Senator = McCaskill that if Congress passed legislation permitting the public = hanging of RoboCallers and Caller ID spoofers it would pass by unanimous = consent.
 
From: stir-bounces@ietf.org = [mailto:stir-bounces@ietf.org] On Behalf Of Henning = Schulzrinne
Sent: Wednesday, July 10, 2013 = 2:02 PM
To: 'Mishra, Sanjay'; Dan York; = Richard Shockey
Cc: stir@ietf.org
Subject: Re: [stir] U.S. Senate = hearing on robocalls July 10, 2013
 
The full testimony, significantly = longer than the 5 minute version on video, is available by clicking on = the name of the witness. You will see references to STIR in both the FCC = and FTC testimony.
 
From: Mishra, Sanjay [mailto:sanjay.mishra@verizon.com] 
Sent: Wednesday, July 10, 2013 = 1:26 PM
To: Dan York; Richard = Shockey
Cc: stir@ietf.org; Henning = Schulzrinne
Subject: RE: [stir] U.S. Senate = hearing on robocalls July 10, = 2013
Dan =96 The archived Senate hearing is available at = the following URL:
 
 
The = second panel included Mr. Rupy from USTA and Mr. Altschul of CTIA. Both = these gentlemen essentially echoed same theme as earlier witnesses, but = added more color, nothing new added=85This was then followed by two last = witnesses, Mr. Stein (Primus) and Mr. Foss,  who spoke about = solution each have to identify spoofed telemarketer calls. Mr. Stein = talked about Telemarketing guard (in short, it supposedly automatically = identify suspected frequent, mass telemarketing calls)  and Mr. Foss talked about nomorobo =  (identifying caller id + calling pattern) which he had previously = presented to FTC and won a $50,000 award (FTC Robocall Challenge). Mr. = Foss said, he is now working on the solution to be ready by end of = summer=85.
 
Lastly, = there was of course a mention of =93common carriers can do = more=85.=94
 
=46rom = the sub-committee website, here are the details on the = speakers:

Witness Panel = 1

Ms. Lois Greisman  
Bureau of Consumer = Protection, Federal Trade Commission
 
Mr. Eric Bash  
Federal Communications = Commission 
Witness Panel = 2
Mr. Kevin G. Rupy  
United States Telecom = Association 
Mr. Michael F. Altschul  
CTIA - The Wireless = Association 
Mr. Matthew Stein  
Primus = Telecommunications Inc.
 
Thanks
 
 stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dan = York
Sent: Saturday, July 06, 2013 = 6:59 AM
To: Richard = Shockey
Cc: stir@ietf.org; Henning = Schulzrinne
Subject: Re: [stir] U.S. Senate = hearing on robocalls July 10, = 2013
Will anyone be able = to watch this and perhaps post a summary?  I will unfortunately be = in transit (heading to ICANN 47) but would be interested to learn what = was said. 
Dan


On Jul 5, 2013, at 12:11 PM, "Richard Shockey" <richard@shockey.us> = wrote:

Any agenda?  Who is testifying = =85
 
From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning = Schulzrinne
Sent: Friday, July 05, 2013 11:44 = AM
To: stir@ietf.org
Subject: [stir] U.S. Senate hearing = on robocalls July 10, 2013
 

Stopping Fraudulent Robocall Scams: Can More Be = Done?

Democratic Press Office - (202) = 224-8374

Jul10201310:00 = AM

Russell Senate Office = Building - 253
stir@ietf.org
stir@ietf.org
https://www.ietf.org/ma= ilman/listinfo/stir

= --Apple-Mail=_020140F4-3BEA-4CAF-87D8-8EF1DF803D9E-- From timothy.dwight@verizon.com Wed Jul 10 12:31: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 4E31F21F9E37 for ; Wed, 10 Jul 2013 12:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIDf628Q0QnI for ; Wed, 10 Jul 2013 12:31:01 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id 060F021F9E15 for ; Wed, 10 Jul 2013 12:30:58 -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; 10 Jul 2013 19:30:43 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.87,1037,1363132800"; d="scan'208,217";a="514475434" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi01.verizon.com with ESMTP; 10 Jul 2013 19:30:43 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Wed, 10 Jul 2013 15:30:42 -0400 To: Brian Rosen , Richard Shockey Date: Wed, 10 Jul 2013 15:30:41 -0400 Thread-Topic: [stir] U.S. Senate hearing on robocalls July 10, 2013 Thread-Index: Ac59ovwtMeumw8WeQpGzJ9uDY4+YkwAADEkQ Message-ID: <2B0F677F0B95454297753F58D4A07FA30129012E13@FHDP1LUMXC7V31.us.one.verizon.com> References: , <007201ce799a$34539360$9cfaba20$@shockey.us> <900A1E2059ADB149B905E3C8FA0046A62C77C39220@FHDP1LUMXC7V23.us.one.verizon.com> <01ad01ce7da0$5af26f00$10d74d00$@shockey.us> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2B0F677F0B95454297753F58D4A07FA30129012E13FHDP1LUMXC7V3_" MIME-Version: 1.0 Cc: "stir@ietf.org" , 'Dan York' , "Mishra, Sanjay" , 'Henning Schulzrinne' Subject: Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 19:31:06 -0000 --_000_2B0F677F0B95454297753F58D4A07FA30129012E13FHDP1LUMXC7V3_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Oh if it were only that simple. The volume of calls received today over VoIP peering interfaces, without va= lid source identity, is quite high (it varies, but I've seen it in the doub= le digits, percentage-wise). I assume these are not all robocalls. Most a= re probably legitimate calls between parties who are blissfully unaware tha= t the networks on which they rely, are failing to identify the caller. tim From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Bri= an Rosen Sent: Wednesday, July 10, 2013 2:23 PM To: Richard Shockey Cc: stir@ietf.org; 'Dan York'; Mishra, Sanjay; 'Henning Schulzrinne' Subject: Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 Given the direction we're going, it seems that what we need at least minima= lly in the U.S. is a reg or interpretation when VoIP interconnect occurs, t= he SPs may, at their discretion, refuse to accept calls that don't have val= id source identity. If we eventually got to a regulation that said all such calls MUST have sou= rce identity, that might be better, but many service providers don't want r= egulation if they can avoid it. Allowing them to refuse calls that don't h= ave good identity would get us a long way to our goal. Brian On Jul 10, 2013, at 3:04 PM, Richard Shockey > wrote: Not a bad hearing actually. What was clear to me was STIR is still no silv= er bullet here. Any reasonable solution has to be a combination of deployab= le technology and national legislative action. I got the clear sense from Senator McCaskill that if Congress passed legisl= ation permitting the public hanging of RoboCallers and Caller ID spoofers i= t would pass by unanimous consent. From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Wednesday, July 10, 2013 2:02 PM To: 'Mishra, Sanjay'; Dan York; Richard Shockey Cc: stir@ietf.org Subject: Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 The full testimony, significantly longer than the 5 minute version on video= , is available by clicking on the name of the witness. You will see referen= ces to STIR in both the FCC and FTC testimony. From: Mishra, Sanjay [mailto:sanjay.mishra@verizon.com] Sent: Wednesday, July 10, 2013 1:26 PM To: Dan York; Richard Shockey Cc: stir@ietf.org; Henning Schulzrinne Subject: RE: [stir] U.S. Senate hearing on robocalls July 10, 2013 Dan - The archived Senate hearing is available at the following URL: http://www.commerce.senate.gov/public/index.cfm?p=3DHearings&ContentRecord_= id=3Dc1eec086-3512-4182-ae63-d60e68f4a532 The hearing were about 2 hours long. Ms Greisman and Mr. Bash were the firs= t of the two witness panel. They introduced the issue of Robocalling and ca= ller id spoofing. Nothing more said here that folks on this distro are not = already overly aware. But, perhaps a good high-level summary to the US Sena= te. (I think I spotted Henning sitting just behind Mr. Bash but had only partia= l camera view, so I could be wrong) Senator McCaskill (chair) played/referred to following typical telemarketer= (robocalls): * "This is Rachel from the Card holder services - Calling in referen= ces to your credit card to lower your interest rate..." * "Warning automotive warranty is about to expire, press 1 to speak = to a Rep or press 2 and your file will be removed..." * Reference to the USA Today article on June 9, 2013 on Seniors get = a warning on Medical Alert scam (http://www.usatoday.com/story/money/perso= nalfinance/2013/06/09/scam-medical-alert/2397189/) The second panel included Mr. Rupy from USTA and Mr. Altschul of CTIA. Both= these gentlemen essentially echoed same theme as earlier witnesses, but ad= ded more color, nothing new added...This was then followed by two last witn= esses, Mr. Stein (Primus) and Mr. Foss, who spoke about solution each have= to identify spoofed telemarketer calls. Mr. Stein talked about Telemarketi= ng guard (in short, it supposedly automatically identify suspected frequent= , mass telemarketing calls) and Mr. Foss talked about nomorobo (identifyi= ng caller id + calling pattern) which he had previously presented to FTC an= d won a $50,000 award (FTC Robocall Challenge). Mr. Foss said, he is now wo= rking on the solution to be ready by end of summer.... Lastly, there was of course a mention of "common carriers can do more...." >From the sub-committee website, here are the details on the speakers: Witness Panel 1 Ms. Lois Greisman Associate Director, Division of Marketing Practices Bureau of Consumer Protection, Federal Trade Commission Mr. Eric Bash Associate Bureau Chief, Enforcement Bureau Federal Communications Commission Witness Panel 2 Mr. Kevin G. Rupy Senior Director, Law and Policy United States Telecom Association Mr. Michael F. Altschul Senior Vice President and General Counsel CTIA - The Wireless Association Mr. Matthew Stein Chief Technology Officer Primus Telecommunications Inc. Mr. Aaron Foss Freelance Software Developer Nomorobo Thanks Sanjay From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Dan York Sent: Saturday, July 06, 2013 6:59 AM To: Richard Shockey Cc: stir@ietf.org; Henning Schulzrinne Subject: Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 Will anyone be able to watch this and perhaps post a summary? I will unfor= tunately be in transit (heading to ICANN 47) but would be interested to lea= rn what was said. Dan On Jul 5, 2013, at 12:11 PM, "Richard Shockey" > wrote: Any agenda? Who is testifying ... From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Friday, July 05, 2013 11:44 AM To: stir@ietf.org Subject: [stir] U.S. Senate hearing on robocalls July 10, 2013 http://www.commerce.senate.gov/public/index.cfm?p=3DHearings Stopping Fraudulent Robocall Scams: Can More Be Done? Democratic Press Office - (202) 224-8374 Jul 10 2013 10:00 AM Russell Senate Office Building - 253 _______________________________________________ stir mailing 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_2B0F677F0B95454297753F58D4A07FA30129012E13FHDP1LUMXC7V3_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Oh if it were only that si= mple.

 

The volume of calls received today over VoIP peering interfaces, without= valid source identity, is quite high (it varies, but I’ve seen it in= the double digits, percentage-wise).  I assume these are not all robo= calls.  Most are probably legitimate calls between parties who are bli= ssfully unaware that the networks on which they rely, are failing to identi= fy the caller.

 

=

tim

 

=

From: stir-bounces@ietf.org [mailto:stir-b= ounces@ietf.org] On Behalf Of Brian Rosen
Sent: Wednesday,= July 10, 2013 2:23 PM
To: Richard Shockey
Cc: stir@iet= f.org; 'Dan York'; Mishra, Sanjay; 'Henning Schulzrinne'
Subject:= Re: [stir] U.S. Senate hearing on robocalls July 10, 2013

 

Given the direction we're going, it seems that what we need at least m= inimally in the U.S. is a reg or interpretation when VoIP interconnect occu= rs, the SPs may, at their discretion, refuse to accept calls that don't hav= e valid source identity.

 = ;

If we eventually got to a regula= tion that said all such calls MUST have source identity, that might be bett= er, but many service providers don't want regulation if they can avoid it. =  Allowing them to refuse calls that don't have good identity would get= us a long way to our goal.

<= o:p> 

Brian

 

On Jul 10, 2013, at 3:04 PM, Richard Shockey <richard@shockey.us> wrote:=



 

Not a bad hearing actually.  What was clear to me was STIR is= still no silver bullet here. Any reasonable solution has to be a combinati= on of deployable technology and national legislative action.

 

<= /div>

I got the clear sense from Senator Mc= Caskill that if Congress passed legislation permitting the public hanging o= f RoboCallers and Caller ID spoofers it would pass by unanimous consent.

 =

From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] = On Behalf Of Henning Sc= hulzrinne
Sent: W= ednesday, July 10, 2013 2:02 PM
To: 'Mishra, Sanjay'; Dan York; Richard Shockey
Cc: stir@ietf.org
Subject: Re: [stir] U.S. Senate hearing on robocalls July 10, 2013=

 

The full testimony, sign= ificantly longer than the 5 minute version on video, is available by clicki= ng on the name of the witness. You will see references to STIR in both the = FCC and FTC testimony.

 

From: Mishra, Sanjay [<= a href=3D"mailto:sanjay.mishra@verizon.com">ma= ilto:sanjay.mishra@verizon.com] 
Sent: <= /span>Wednesday, July 10, 2013 1:26 PM
To: Dan York; Richard Shockey
Cc: stir@ietf.org; Henning Schulzrinne
= Subject: RE: [stir] = U.S. Senate hearing on robocalls July 10, 2013

<= /div>

 

Dan – The archived Senate hearing is available = at the following URL:

=  

<= a href=3D"http://www.commerce.senate.gov/public/index.cfm?p=3DHearings&= ContentRecord_id=3Dc1eec086-3512-4182-ae63-d60e68f4a532">http://www.commerce.senate.gov/public/index.cfm?p=3DHearings&= ;ContentRecord_id=3Dc1eec086-3512-4182-ae63-d60e68f4a532<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>

 

The hearing were about 2 hours= long. Ms Greisman and Mr. Bash were the first of the two witness panel. Th= ey introduced the issue of Robocalling and caller id spoofing. Nothing more= said here that folks on this distro are not already overly aware. But, per= haps a good high-level summary to the US Senate.

 

(I think I spotted Henning sitting just behind Mr= . Bash but had only partial camera view, so I could be wrong)

 

=

Senator McCaskill (chair) played/ref= erred to following typical telemarketer (robocalls):

<= /div>

 

&midd= ot;   &= nbsp;    “This is Rachel from the Card holder services – Call= ing in references to your credit card to lower your interest rate…= 221;

·        “Warning automotive war= ranty is about to expire, press 1 to speak to a Rep or press 2 and your fil= e will be removed…”

·     &n= bsp;  Re= ference to the USA Today article on June 9, 2013 on Seniors get a warning o= n Medical Alert  scam (http://www.usatoday.com/story/money/personalfinance/2013/06/09/sc= am-medical-alert/2397189/)

 

The second panel included Mr. Rupy from USTA and Mr. Altschu= l of CTIA. Both these gentlemen essentially echoed same theme as earlier wi= tnesses, but added more color, nothing new added…This was then follow= ed by two last witnesses, Mr. Stein (Primus) and Mr. Foss,  who spoke = about solution each have to identify spoofed telemarketer calls. Mr. Stein = talked about Telemarketing guard (in short, it supposedly automatically ide= ntify suspected frequent, mass telemarketing calls)  and Mr. Foss t= alked about nomorobo  (identifying caller id + calling pattern) which = he had previously presented to FTC and won a $50,000 award (FTC Robocall Ch= allenge). Mr. Foss said, he is now working on the solution to be ready by e= nd of summer….

 

Lastly, there was of course a mention of “common carriers can do= more….”

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

Fr= om the sub-committee website, here are the details on the speakers:<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>

Witness Panel 1

<= div>

Ms. Lois Greisman =
Associate Director, Division of Marketing Practices 
Bureau of Consumer Protection, Fe= deral Trade Commission

 

M= r. Eric Bash 
Associate Bureau Chief= , Enforcement Bureau 
Fe= deral Communications Commission

 

Witness Panel 2

 

Mr. Kevin G. Rupy Senior Director, Law and Policy <= /span>
United States Telecom Association

 

Mr. Michael F. Altschul 
Senior Vice President and General Counsel 
CTIA - The Wireless Association

 

Mr. Matthew Stein 
Chief Technology Officer 
Primus Telecommunications Inc.

 

Mr. Aaron Foss=  
Fr= eelance Software Developer =
Nomorobo

&n= bsp;

Thanks

Sanjay<= /span>

 =

From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dan York
Sent: Saturday, July 06, 2013 6:59 AM
To:<= span class=3Dapple-converted-space> Richard Shockey
Cc: stir@ietf.org; Henning Sch= ulzrinne
Subject: Re: [stir] U.S. Senate hearing on robocalls July 10, 2013

 

Will anyone be able to watch this and perhaps post= a summary?  I will unfortunately be in transit (heading to ICANN 47) = but would be interested to learn what was said. 

=

 

Dan


On Jul 5, 2013= , at 12:11 PM, "Richard Shockey" <richard@shockey.us> wr= ote:

Any agenda?  Who is t= estifying …

 

Fr= om: stir-bounces@ietf.org [mailto:stir-bounces@i= etf.org] On B= ehalf Of Henning Schulz= rinne
Sent: Frida= y, July 05, 2013 11:44 AM
To:=  = stir@ietf.org
Subject: [stir] U.S. Senate hearing on robocalls July 10, 2013=

 

 

St= opping Fraudulent Robocall Scams: Can More Be Done?<= /o:p>

Democratic Press Office - (202) 224-8374=

Jul<= span style=3D'font-size:10.5pt;font-family:"Tahoma","sans-serif";color:#929= B74'> 10&n= bsp;2013 = ;10:00 AM

Russell Senate Office= Building - 253

 

_______________________________= ________________
stir mailing list
<= span style=3D'color:purple'>stir@ietf.org
https://ww= w.ietf.org/mailman/listinfo/stir

_______________________________________________
stir m= ailing list
stir@ietf.org
https://www.ietf.org/mailm= an/listinfo/stir

=  

= --_000_2B0F677F0B95454297753F58D4A07FA30129012E13FHDP1LUMXC7V3_-- From pkyzivat@alum.mit.edu Wed Jul 10 12:41: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 C9DA021F9D98 for ; Wed, 10 Jul 2013 12:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.132 X-Spam-Level: X-Spam-Status: No, score=-0.132 tagged_above=-999 required=5 tests=[AWL=0.305, 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 tdQnEyLGsKt3 for ; Wed, 10 Jul 2013 12:41:05 -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 B76DA21F9D8B for ; Wed, 10 Jul 2013 12:41:04 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta12.westchester.pa.mail.comcast.net with comcast id yhRZ1l0011ap0As5Cjh3Hh; Wed, 10 Jul 2013 19:41:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id yjh31l00u3ZTu2S3ijh3iV; Wed, 10 Jul 2013 19:41:03 +0000 Message-ID: <51DDB8CE.6070704@alum.mit.edu> Date: Wed, 10 Jul 2013 15:41:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: stir@ietf.org References: , <007201ce799a$34539360$9cfaba20$@shockey.us> <900A1E2059ADB149B905E3C8FA0046A62C77C39220@FHDP1LUMXC7V23.us.one.verizon.com> <01ad01ce7da0$5af26f00$10d74d00$@shockey.us> In-Reply-To: <01ad01ce7da0$5af26f00$10d74d00$@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=1373485263; bh=V2lWNMHDIheDXQFymm1XFiBXQuDBr7QaLR3zOaEc/+g=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=AJeTFC79HbejCVhDbkxyaP88j3jvXQnP0N6z6F2HMA57uE64bR2bN3eux1e1Bs3OJ vbrSJ7lau3G51Ip6BuXeY8aAwyR6jvRsh+GXNC7dEUDMo++Hq9BT5UPQWc3+oYk5k9 wkPLVthIf4No00UUugEzwkNd5LpsHEHSA5AxdV7MBaTeMUxAy23Bwh56L29iX/5gTn s7zVp463M91KEdb+alMPoUKCU+3O+uqZzhTrimjYRdn2nuTAVPXQEEVPiiQfazoWJd sXWHHA9LO8UPWFXAsYCdey6m6DkAxCW96tZV0AsX02/JVJDEpE7yU2zjS7uM4b5926 KZvhMCr1ETe0Q== Subject: Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 19:41:11 -0000 On 7/10/13 3:04 PM, Richard Shockey wrote: > I got the clear sense from Senator McCaskill that if Congress passed > legislation permitting the public hanging of RoboCallers and Caller ID > spoofers it would pass by unanimous consent. Let's go for it! From br@brianrosen.net Wed Jul 10 12:41:43 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E3321F9D8D for ; Wed, 10 Jul 2013 12:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.669 X-Spam-Level: X-Spam-Status: No, score=-99.669 tagged_above=-999 required=5 tests=[AWL=-0.629, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 VgUKYpg1JOk5 for ; Wed, 10 Jul 2013 12:41:39 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 2324121F9D8B for ; Wed, 10 Jul 2013 12:41:39 -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=DkPuhTd+Ne8fxEohZYm/Me1kVATUDtrC/SHD4a73Hoc=; b=T9c4J6laRPQxQLIxO8IYn2tSA2xR0YcghPYY82G0LVn3oWMGcSEJeWhyLqkEdgDzz1eOxc6jT7OrOeMAN4o0CptsmBrpDYPUmfKMHHQHFXiT78MW1p8ALD8CIqV4d1KI9Wj9yrdR927igVaPO675x2zt4hrDf9kzLDl6zc8Si4c=; Received: from neustargw.va.neustar.com ([209.173.53.233]:47922 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1Ux0Gf-0006w3-Hb; Wed, 10 Jul 2013 15:41:37 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_46328524-01CB-48CA-999B-4E5CD7363987" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <2B0F677F0B95454297753F58D4A07FA30129012E13@FHDP1LUMXC7V31.us.one.verizon.com> Date: Wed, 10 Jul 2013 15:41:36 -0400 Message-Id: <2D6F0F8F-5694-4225-A222-4159DE644125@brianrosen.net> References: , <007201ce799a$34539360$9cfaba20$@shockey.us> <900A1E2059ADB149B905E3C8FA0046A62C77C39220@FHDP1LUMXC7V23.us.one.verizon.com> <01ad01ce7da0$5af26f00$10d74d00$@shockey.us> <2B0F677F0B95454297753F58D4A07FA30129012E13@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" , 'Henning Schulzrinne' , 'Dan York' , "Mishra, Sanjay" , Richard Shockey Subject: Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 19:41:43 -0000 --Apple-Mail=_46328524-01CB-48CA-999B-4E5CD7363987 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Sure. We have to get deployment going. Suppose it went something like this: We get the standard close to finished We get some early deployment experience that looks good Vendors deliver real code not very long after the RFCs are released. The green vendors deploy in their networks, and everything looks solid. Now, what I think we would like to see is the green carriers telling = their wholesale and interconnect partners that they have a deadline to = deploy what the green carriers have already deployed, and after the = deadline, no more unverifiable calls will be accepted. If even a few of the larger green carriers did it, that would force = nearly uniform deployment, because the recalcitrant SPs need to get to = the consumers served by the the carriers that demand verified source = identity. If most of them did it on somewhat similar time scales, then = there wouldn't even be any shopping of wholesale business by customers = who wanted to avoid deploying. You could even imagine monitoring that had some target percentage of = verified calls from a wholesale customer or peer that tightened over = time. If we're doing what we say we are doing, there won't be any excuse to = not deploy other than spending the $$ to get it done. We're explicitly = covering cases where we have express permission from a number holder to = another entity that entitles that entity to place calls with the = identity of the number holder.=20 That does depend on whatever infrastructure we describe to handle = credentials be deployed as well as SP infrastructure. In some = countries, that may take regulatory work, in others, it might be = agreements among SPs, or both. Brian On Jul 10, 2013, at 3:30 PM, "Dwight, Timothy M \(Tim\)" = wrote: > Oh if it were only that simple. > =20 > The volume of calls received today over VoIP peering interfaces, = without valid source identity, is quite high (it varies, but I=92ve seen = it in the double digits, percentage-wise). I assume these are not all = robocalls. Most are probably legitimate calls between parties who are = blissfully unaware that the networks on which they rely, are failing to = identify the caller. > =20 > tim > =20 > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Brian Rosen > Sent: Wednesday, July 10, 2013 2:23 PM > To: Richard Shockey > Cc: stir@ietf.org; 'Dan York'; Mishra, Sanjay; 'Henning Schulzrinne' > Subject: Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 > =20 > Given the direction we're going, it seems that what we need at least = minimally in the U.S. is a reg or interpretation when VoIP interconnect = occurs, the SPs may, at their discretion, refuse to accept calls that = don't have valid source identity. > =20 > If we eventually got to a regulation that said all such calls MUST = have source identity, that might be better, but many service providers = don't want regulation if they can avoid it. Allowing them to refuse = calls that don't have good identity would get us a long way to our goal. > =20 > Brian > =20 > On Jul 10, 2013, at 3:04 PM, Richard Shockey = wrote: >=20 >=20 > =20 > Not a bad hearing actually. What was clear to me was STIR is still no = silver bullet here. Any reasonable solution has to be a combination of = deployable technology and national legislative action. > =20 > I got the clear sense from Senator McCaskill that if Congress passed = legislation permitting the public hanging of RoboCallers and Caller ID = spoofers it would pass by unanimous consent. > =20 > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Henning Schulzrinne > Sent: Wednesday, July 10, 2013 2:02 PM > To: 'Mishra, Sanjay'; Dan York; Richard Shockey > Cc: stir@ietf.org > Subject: Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 > =20 > The full testimony, significantly longer than the 5 minute version on = video, is available by clicking on the name of the witness. You will see = references to STIR in both the FCC and FTC testimony. > =20 > From: Mishra, Sanjay [mailto:sanjay.mishra@verizon.com]=20 > Sent: Wednesday, July 10, 2013 1:26 PM > To: Dan York; Richard Shockey > Cc: stir@ietf.org; Henning Schulzrinne > Subject: RE: [stir] U.S. Senate hearing on robocalls July 10, 2013 > =20 > Dan =96 The archived Senate hearing is available at the following URL: > =20 > = http://www.commerce.senate.gov/public/index.cfm?p=3DHearings&ContentRecord= _id=3Dc1eec086-3512-4182-ae63-d60e68f4a532 > =20 > The hearing were about 2 hours long. Ms Greisman and Mr. Bash were the = first of the two witness panel. They introduced the issue of Robocalling = and caller id spoofing. Nothing more said here that folks on this distro = are not already overly aware. But, perhaps a good high-level summary to = the US Senate. > =20 > (I think I spotted Henning sitting just behind Mr. Bash but had only = partial camera view, so I could be wrong) > =20 > Senator McCaskill (chair) played/referred to following typical = telemarketer (robocalls): > =20 > =B7 =93This is Rachel from the Card holder services =96 Calling = in references to your credit card to lower your interest rate=85=94 > =B7 =93Warning automotive warranty is about to expire, press 1 = to speak to a Rep or press 2 and your file will be removed=85=94 > =B7 Reference to the USA Today article on June 9, 2013 on = Seniors get a warning on Medical Alert scam = (http://www.usatoday.com/story/money/personalfinance/2013/06/09/scam-medic= al-alert/2397189/) > =20 > The second panel included Mr. Rupy from USTA and Mr. Altschul of CTIA. = Both these gentlemen essentially echoed same theme as earlier witnesses, = but added more color, nothing new added=85This was then followed by two = last witnesses, Mr. Stein (Primus) and Mr. Foss, who spoke about = solution each have to identify spoofed telemarketer calls. Mr. Stein = talked about Telemarketing guard (in short, it supposedly automatically = identify suspected frequent, mass telemarketing calls) and Mr. Foss = talked about nomorobo (identifying caller id + calling pattern) which = he had previously presented to FTC and won a $50,000 award (FTC Robocall = Challenge). Mr. Foss said, he is now working on the solution to be ready = by end of summer=85. > =20 > Lastly, there was of course a mention of =93common carriers can do = more=85.=94 > =20 > =46rom the sub-committee website, here are the details on the = speakers: > Witness Panel 1 >=20 > Ms. Lois Greisman=20 > Associate Director, Division of Marketing Practices=20 > Bureau of Consumer Protection, Federal Trade Commission > =20 > Mr. Eric Bash=20 > Associate Bureau Chief, Enforcement Bureau=20 > Federal Communications Commission > =20 > Witness Panel 2 > =20 > Mr. Kevin G. Rupy=20 > Senior Director, Law and Policy=20 > United States Telecom Association > =20 > Mr. Michael F. Altschul=20 > Senior Vice President and General Counsel=20 > CTIA - The Wireless Association > =20 > Mr. Matthew Stein=20 > Chief Technology Officer=20 > Primus Telecommunications Inc. > =20 > Mr. Aaron Foss=20 > Freelance Software Developer=20 > Nomorobo > =20 > Thanks > Sanjay > =20 > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Dan York > Sent: Saturday, July 06, 2013 6:59 AM > To: Richard Shockey > Cc: stir@ietf.org; Henning Schulzrinne > Subject: Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 > =20 > Will anyone be able to watch this and perhaps post a summary? I will = unfortunately be in transit (heading to ICANN 47) but would be = interested to learn what was said.=20 > =20 > Dan >=20 >=20 > On Jul 5, 2013, at 12:11 PM, "Richard Shockey" = wrote: >=20 > Any agenda? Who is testifying =85 > =20 > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Henning Schulzrinne > Sent: Friday, July 05, 2013 11:44 AM > To: stir@ietf.org > Subject: [stir] U.S. Senate hearing on robocalls July 10, 2013 > =20 > http://www.commerce.senate.gov/public/index.cfm?p=3DHearings > =20 > Stopping Fraudulent Robocall Scams: Can More Be Done? > Democratic Press Office - (202) 224-8374 > Jul 10 2013 10:00 AM > Russell Senate Office Building - 253 > =20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_46328524-01CB-48CA-999B-4E5CD7363987 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Sure.  We have to get = deployment going.

Suppose it went something like = this:
We get the standard close to finished
We get = some early deployment experience that looks good
Vendors = deliver real code not very long after the RFCs are = released.
The green vendors deploy in their networks, and = everything looks solid.

Now, what I think we = would like to see is the green carriers telling their wholesale and = interconnect partners that they have a deadline to deploy what the green = carriers have already deployed, and after the deadline, no more = unverifiable calls will be accepted.

If even a = few of the larger green carriers did it, that would force nearly uniform = deployment, because the recalcitrant SPs need to get to the consumers = served by the the carriers that demand verified source identity. =  If most of them did it on somewhat similar time scales, then there = wouldn't even be any shopping of wholesale business by customers who = wanted to avoid deploying.

You could even = imagine monitoring that had some target percentage of verified calls =  from a wholesale customer or peer that tightened over = time.

If we're doing what we say we are doing, = there won't be any excuse to not deploy other than spending the $$ to = get it done.  We're explicitly covering cases where we have express = permission from a number holder to another entity that entitles that = entity to place calls with the identity of the number = holder. 

That does depend on whatever = infrastructure we describe to handle credentials be deployed as well as = SP infrastructure.  In some countries, that may take regulatory = work, in others, it might be agreements among SPs, or = both.

Brian

On= Jul 10, 2013, at 3:30 PM, "Dwight, Timothy M \(Tim\)" <timothy.dwight@verizon.com&= gt; wrote:

Oh if it were only that = simple.
The volume of calls = received today over VoIP peering interfaces, without valid source = identity, is quite high (it varies, but I=92ve seen it in the double = digits, percentage-wise).  I assume these are not all = robocalls.  Most are probably legitimate calls between parties who = are blissfully unaware that the networks on which they rely, are failing = to identify the caller.
 
From: stir-bounces@ietf.org = [mailto:stir-bounces@ietf.org] On Behalf Of Brian = Rosen
Sent: Wednesday, July 10, 2013 = 2:23 PM
To: Richard = Shockey
Cc: stir@ietf.org; 'Dan York'; Mishra, = Sanjay; 'Henning Schulzrinne'
Subject: Re: [stir] U.S. Senate = hearing on robocalls July 10, = 2013
Given the = direction we're going, it seems that what we need at least minimally in = the U.S. is a reg or interpretation when VoIP interconnect occurs, the = SPs may, at their discretion, refuse to accept calls that don't have = valid source identity.
If = we eventually got to a regulation that said all such calls MUST have = source identity, that might be better, but many service providers don't = want regulation if they can avoid it.  Allowing them to refuse = calls that don't have good identity would get us a long way to our = goal.
richard@shockey.us> = wrote:
 Not a bad hearing actually.  What was = clear to me was STIR is still no silver bullet here. Any reasonable = solution has to be a combination of deployable technology and national = legislative action.
 I got the clear sense from Senator McCaskill = that if Congress passed legislation permitting the public hanging of = RoboCallers and Caller ID spoofers it would pass by unanimous = consent.
 
 [mailto:stir-bounces@ietf.org] On Behalf Of Henning = Schulzrinne
Sent: Wednesday, July 10, 2013 = 2:02 PM
To: 'Mishra, Sanjay'; Dan York; = Richard Shockey
Cc: stir@ietf.org
Subject: Re: [stir] U.S. Senate = hearing on robocalls July 10, = 2013
The full testimony, significantly longer than = the 5 minute version on video, is available by clicking on the name of = the witness. You will see references to STIR in both the FCC and FTC = testimony.

Witness Panel 1Ms. Lois = Greisman 
Associate = Director, Division of Marketing Practices 
Bureau of Consumer = Protection, Federal Trade Commission Mr. Eric = Bash 
Associate = Bureau Chief, Enforcement Bureau 
Federal Communications = Commission

 Witness Panel 2 Mr. Kevin = G. Rupy 
Senior = Director, Law and Policy 
United States Telecom = Association
 Mr. = Michael F. Altschul  
CTIA - The Wireless = Association
 Mr. = Matthew Stein  
Primus = Telecommunications Inc. 
Mr. Aaron = Foss 
Freelance = Software Developer 
Nomorobo ThanksSanjay 
stir-bounces@ietf.org [ On Behalf Of Dan = York
Sent: Saturday, July 06, 2013 = 6:59 AM
To: Richard = Shockey
Cc: stir@ietf.org; = Henning Schulzrinne
Subject: Re: [stir] U.S. Senate = hearing on robocalls July 10, 2013Dan


On Jul 5, 2013, at 12:11 PM, "Richard Shockey" <

Stopping Fraudulent Robocall Scams: Can More Be = Done?
Democratic Press Office - (202) = 224-8374

Jul10201310:00 = AM

Russell = Senate Office Building - 253
_______________________________________________
stir mailing = list
stir@ietf.org
> wrote: > >> Oh if it were only that simple. >> The volume of calls received today over VoIP peering interfaces, >> without valid source identity, is quite high (it varies, but I’ve seen >> it in the double digits, percentage-wise). I assume these are not all >> robocalls. Most are probably legitimate calls between parties who are >> blissfully unaware that the networks on which they rely, are failing >> to identify the caller. >> tim >> *From:*stir-bounces@ietf.org >> [mailto:stir-bounces@ietf.org ]*On Behalf >> Of*Brian Rosen >> *Sent:*Wednesday, July 10, 2013 2:23 PM >> *To:*Richard Shockey >> *Cc:*stir@ietf.org ; 'Dan York'; Mishra, Sanjay; >> 'Henning Schulzrinne' >> *Subject:*Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 >> Given the direction we're going, it seems that what we need at least >> minimally in the U.S. is a reg or interpretation when VoIP >> interconnect occurs, the SPs may, at their discretion, refuse to >> accept calls that don't have valid source identity. >> If we eventually got to a regulation that said all such calls MUST >> have source identity, that might be better, but many service providers >> don't want regulation if they can avoid it. Allowing them to refuse >> calls that don't have good identity would get us a long way to our goal. >> Brian >> On Jul 10, 2013, at 3:04 PM, Richard Shockey > > wrote: >> >> >> Not a bad hearing actually. What was clear to me was STIR is still no >> silver bullet here. Any reasonable solution has to be a combination of >> deployable technology and national legislative action. >> I got the clear sense from Senator McCaskill that if Congress passed >> legislation permitting the public hanging of RoboCallers and Caller ID >> spoofers it would pass by unanimous consent. >> *From:*stir-bounces@ietf.org >> [mailto:stir-bounces@ietf.org >> ]*On Behalf Of*Henning Schulzrinne >> *Sent:*Wednesday, July 10, 2013 2:02 PM >> *To:*'Mishra, Sanjay'; Dan York; Richard Shockey >> *Cc:*stir@ietf.org >> *Subject:*Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 >> The full testimony, significantly longer than the 5 minute version on >> video, is available by clicking on the name of the witness. You will >> see references to STIR in both the FCC and FTC testimony. >> *From:*Mishra, Sanjay [mailto:sanjay.mishra@verizon.com] >> *Sent:*Wednesday, July 10, 2013 1:26 PM >> *To:*Dan York; Richard Shockey >> *Cc:*stir@ietf.org ; Henning Schulzrinne >> *Subject:*RE: [stir] U.S. Senate hearing on robocalls July 10, 2013 >> Dan – The archived Senate hearing is available at the following URL: >> http://www.commerce.senate.gov/public/index.cfm?p=Hearings&ContentRecord_id=c1eec086-3512-4182-ae63-d60e68f4a532 >> The hearing were about 2 hours long. Ms Greisman and Mr. Bash were the >> first of the two witness panel. They introduced the issue of >> Robocalling and caller id spoofing. Nothing more said here that folks >> on this distro are not already overly aware. But, perhaps a good >> high-level summary to the US Senate. >> (I think I spotted Henning sitting just behind Mr. Bash but had only >> partial camera view, so I could be wrong) >> Senator McCaskill (chair) played/referred to following typical >> telemarketer (robocalls): >> ·“This is Rachel from the Card holder services – Calling in references >> to your credit card to lower your interest rate…” >> ·“Warning automotive warranty is about to expire, press 1 to speak to >> a Rep or press 2 and your file will be removed…” >> ·Reference to the USA Today article on June 9, 2013 on Seniors get a >> warning on Medical Alert scam >> (http://www.usatoday.com/story/money/personalfinance/2013/06/09/scam-medical-alert/2397189/) >> The second panel included Mr. Rupy from USTA and Mr. Altschul of CTIA. >> Both these gentlemen essentially echoed same theme as earlier >> witnesses, but added more color, nothing new added…This was then >> followed by two last witnesses, Mr. Stein (Primus) and Mr. Foss, who >> spoke about solution each have to identify spoofed telemarketer calls. >> Mr. Stein talked about Telemarketing guard (in short, it supposedly >> automatically identify suspected frequent, mass telemarketing >> calls)and Mr. Foss talked about nomorobo (identifying caller id + >> calling pattern) which he had previously presented to FTC and won a >> $50,000 award (FTC Robocall Challenge). Mr. Foss said, he is now >> working on the solution to be ready by end of summer…. >> Lastly, there was of course a mention of “common carriers can do more….” >> From the sub-committee website, here are the details on the speakers: >> >> *Witness Panel 1* >> >> *Ms. Lois >> Greisman* >> Associate Director, Division of Marketing Practices >> Bureau of Consumer Protection, Federal Trade Commission >> *Mr. Eric >> Bash* >> Associate Bureau Chief, Enforcement Bureau >> Federal Communications Commission >> *Witness Panel 2* >> ** >> *Mr. Kevin G. >> Rupy* >> Senior Director, Law and Policy >> United States Telecom Association >> *Mr. Michael F. >> Altschul* >> Senior Vice President and General Counsel >> CTIA - The Wireless Association >> *Mr. Matthew >> Stein* >> Chief Technology Officer >> Primus Telecommunications Inc. >> *Mr. Aaron >> Foss* >> Freelance Software Developer >> Nomorobo >> Thanks >> Sanjay >> *From:*stir-bounces@ietf.org >> [mailto:stir-bounces@ietf.org]*On Behalf >> Of*Dan York >> *Sent:*Saturday, July 06, 2013 6:59 AM >> *To:*Richard Shockey >> *Cc:*stir@ietf.org ; Henning Schulzrinne >> *Subject:*Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 >> Will anyone be able to watch this and perhaps post a summary? I will >> unfortunately be in transit (heading to ICANN 47) but would be >> interested to learn what was said. >> >> Dan >> >> >> On Jul 5, 2013, at 12:11 PM, "Richard Shockey" > > wrote: >> >> Any agenda? Who is testifying … >> *From:*stir-bounces@ietf.org >> [mailto:stir-bounces@ietf.org]*On >> Behalf Of*Henning Schulzrinne >> *Sent:*Friday, July 05, 2013 11:44 AM >> *To:*stir@ietf.org >> *Subject:*[stir] U.S. Senate hearing on robocalls July 10, 2013 >> http://www.commerce.senate.gov/public/index.cfm?p=Hearings >> >> >> Stopping Fraudulent Robocall Scams: Can More Be Done? >> >> >> /Democratic Press Office - (202) 224-8374/ >> >> >> Jul10201310:00 AM >> >> Russell Senate Office Building - 253 >> >> _______________________________________________ >> stir mailing 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 Wed Jul 10 13:03:36 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A691121F9E18 for ; Wed, 10 Jul 2013 13:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.11 X-Spam-Level: X-Spam-Status: No, score=-99.11 tagged_above=-999 required=5 tests=[AWL=-1.073, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_23=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_53=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 YBmN4Wp5nyNN for ; Wed, 10 Jul 2013 13:03:32 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 7605F21F9DB7 for ; Wed, 10 Jul 2013 13:03:32 -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=bdwlpMxfe7mHefqHs5lidbXBO3wV2yRa3qcQ8VTbYFw=; b=ijk++FvjO845JXGBd0M5kGlx8fALVn7GdbxDj6SfC6Yyf9h1Ii0T+4n9nEJJjIeFHeBEQkouSMDg144TLHNM6quiF6ezU+3SaK2Kjp3doApmFG9th7QdeHQgt8LiT+eWfG5t7886QAy0H+OAUWdPHQg3G4mVtqoqgZTD33c4RAc=; Received: from neustargw.va.neustar.com ([209.173.53.233]:58265 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1Ux0bq-0006zF-3i; Wed, 10 Jul 2013 16:03:30 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <51DDBC21.40706@alum.mit.edu> Date: Wed, 10 Jul 2013 16:03:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <007201ce799a$34539360$9cfaba20$@shockey.us> <900A1E2059ADB149B905E3C8FA0046A62C77C39220@FHDP1LUMXC7V23.us.one.verizon.com> <01ad01ce7da0$5af26f00$10d74d00$@shockey.us> <2B0F677F0B95454297753F58D4A07FA30129012E13@FHDP1LUMXC7V31.us.one.verizon.com> <2D6F0F8F-5694-4225-A222-4159DE644125@brianrosen.net> <51DDBC21.40706@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] U.S. Senate hearing on robocalls July 10, 2013 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 20:03:36 -0000 Sure. TNSTAFL. I've heard that it might be less trouble than you might think. For = example, I hear the Nigerian regulator really doesn't like his country = being the source of a lot of SPAM, and if we gave them some proven = technology to avoid being the robocall/vishing source, they might just = mandate it PDQ. If you could get the national carrier to deploy, and = start playing the same game with it's domestic partners, it might come = along pretty much the same way. The green carriers could, at a minimum, enforce a believable source = (correct country code for example), even if it was not verified, and = they could start telling their VoIP peering partners that they need to = start deploying, albeit it probably a longer time frame than the = domestic partners. I suspect the problem is going to be that we need the out of band = solution, because we will have lots of PSTN interconnect at the = international level long after it's uncommon in places like North = America. Brian On Jul 10, 2013, at 3:55 PM, Paul Kyzivat wrote: > Brian, >=20 > This sounds plausible in the US. But what about international calls? = It may take some countries a long time to sort this out, and = international calls probably can't be blocked while that happens. Would = some bad-boys be able to find a way to exploit that? >=20 > Thanks, > =09 >=20 > On 7/10/13 3:41 PM, Brian Rosen wrote: >> Sure. We have to get deployment going. >>=20 >> Suppose it went something like this: >> We get the standard close to finished >> We get some early deployment experience that looks good >> Vendors deliver real code not very long after the RFCs are released. >> The green vendors deploy in their networks, and everything looks = solid. >>=20 >> Now, what I think we would like to see is the green carriers telling >> their wholesale and interconnect partners that they have a deadline = to >> deploy what the green carriers have already deployed, and after the >> deadline, no more unverifiable calls will be accepted. >>=20 >> If even a few of the larger green carriers did it, that would force >> nearly uniform deployment, because the recalcitrant SPs need to get = to >> the consumers served by the the carriers that demand verified source >> identity. If most of them did it on somewhat similar time scales, = then >> there wouldn't even be any shopping of wholesale business by = customers >> who wanted to avoid deploying. >>=20 >> You could even imagine monitoring that had some target percentage of >> verified calls from a wholesale customer or peer that tightened over = time. >>=20 >> If we're doing what we say we are doing, there won't be any excuse to >> not deploy other than spending the $$ to get it done. We're = explicitly >> covering cases where we have express permission from a number holder = to >> another entity that entitles that entity to place calls with the >> identity of the number holder. >>=20 >> That does depend on whatever infrastructure we describe to handle >> credentials be deployed as well as SP infrastructure. In some >> countries, that may take regulatory work, in others, it might be >> agreements among SPs, or both. >>=20 >> Brian >>=20 >> On Jul 10, 2013, at 3:30 PM, "Dwight, Timothy M \(Tim\)" >> > = wrote: >>=20 >>> Oh if it were only that simple. >>> The volume of calls received today over VoIP peering interfaces, >>> without valid source identity, is quite high (it varies, but I=92ve = seen >>> it in the double digits, percentage-wise). I assume these are not = all >>> robocalls. Most are probably legitimate calls between parties who = are >>> blissfully unaware that the networks on which they rely, are failing >>> to identify the caller. >>> tim >>> *From:*stir-bounces@ietf.org >>> [mailto:stir-bounces@ietf.org ]*On Behalf >>> Of*Brian Rosen >>> *Sent:*Wednesday, July 10, 2013 2:23 PM >>> *To:*Richard Shockey >>> *Cc:*stir@ietf.org ; 'Dan York'; Mishra, = Sanjay; >>> 'Henning Schulzrinne' >>> *Subject:*Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 >>> Given the direction we're going, it seems that what we need at least >>> minimally in the U.S. is a reg or interpretation when VoIP >>> interconnect occurs, the SPs may, at their discretion, refuse to >>> accept calls that don't have valid source identity. >>> If we eventually got to a regulation that said all such calls MUST >>> have source identity, that might be better, but many service = providers >>> don't want regulation if they can avoid it. Allowing them to refuse >>> calls that don't have good identity would get us a long way to our = goal. >>> Brian >>> On Jul 10, 2013, at 3:04 PM, Richard Shockey >> > wrote: >>>=20 >>>=20 >>> Not a bad hearing actually. What was clear to me was STIR is still = no >>> silver bullet here. Any reasonable solution has to be a combination = of >>> deployable technology and national legislative action. >>> I got the clear sense from Senator McCaskill that if Congress passed >>> legislation permitting the public hanging of RoboCallers and Caller = ID >>> spoofers it would pass by unanimous consent. >>> *From:*stir-bounces@ietf.org >>> [mailto:stir-bounces@ietf.org >>> ]*On Behalf Of*Henning Schulzrinne >>> *Sent:*Wednesday, July 10, 2013 2:02 PM >>> *To:*'Mishra, Sanjay'; Dan York; Richard Shockey >>> *Cc:*stir@ietf.org >>> *Subject:*Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 >>> The full testimony, significantly longer than the 5 minute version = on >>> video, is available by clicking on the name of the witness. You will >>> see references to STIR in both the FCC and FTC testimony. >>> *From:*Mishra, Sanjay [mailto:sanjay.mishra@verizon.com] >>> *Sent:*Wednesday, July 10, 2013 1:26 PM >>> *To:*Dan York; Richard Shockey >>> *Cc:*stir@ietf.org ; Henning Schulzrinne >>> *Subject:*RE: [stir] U.S. Senate hearing on robocalls July 10, 2013 >>> Dan =96 The archived Senate hearing is available at the following = URL: >>> = http://www.commerce.senate.gov/public/index.cfm?p=3DHearings&ContentRecord= _id=3Dc1eec086-3512-4182-ae63-d60e68f4a532 >>> The hearing were about 2 hours long. Ms Greisman and Mr. Bash were = the >>> first of the two witness panel. They introduced the issue of >>> Robocalling and caller id spoofing. Nothing more said here that = folks >>> on this distro are not already overly aware. But, perhaps a good >>> high-level summary to the US Senate. >>> (I think I spotted Henning sitting just behind Mr. Bash but had only >>> partial camera view, so I could be wrong) >>> Senator McCaskill (chair) played/referred to following typical >>> telemarketer (robocalls): >>> =B7=93This is Rachel from the Card holder services =96 Calling in = references >>> to your credit card to lower your interest rate=85=94 >>> =B7=93Warning automotive warranty is about to expire, press 1 to = speak to >>> a Rep or press 2 and your file will be removed=85=94 >>> =B7Reference to the USA Today article on June 9, 2013 on Seniors get = a >>> warning on Medical Alert scam >>> = (http://www.usatoday.com/story/money/personalfinance/2013/06/09/scam-medic= al-alert/2397189/) >>> The second panel included Mr. Rupy from USTA and Mr. Altschul of = CTIA. >>> Both these gentlemen essentially echoed same theme as earlier >>> witnesses, but added more color, nothing new added=85This was then >>> followed by two last witnesses, Mr. Stein (Primus) and Mr. Foss, = who >>> spoke about solution each have to identify spoofed telemarketer = calls. >>> Mr. Stein talked about Telemarketing guard (in short, it supposedly >>> automatically identify suspected frequent, mass telemarketing >>> calls)and Mr. Foss talked about nomorobo (identifying caller id + >>> calling pattern) which he had previously presented to FTC and won a >>> $50,000 award (FTC Robocall Challenge). Mr. Foss said, he is now >>> working on the solution to be ready by end of summer=85. >>> Lastly, there was of course a mention of =93common carriers can do = more=85.=94 >>> =46rom the sub-committee website, here are the details on the = speakers: >>>=20 >>> *Witness Panel 1* >>>=20 >>> *Ms. Lois >>> = Greisman* >>> Associate Director, Division of Marketing Practices >>> Bureau of Consumer Protection, Federal Trade Commission >>> *Mr. Eric >>> = Bash* >>> Associate Bureau Chief, Enforcement Bureau >>> Federal Communications Commission >>> *Witness Panel 2* >>> ** >>> *Mr. Kevin G. >>> = Rupy* >>> Senior Director, Law and Policy >>> United States Telecom Association >>> *Mr. Michael F. >>> = Altschul* >>> Senior Vice President and General Counsel >>> CTIA - The Wireless Association >>> *Mr. Matthew >>> = Stein* >>> Chief Technology Officer >>> Primus Telecommunications Inc. >>> *Mr. Aaron >>> = Foss* >>> Freelance Software Developer >>> Nomorobo >>> Thanks >>> Sanjay >>> *From:*stir-bounces@ietf.org >>> [mailto:stir-bounces@ietf.org]*On = Behalf >>> Of*Dan York >>> *Sent:*Saturday, July 06, 2013 6:59 AM >>> *To:*Richard Shockey >>> *Cc:*stir@ietf.org ; Henning Schulzrinne >>> *Subject:*Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 >>> Will anyone be able to watch this and perhaps post a summary? I = will >>> unfortunately be in transit (heading to ICANN 47) but would be >>> interested to learn what was said. >>>=20 >>> Dan >>>=20 >>>=20 >>> On Jul 5, 2013, at 12:11 PM, "Richard Shockey" >> > wrote: >>>=20 >>> Any agenda? Who is testifying =85 >>> *From:*stir-bounces@ietf.org >>> [mailto:stir-bounces@ietf.org]*On >>> Behalf Of*Henning Schulzrinne >>> *Sent:*Friday, July 05, 2013 11:44 AM >>> *To:*stir@ietf.org >>> *Subject:*[stir] U.S. Senate hearing on robocalls July 10, 2013 >>> http://www.commerce.senate.gov/public/index.cfm?p=3DHearings >>>=20 >>>=20 >>> Stopping Fraudulent Robocall Scams: Can More Be Done? >>> = >>>=20 >>> /Democratic Press Office - (202) 224-8374/ >>>=20 >>>=20 >>> Jul10201310:00 AM >>>=20 >>> Russell Senate Office Building - 253 >>>=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 >> _______________________________________________ >> 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 Henning.Schulzrinne@fcc.gov Wed Jul 10 13:07: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 7429921F9A7E for ; Wed, 10 Jul 2013 13:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.751 X-Spam-Level: X-Spam-Status: No, score=-0.751 tagged_above=-999 required=5 tests=[AWL=-0.552, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_53=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 Ur8XM0HqoP8d for ; Wed, 10 Jul 2013 13:07:13 -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 8ACA221F9E8B for ; Wed, 10 Jul 2013 13:07:13 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Paul Kyzivat' , "stir@ietf.org" Thread-Topic: [stir] U.S. Senate hearing on robocalls July 10, 2013 Thread-Index: Ac55ll2Rp2J08HAPQF6sU8EdWKmeUAAJVyiAACdq6wAA1qmLgAAHLDXQ///iQwCAAAUEgIAAAjqAgAADDQCAAAPOgIAAQHNA Date: Wed, 10 Jul 2013 20:07:12 +0000 References: , <007201ce799a$34539360$9cfaba20$@shockey.us> <900A1E2059ADB149B905E3C8FA0046A62C77C39220@FHDP1LUMXC7V23.us.one.verizon.com> <01ad01ce7da0$5af26f00$10d74d00$@shockey.us> <2B0F677F0B95454297753F58D4A07FA30129012E13@FHDP1LUMXC7V31.us.one.verizon.com> <2D6F0F8F-5694-4225-A222-4159DE644125@brianrosen.net> <51DDBC21.40706@alum.mit.edu> In-Reply-To: <51DDBC21.40706@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] U.S. Senate hearing on robocalls July 10, 2013 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 20:07:17 -0000 There are two kinds of international calls: (1) with a US "From" / caller ID, but originated outside the US, including = both robocallers and legitimate call centers (2) with an international callerID I think the second category is self-limiting (people would probably be hap= py to just block such calls, given that most people receive very few legit = international calls or only from very specific numbers, such as friends and= family) and the first would seem to be subject to the same considerations = as domestic calls. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Pau= l Kyzivat Sent: Wednesday, July 10, 2013 3:55 PM To: stir@ietf.org Subject: Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 Brian, This sounds plausible in the US. But what about international calls? It may= take some countries a long time to sort this out, and international calls = probably can't be blocked while that happens. Would some bad-boys be able t= o find a way to exploit that? Thanks, =09 On 7/10/13 3:41 PM, Brian Rosen wrote: > Sure. We have to get deployment going. > > Suppose it went something like this: > We get the standard close to finished > We get some early deployment experience that looks good Vendors=20 > deliver real code not very long after the RFCs are released. > The green vendors deploy in their networks, and everything looks solid. > > Now, what I think we would like to see is the green carriers telling=20 > their wholesale and interconnect partners that they have a deadline to=20 > deploy what the green carriers have already deployed, and after the=20 > deadline, no more unverifiable calls will be accepted. > > If even a few of the larger green carriers did it, that would force=20 > nearly uniform deployment, because the recalcitrant SPs need to get to=20 > the consumers served by the the carriers that demand verified source=20 > identity. If most of them did it on somewhat similar time scales,=20 > then there wouldn't even be any shopping of wholesale business by=20 > customers who wanted to avoid deploying. > > You could even imagine monitoring that had some target percentage of=20 > verified calls from a wholesale customer or peer that tightened over tim= e. > > If we're doing what we say we are doing, there won't be any excuse to=20 > not deploy other than spending the $$ to get it done. We're=20 > explicitly covering cases where we have express permission from a=20 > number holder to another entity that entitles that entity to place=20 > calls with the identity of the number holder. > > That does depend on whatever infrastructure we describe to handle=20 > credentials be deployed as well as SP infrastructure. In some=20 > countries, that may take regulatory work, in others, it might be=20 > agreements among SPs, or both. > > Brian > > On Jul 10, 2013, at 3:30 PM, "Dwight, Timothy M \(Tim\)" > > wrote: > >> Oh if it were only that simple. >> The volume of calls received today over VoIP peering interfaces,=20 >> without valid source identity, is quite high (it varies, but I've=20 >> seen it in the double digits, percentage-wise). I assume these are=20 >> not all robocalls. Most are probably legitimate calls between=20 >> parties who are blissfully unaware that the networks on which they=20 >> rely, are failing to identify the caller. >> tim >> *From:*stir-bounces@ietf.org =20 >> [mailto:stir-bounces@ietf.org ]*On Behalf=20 >> Of*Brian Rosen *Sent:*Wednesday, July 10, 2013 2:23 PM *To:*Richard=20 >> Shockey *Cc:*stir@ietf.org ; 'Dan York';=20 >> Mishra, Sanjay; 'Henning Schulzrinne' >> *Subject:*Re: [stir] U.S. Senate hearing on robocalls July 10, 2013=20 >> Given the direction we're going, it seems that what we need at least=20 >> minimally in the U.S. is a reg or interpretation when VoIP=20 >> interconnect occurs, the SPs may, at their discretion, refuse to=20 >> accept calls that don't have valid source identity. >> If we eventually got to a regulation that said all such calls MUST=20 >> have source identity, that might be better, but many service=20 >> providers don't want regulation if they can avoid it. Allowing them=20 >> to refuse calls that don't have good identity would get us a long way to= our goal. >> Brian >> On Jul 10, 2013, at 3:04 PM, Richard Shockey > > wrote: >> >> >> Not a bad hearing actually. What was clear to me was STIR is still=20 >> no silver bullet here. Any reasonable solution has to be a=20 >> combination of deployable technology and national legislative action. >> I got the clear sense from Senator McCaskill that if Congress passed=20 >> legislation permitting the public hanging of RoboCallers and Caller=20 >> ID spoofers it would pass by unanimous consent. >> *From:*stir-bounces@ietf.org >> [mailto:stir-bounces@ietf.org >> ]*On Behalf Of*Henning Schulzrinne=20 >> *Sent:*Wednesday, July 10, 2013 2:02 PM *To:*'Mishra, Sanjay'; Dan=20 >> York; Richard Shockey *Cc:*stir@ietf.org >> *Subject:*Re: [stir] U.S. Senate hearing on robocalls July 10, 2013=20 >> The full testimony, significantly longer than the 5 minute version on=20 >> video, is available by clicking on the name of the witness. You will=20 >> see references to STIR in both the FCC and FTC testimony. >> *From:*Mishra, Sanjay [mailto:sanjay.mishra@verizon.com] >> *Sent:*Wednesday, July 10, 2013 1:26 PM *To:*Dan York; Richard=20 >> Shockey *Cc:*stir@ietf.org ; Henning=20 >> Schulzrinne >> *Subject:*RE: [stir] U.S. Senate hearing on robocalls July 10, 2013=20 >> Dan - The archived Senate hearing is available at the following URL: >> http://www.commerce.senate.gov/public/index.cfm?p=3DHearings&ContentRec >> ord_id=3Dc1eec086-3512-4182-ae63-d60e68f4a532 >> The hearing were about 2 hours long. Ms Greisman and Mr. Bash were=20 >> the first of the two witness panel. They introduced the issue of=20 >> Robocalling and caller id spoofing. Nothing more said here that folks=20 >> on this distro are not already overly aware. But, perhaps a good=20 >> high-level summary to the US Senate. >> (I think I spotted Henning sitting just behind Mr. Bash but had only=20 >> partial camera view, so I could be wrong) Senator McCaskill (chair)=20 >> played/referred to following typical telemarketer (robocalls): >> *"This is Rachel from the Card holder services - Calling in=20 >> references to your credit card to lower your interest rate..." >> *"Warning automotive warranty is about to expire, press 1 to speak to=20 >> a Rep or press 2 and your file will be removed..." >> *Reference to the USA Today article on June 9, 2013 on Seniors get a=20 >> warning on Medical Alert scam >> (http://www.usatoday.com/story/money/personalfinance/2013/06/09/scam- >> medical-alert/2397189/) The second panel included Mr. Rupy from USTA=20 >> and Mr. Altschul of CTIA. >> Both these gentlemen essentially echoed same theme as earlier=20 >> witnesses, but added more color, nothing new added...This was then=20 >> followed by two last witnesses, Mr. Stein (Primus) and Mr. Foss, who=20 >> spoke about solution each have to identify spoofed telemarketer calls. >> Mr. Stein talked about Telemarketing guard (in short, it supposedly=20 >> automatically identify suspected frequent, mass telemarketing=20 >> calls)and Mr. Foss talked about nomorobo (identifying caller id +=20 >> calling pattern) which he had previously presented to FTC and won a >> $50,000 award (FTC Robocall Challenge). Mr. Foss said, he is now=20 >> working on the solution to be ready by end of summer.... >> Lastly, there was of course a mention of "common carriers can do more...= ." >> From the sub-committee website, here are the details on the speakers: >> >> *Witness Panel 1* >> >> *Ms. Lois >> Greisman> ontentRecord_id=3Dc1eec086-3512-4182-ae63-d60e68f4a532&Statement_id=3D62= e >> 2fdd3-2cc6-4fca-ab16-f1978019cd48&ContentType_id=3D14f995b9-dfa5-407a-9 >> d35-56cc7152a7ed&Group_id=3Db06c39af-e033-4cba-9221-de668ca1978a&MonthD >> isplay=3D7&YearDisplay=3D2013>* Associate Director, Division of Marketin= g=20 >> Practices Bureau of Consumer Protection, Federal Trade Commission=20 >> *Mr. Eric >> Bash> ntRecord_id=3Dc1eec086-3512-4182-ae63-d60e68f4a532&Statement_id=3D672a55= e >> 7-b30a-469f-8eea-3a9aa02ffaa4&ContentType_id=3D14f995b9-dfa5-407a-9d35- >> 56cc7152a7ed&Group_id=3Db06c39af-e033-4cba-9221-de668ca1978a&MonthDispl >> ay=3D7&YearDisplay=3D2013>* Associate Bureau Chief, Enforcement Bureau=20 >> Federal Communications Commission *Witness Panel 2* >> ** >> *Mr. Kevin G. >> Rupy> ntRecord_id=3Dc1eec086-3512-4182-ae63-d60e68f4a532&Statement_id=3D2f8df0= 5 >> 4-d7ef-40e6-868c-f37733d6fefc&ContentType_id=3D14f995b9-dfa5-407a-9d35- >> 56cc7152a7ed&Group_id=3Db06c39af-e033-4cba-9221-de668ca1978a&MonthDispl >> ay=3D7&YearDisplay=3D2013>* >> Senior Director, Law and Policy >> United States Telecom Association >> *Mr. Michael F. >> Altschul> ontentRecord_id=3Dc1eec086-3512-4182-ae63-d60e68f4a532&Statement_id=3D89= f >> 31c54-0939-4e99-bf5b-34ce10fff8b1&ContentType_id=3D14f995b9-dfa5-407a-9 >> d35-56cc7152a7ed&Group_id=3Db06c39af-e033-4cba-9221-de668ca1978a&MonthD >> isplay=3D7&YearDisplay=3D2013>* Senior Vice President and General Counse= l=20 >> CTIA - The Wireless Association *Mr. Matthew >> Stein> entRecord_id=3Dc1eec086-3512-4182-ae63-d60e68f4a532&Statement_id=3Dfbe25= 1 >> 26-3be7-4654-a03f-3e480c8d7400&ContentType_id=3D14f995b9-dfa5-407a-9d35 >> -56cc7152a7ed&Group_id=3Db06c39af-e033-4cba-9221-de668ca1978a&MonthDisp >> lay=3D7&YearDisplay=3D2013>* >> Chief Technology Officer >> Primus Telecommunications Inc. >> *Mr. Aaron >> Foss> ntRecord_id=3Dc1eec086-3512-4182-ae63-d60e68f4a532&Statement_id=3D65a498= c >> 3-0ad9-4b3d-8b1c-915245e73719&ContentType_id=3D14f995b9-dfa5-407a-9d35- >> 56cc7152a7ed&Group_id=3Db06c39af-e033-4cba-9221-de668ca1978a&MonthDispl >> ay=3D7&YearDisplay=3D2013>* >> Freelance Software Developer >> Nomorobo >> Thanks >> Sanjay >> *From:*stir-bounces@ietf.org >> [mailto:stir-bounces@ietf.org]*On=20 >> Behalf Of*Dan York *Sent:*Saturday, July 06, 2013 6:59 AM=20 >> *To:*Richard Shockey *Cc:*stir@ietf.org ;=20 >> Henning Schulzrinne >> *Subject:*Re: [stir] U.S. Senate hearing on robocalls July 10, 2013=20 >> Will anyone be able to watch this and perhaps post a summary? I will=20 >> unfortunately be in transit (heading to ICANN 47) but would be=20 >> interested to learn what was said. >> >> Dan >> >> >> On Jul 5, 2013, at 12:11 PM, "Richard Shockey" > > wrote: >> >> Any agenda? Who is testifying ... >> *From:*stir-bounces@ietf.org >> [mailto:stir-bounces@ietf.org]*On >> Behalf Of*Henning Schulzrinne >> *Sent:*Friday, July 05, 2013 11:44 AM >> *To:*stir@ietf.org >> *Subject:*[stir] U.S. Senate hearing on robocalls July 10, 2013 >> http://www.commerce.senate.gov/public/index.cfm?p=3DHearings >> >> >> Stopping Fraudulent Robocall Scams: Can More Be Done? >> =20 >> > cord_id=3Dc1eec086-3512-4182-ae63-d60e68f4a532&ContentType_id=3D14f995b9= - >> dfa5-407a-9d35-56cc7152a7ed&Group_id=3Db06c39af-e033-4cba-9221-de668ca1 >> 978a&MonthDisplay=3D7&YearDisplay=3D2013> >> >> /Democratic Press Office - (202) 224-8374/ >> >> >> Jul10201310:00 AM >> >> Russell Senate Office Building - 253 >> >> _______________________________________________ >> stir mailing 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 Wed Jul 10 21:53: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 A713221F9CB3 for ; Wed, 10 Jul 2013 21:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.807 X-Spam-Level: X-Spam-Status: No, score=-5.807 tagged_above=-999 required=5 tests=[AWL=-0.605, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMoVLG-dhvgj for ; Wed, 10 Jul 2013 21:53:17 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE2921F922A for ; Wed, 10 Jul 2013 21:53:16 -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 r6B4rAXm027051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Jul 2013 04:53:12 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 r6B4r1i5004577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jul 2013 04:53:02 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 r6B4r1B8018429; Thu, 11 Jul 2013 04:53:01 GMT Received: from [192.168.2.80] (/184.74.74.115) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 10 Jul 2013 21:53:00 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_2D749301-4DD9-4F47-9CB4-9C5F26FAD523" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <01ad01ce7da0$5af26f00$10d74d00$@shockey.us> Date: Thu, 11 Jul 2013 00:52:59 -0400 Message-Id: <52705969-970E-431A-9A9B-B24AAF69C082@oracle.com> References: , <007201ce799a$34539360$9cfaba20$@shockey.us> <900A1E2059ADB149B905E3C8FA0046A62C77C39220@FHDP1LUMXC7V23.us.one.verizon.com> <01ad01ce7da0$5af26f00$10d74d00$@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, 'Dan York' , "'Mishra, Sanjay'" , 'Henning Schulzrinne' Subject: Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 04:53:22 -0000 --Apple-Mail=_2D749301-4DD9-4F47-9CB4-9C5F26FAD523 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Yeah, I was impressed by some of the testimony from the speakers and Q&A = from the Senators. It's unfortunate they spent so much time on the Primus TeleGuard service = and portrayed it as some form of silver bullet to the problem, when it = only solves specific forms of robocalls, and even then only after = there's sufficient negative feedback from people who were already = called. Mr. Altschul's response to it was more accurate and poignant = than the people there seemed to realize as well, including for the = American Airlines scenario. Plus my hunch is Canadian carriers happen = to have a more easily identifiable call origin model right now, and thus = its more easily defendable currently. Regardless, none of the robocall-blocking tactics I've seen will do much = in the long run unless we get the caller-id's to at least be = authenticate-able. Once we know the caller-ids can't be randomly = generated or spoof legitimate sources, doing whitelist/blacklist things = will be a lot more tenable. -hadriel On Jul 10, 2013, at 3:04 PM, Richard Shockey wrote: > =20 > Not a bad hearing actually. What was clear to me was STIR is still no = silver bullet here. Any reasonable solution has to be a combination of = deployable technology and national legislative action. > =20 > I got the clear sense from Senator McCaskill that if Congress passed = legislation permitting the public hanging of RoboCallers and Caller ID = spoofers it would pass by unanimous consent. > =20 > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Henning Schulzrinne > Sent: Wednesday, July 10, 2013 2:02 PM > To: 'Mishra, Sanjay'; Dan York; Richard Shockey > Cc: stir@ietf.org > Subject: Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 > =20 > The full testimony, significantly longer than the 5 minute version on = video, is available by clicking on the name of the witness. You will see = references to STIR in both the FCC and FTC testimony. > =20 > From: Mishra, Sanjay [mailto:sanjay.mishra@verizon.com]=20 > Sent: Wednesday, July 10, 2013 1:26 PM > To: Dan York; Richard Shockey > Cc: stir@ietf.org; Henning Schulzrinne > Subject: RE: [stir] U.S. Senate hearing on robocalls July 10, 2013 > =20 > Dan =96 The archived Senate hearing is available at the following URL: > =20 > = http://www.commerce.senate.gov/public/index.cfm?p=3DHearings&ContentRecord= _id=3Dc1eec086-3512-4182-ae63-d60e68f4a532 > =20 > The hearing were about 2 hours long. Ms Greisman and Mr. Bash were the = first of the two witness panel. They introduced the issue of Robocalling = and caller id spoofing. Nothing more said here that folks on this distro = are not already overly aware. But, perhaps a good high-level summary to = the US Senate. > =20 > (I think I spotted Henning sitting just behind Mr. Bash but had only = partial camera view, so I could be wrong) > =20 > Senator McCaskill (chair) played/referred to following typical = telemarketer (robocalls): > =20 > =B7 =93This is Rachel from the Card holder services =96 Calling = in references to your credit card to lower your interest rate=85=94 > =B7 =93Warning automotive warranty is about to expire, press 1 = to speak to a Rep or press 2 and your file will be removed=85=94 > =B7 Reference to the USA Today article on June 9, 2013 on = Seniors get a warning on Medical Alert scam = (http://www.usatoday.com/story/money/personalfinance/2013/06/09/scam-medic= al-alert/2397189/) > =20 > The second panel included Mr. Rupy from USTA and Mr. Altschul of CTIA. = Both these gentlemen essentially echoed same theme as earlier witnesses, = but added more color, nothing new added=85This was then followed by two = last witnesses, Mr. Stein (Primus) and Mr. Foss, who spoke about = solution each have to identify spoofed telemarketer calls. Mr. Stein = talked about Telemarketing guard (in short, it supposedly automatically = identify suspected frequent, mass telemarketing calls) and Mr. Foss = talked about nomorobo (identifying caller id + calling pattern) which = he had previously presented to FTC and won a $50,000 award (FTC Robocall = Challenge). Mr. Foss said, he is now working on the solution to be ready = by end of summer=85. > =20 > Lastly, there was of course a mention of =93common carriers can do = more=85.=94 > =20 > =46rom the sub-committee website, here are the details on the = speakers: > Witness Panel 1 >=20 > Ms. Lois Greisman=20 > Associate Director, Division of Marketing Practices=20 > Bureau of Consumer Protection, Federal Trade Commission > =20 > Mr. Eric Bash=20 > Associate Bureau Chief, Enforcement Bureau=20 > Federal Communications Commission > =20 > Witness Panel 2 > =20 > Mr. Kevin G. Rupy=20 > Senior Director, Law and Policy=20 > United States Telecom Association > =20 > Mr. Michael F. Altschul=20 > Senior Vice President and General Counsel=20 > CTIA - The Wireless Association > =20 > Mr. Matthew Stein=20 > Chief Technology Officer=20 > Primus Telecommunications Inc. > =20 > Mr. Aaron Foss=20 > Freelance Software Developer=20 > Nomorobo > =20 > Thanks > Sanjay > =20 > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Dan York > Sent: Saturday, July 06, 2013 6:59 AM > To: Richard Shockey > Cc: stir@ietf.org; Henning Schulzrinne > Subject: Re: [stir] U.S. Senate hearing on robocalls July 10, 2013 > =20 > Will anyone be able to watch this and perhaps post a summary? I will = unfortunately be in transit (heading to ICANN 47) but would be = interested to learn what was said.=20 > =20 > Dan >=20 >=20 > On Jul 5, 2013, at 12:11 PM, "Richard Shockey" = wrote: >=20 > Any agenda? Who is testifying =85 > =20 > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Henning Schulzrinne > Sent: Friday, July 05, 2013 11:44 AM > To: stir@ietf.org > Subject: [stir] U.S. Senate hearing on robocalls July 10, 2013 > =20 > http://www.commerce.senate.gov/public/index.cfm?p=3DHearings > =20 > Stopping Fraudulent Robocall Scams: Can More Be Done? > Democratic Press Office - (202) 224-8374 > Jul 10 2013 10:00 AM > Russell Senate Office Building - 253 > =20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_2D749301-4DD9-4F47-9CB4-9C5F26FAD523 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Yeah, I was = impressed by some of the testimony from the speakers and Q&A from = the Senators.

It's unfortunate they spent so = much time on the Primus TeleGuard service and portrayed it as some form = of silver bullet to the problem, when it only solves specific forms of = robocalls, and even then only after there's sufficient negative feedback = from people who were already called.  Mr. Altschul's response to it = was more accurate and poignant than the people there seemed to realize = as well, including for the American Airlines scenario.  Plus my = hunch is Canadian carriers happen to have a more easily identifiable = call origin model right now, and thus its more easily defendable = currently.

Regardless, none of the = robocall-blocking tactics I've seen will do much in the long run unless = we get the caller-id's to at least be authenticate-able.  Once we = know the caller-ids can't be randomly generated or spoof legitimate = sources, doing whitelist/blacklist things will be a lot more = tenable.

-hadriel


Not a bad hearing actually.  What was clear to me was = STIR is still no silver bullet here. Any reasonable solution has to be a = combination of deployable technology and national legislative = action.
 
I got the clear sense from Senator = McCaskill that if Congress passed legislation permitting the public = hanging of RoboCallers and Caller ID spoofers it would pass by unanimous = consent.
 
From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning = Schulzrinne
Sent: Wednesday, July 10, 2013 = 2:02 PM
To: 'Mishra, Sanjay'; Dan York; = Richard Shockey
Cc: stir@ietf.org
Subject: Re: [stir] U.S. Senate = hearing on robocalls July 10, 2013
 
The full testimony, significantly = longer than the 5 minute version on video, is available by clicking on = the name of the witness. You will see references to STIR in both the FCC = and FTC testimony.
 
From: Mishra, Sanjay [mailto:sanjay.mishra@verizon.com] 
Sent: Wednesday, July 10, 2013 = 1:26 PM
To: Dan York; Richard = Shockey
Cc: stir@ietf.org; Henning = Schulzrinne
Subject: RE: [stir] U.S. Senate = hearing on robocalls July 10, = 2013
Dan =96 The archived Senate hearing is available at = the following URL:
 
 
The = second panel included Mr. Rupy from USTA and Mr. Altschul of CTIA. Both = these gentlemen essentially echoed same theme as earlier witnesses, but = added more color, nothing new added=85This was then followed by two last = witnesses, Mr. Stein (Primus) and Mr. Foss,  who spoke about = solution each have to identify spoofed telemarketer calls. Mr. Stein = talked about Telemarketing guard (in short, it supposedly automatically = identify suspected frequent, mass telemarketing calls)  and Mr. Foss talked about nomorobo =  (identifying caller id + calling pattern) which he had previously = presented to FTC and won a $50,000 award (FTC Robocall Challenge). Mr. = Foss said, he is now working on the solution to be ready by end of = summer=85.
 
Lastly, = there was of course a mention of =93common carriers can do = more=85.=94
 
=46rom = the sub-committee website, here are the details on the = speakers:

Witness Panel = 1

Ms. Lois Greisman  
Bureau of Consumer = Protection, Federal Trade Commission
 
Mr. Eric Bash  
Federal Communications = Commission 
Witness Panel = 2
Mr. Kevin G. Rupy  
United States Telecom = Association 
Mr. Michael F. Altschul  
CTIA - The Wireless = Association 
Mr. Matthew Stein  
Primus = Telecommunications Inc.
 
Thanks
 
 stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dan = York
Sent: Saturday, July 06, 2013 = 6:59 AM
To: Richard = Shockey
Cc: stir@ietf.org; Henning = Schulzrinne
Subject: Re: [stir] U.S. Senate = hearing on robocalls July 10, = 2013
Will anyone be able = to watch this and perhaps post a summary?  I will unfortunately be = in transit (heading to ICANN 47) but would be interested to learn what = was said. 
Dan


On Jul 5, 2013, at 12:11 PM, "Richard Shockey" <richard@shockey.us> = wrote:

Any agenda?  Who is testifying = =85
 
From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning = Schulzrinne
Sent: Friday, July 05, 2013 11:44 = AM
To: stir@ietf.org
Subject: [stir] U.S. Senate hearing = on robocalls July 10, 2013
 

Stopping Fraudulent Robocall Scams: Can More Be = Done?

Democratic Press Office - (202) = 224-8374

Jul10201310:00 = AM

Russell Senate Office = Building - 253
stir@ietf.org
stir@ietf.org
, 'Henning Schulzrinne' Subject: [stir] Using Validated Numbers (was - Re: U.S. Senate hearing on robocalls July 10, 2013) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 05:09:27 -0000 > Regardless, none of the robocall-blocking tactics I've seen will do much > in the long run unless we get the caller-id's to at least be > authenticate-able. Once we know the caller-ids can't be randomly > generated or spoof legitimate sources, doing whitelist/blacklist things > will be a lot more tenable. Dumb question, since it seems clear that most folk already have a sense of the answer: Once there are some telephone numbers getting validated, how will this get used and by what components in the system? I'm asking for more detail that the above text has, so that it's possible to consider the specifics of what to change and how it will work, such as during initial years of only partial adoption. Over in email-abuse land, a wide range of assumptions were made about the use of authenticated names, but the actual uses have had some surprises. To the extent that there is agreement on the specific uses that are planned for validated telephone numbers, it can sometimes help to clarify engineering choices for the validation mechanism. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From chris_wendt@cable.comcast.com Thu Jul 11 06:53: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 EA54811E8174 for ; Thu, 11 Jul 2013 06:53: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 QR5IXR9Iqlio for ; Thu, 11 Jul 2013 06:53:27 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id D9E3E11E8171 for ; Thu, 11 Jul 2013 06:53:24 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.81939696; Thu, 11 Jul 2013 07:51:25 -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; Thu, 11 Jul 2013 09:53:14 -0400 From: "Wendt, Chris" Thread-Topic: [stir] Using Validated Numbers (was - Re: U.S. Senate hearing on robocalls July 10, 2013) Thread-Index: AQHOfj38DO4GEUpPhUWEXHYCL6uPDg== Date: Thu, 11 Jul 2013 13:53:13 +0000 Message-ID: <1E0475FDD84F0C42A9F46570BB946FD941942C18@PACDCEXMB01.cable.comcast.com> References: , <007201ce799a$34539360$9cfaba20$@shockey.us> <900A1E2059ADB149B905E3C8FA0046A62C77C39220@FHDP1LUMXC7V23.us.one.verizon.com> <01ad01ce7da0$5af26f00$10d74d00$@shockey.us> <52705969-970E-431A-9A9B-B24AAF69C082@oracle.com> <51DE3DDB.2000303@dcrocker.net> In-Reply-To: <51DE3DDB.2000303@dcrocker.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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: "" Cc: "" , Dan York , "Mishra, Sanjay" , Henning Schulzrinne Subject: Re: [stir] Using Validated Numbers (was - Re: U.S. Senate hearing on robocalls July 10, 2013) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 13:53:32 -0000 I believe the combination of both tactics will be powerful and once caller-= id validation becomes more prevalent and universal, it will make the call a= nalytics, spoofing detection magic even more accurate, obviously. Will be key for congress and/or others to give a clear signal that blocking= or at least redirecting calls is appropriate and legal. It's just definin= g "appropriate" scenarios may be hard. On Jul 11, 2013, at 1:08 AM, Dave Crocker wrote: >=20 >> Regardless, none of the robocall-blocking tactics I've seen will do much >> in the long run unless we get the caller-id's to at least be >> authenticate-able. Once we know the caller-ids can't be randomly >> generated or spoof legitimate sources, doing whitelist/blacklist things >> will be a lot more tenable. >=20 >=20 > Dumb question, since it seems clear that most folk already have a sense o= f the answer: Once there are some telephone numbers getting validated, how= will this get used and by what components in the system? >=20 > I'm asking for more detail that the above text has, so that it's possible= to consider the specifics of what to change and how it will work, such as = during initial years of only partial adoption. >=20 > Over in email-abuse land, a wide range of assumptions were made about the= use of authenticated names, but the actual uses have had some surprises. >=20 > To the extent that there is agreement on the specific uses that are plann= ed for validated telephone numbers, it can sometimes help to clarify engine= ering choices for the validation mechanism. >=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 Henning.Schulzrinne@fcc.gov Thu Jul 11 07:00: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 9111511E812B for ; Thu, 11 Jul 2013 07:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.931 X-Spam-Level: X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[AWL=0.668, 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 tykhTYGN3lx6 for ; Thu, 11 Jul 2013 07:00:03 -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 3B6D611E817A for ; Thu, 11 Jul 2013 07:00:00 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "'dcrocker@bbiw.net'" , "stir@ietf.org" Thread-Topic: Using Validated Numbers (was - Re: [stir] U.S. Senate hearing on robocalls July 10, 2013) Thread-Index: AQHOffTJQB26Adoo30SC+fK7QmHeTplfgEdQ Date: Thu, 11 Jul 2013 13:59:59 +0000 References: , <007201ce799a$34539360$9cfaba20$@shockey.us> <900A1E2059ADB149B905E3C8FA0046A62C77C39220@FHDP1LUMXC7V23.us.one.verizon.com> <01ad01ce7da0$5af26f00$10d74d00$@shockey.us> <52705969-970E-431A-9A9B-B24AAF69C082@oracle.com> <51DE3DDB.2000303@dcrocker.net> In-Reply-To: <51DE3DDB.2000303@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: 'Dan York' , "'Mishra, Sanjay'" Subject: Re: [stir] Using Validated Numbers (was - Re: U.S. Senate hearing on robocalls July 10, 2013) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 14:00:07 -0000 A crucial component will be that=20 (1) *all* calls from a certain number are validated (2) the receiver can know that this is the case ("DANE") (2) can be a heuristic, given (1), but obviously explicit information is be= tter. That way, targets that are particularly susceptible to individualized= spoofing, such as financial institutions, can protect themselves first, ju= st like they did by implementing TLS early on their web sites. That would p= revent a fair amount of vishing. If we can then get the large outbound call= centers to "incent" their carriers, most people will then only get three k= inds of calls: (a) validated business calls (b) known numbers from friends and family (c) unvalidated calls that are very likely to be robocalls and can, at leas= t, be sent to voicemail and CAPTCHA (2) may not be an Internet-facing directory, although that could be quite h= elpful. For example, this information could be contained in the LERG or oth= er information made available by the numbering administrator. -----Original Message----- From: Dave Crocker [mailto:dhc@dcrocker.net]=20 Sent: Thursday, July 11, 2013 1:09 AM To: stir@ietf.org Cc: 'Dan York'; 'Mishra, Sanjay'; Henning Schulzrinne Subject: Using Validated Numbers (was - Re: [stir] U.S. Senate hearing on r= obocalls July 10, 2013) > Regardless, none of the robocall-blocking tactics I've seen will do=20 > much in the long run unless we get the caller-id's to at least be=20 > authenticate-able. Once we know the caller-ids can't be randomly=20 > generated or spoof legitimate sources, doing whitelist/blacklist=20 > things will be a lot more tenable. Dumb question, since it seems clear that most folk already have a sense of = the answer: Once there are some telephone numbers getting validated, how w= ill this get used and by what components in the system? I'm asking for more detail that the above text has, so that it's possible t= o consider the specifics of what to change and how it will work, such as du= ring initial years of only partial adoption. Over in email-abuse land, a wide range of assumptions were made about the u= se of authenticated names, but the actual uses have had some surprises. To the extent that there is agreement on the specific uses that are planned= for validated telephone numbers, it can sometimes help to clarify engineer= ing choices for the validation mechanism. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From housley@vigilsec.com Thu Jul 11 07:21: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 D2C2611E817F for ; Thu, 11 Jul 2013 07: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 VkejtKIXFomO for ; Thu, 11 Jul 2013 07:21:47 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 8B62221F9FFC for ; Thu, 11 Jul 2013 07:21:46 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 9840DF24082; Thu, 11 Jul 2013 10:21:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id mDweK8+DwkGk; Thu, 11 Jul 2013 10:21:44 -0400 (EDT) Received: from [172.16.31.121] (wsip-70-164-41-66.dc.dc.cox.net [70.164.41.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 98FC6F2407E; Thu, 11 Jul 2013 10:21:52 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> Date: Thu, 11 Jul 2013 10:21:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> To: stir@ietf.org X-Mailer: Apple Mail (2.1085) Cc: Richard Barnes , Brian Rosen , Gonzalo Camarillo Subject: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 14:21:54 -0000 Dear STIR Mail List Participants: Brian and I have tried to pull together charter text based on the = discussion to date. The closer we can get to consensus on the list before the BOF, the more = likely that we can get a WG shortly after Berlin. To this end, please = review and comment on the attached text. Brian and I will hold the pen = for updates to the text. Russ =3D =3D =3D =3D =3D Name: Secure Telephone Identity Revisited (stir) Area: RAI Chairs: TBD Area Advisor: Richard Barnes Mailing list: stir@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/stir 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. As with email, the claimed source identity of a SIP = request is not verified, and this permits unauthorized use of source = identities as part of deceptive and coercive activities, such as = robocalling (bulk unsolicited commercial communications), vishing = (voicemail hacking, and impersonating banks) and swatting (impersonating = callers to emergency services to stimulate unwarranted large scale law = enforcement deployments). This working group will define a deployable = mechanism to validate the identity of the calling party that can be = verified by entities in the path of a call. =20 SIP is one of the main VoIP technologies used by parties that want to = present an incorrect origination. A number of previous efforts have = tried to secure the origins of SIP communications, including RFC 3325, = RFC 4474, and the VIPR working group. To date, however, true validation = of the source of SIP calls has not seen any appreciable deployment. = Several factors contributed to this lack of success, including: failure = of the problem to be seen as critical at the time; lack of any real = means of asserting authority over telephone numbers; misalignment of the = mechanisms proposed by RFC 4474 with the complex deployment environment = that has emerged for SIP; lack of end-to-end SIP session establishment; = and inherent operational problems with a transitive trust model. Initially, the working group will specify an in-band mechanism to = authenticate the originator of a SIP session where the identity being = authenticated is a telephone number and the session is established with = SIP end to end. The working group will consider choices for protecting = the identity information and the credentials used, but will likely be = similar to the methods described in RFC 4474, which employs a signature = over a set of information in the SIP headers using a credential assigned = to the identity. In order to be authoritative, credentials used with = this mechanism will be derived from existing telephone number assignment = and delegation models. That is, when a telephone number or range of = telephone numbers is delegated to an entity, a credential will accompany = such delegation. The mechanism must allow parties who are not delegated = a telephone number, but are preauthorized by the entity who is delegated = the number, to place calls using the identity. Expansion of the = authentication mechanism to identities using the user@domain form should = be considered in the initial design. After completing the SIP end to = end solution, the working group will consider session establishment = where there are one or more non-SIP hops, most likely using an = out-of-band authentication mechanism. However, the in-band and = out-of-band mechanisms should share as much in common as possible, = especially the credentials. The working group will coordinate with the Security Area on credential = management. The working group will coordinate with other working groups in the RAI = Area regarding signaling through existing deployments, including = INSIPID. Authenticated identity is closely linked to privacy, and one frequently = 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. 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 The working group will deliver the following: - A problem statement detailing the deployment environment and situation that motivate work on secure telephone identity - A mechanism document describing the SIP end-to-end with telephone number-based identities=20 - A document describing the credentials required to support secure telephone identity - A fallback mechanism to allow out-of-band identity establishment during call setup Milestones Sep 2013 Submit problem statement for Informational Nov 2013 Submit RFC4474bis for Proposed Standard Feb 2014 Submit credential specification for Proposed Standard Jun 2014 Submit fallback for Proposed Standard From michael.hammer@yaanatech.com Thu Jul 11 07:37: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 480BD11E81A4 for ; Thu, 11 Jul 2013 07:37:05 -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=0.127, 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 tuW7oUk-tpdZ for ; Thu, 11 Jul 2013 07:37:01 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 12C0111E8189 for ; Thu, 11 Jul 2013 07:37:00 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Thu, 11 Jul 2013 07:36:59 -0700 From: Michael Hammer To: "Henning.Schulzrinne@fcc.gov" , "dcrocker@bbiw.net" , "stir@ietf.org" Thread-Topic: [stir] Using Validated Numbers (was - Re: U.S. Senate hearing on robocalls July 10, 2013) Thread-Index: AQHOffTTi+w/fxxOlkiy0CY8GkqTGplf90uA//+U5fA= Date: Thu, 11 Jul 2013 14:36:58 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC13E48@EX2K10MB1.corp.yaanatech.com> References: , <007201ce799a$34539360$9cfaba20$@shockey.us> <900A1E2059ADB149B905E3C8FA0046A62C77C39220@FHDP1LUMXC7V23.us.one.verizon.com> <01ad01ce7da0$5af26f00$10d74d00$@shockey.us> <52705969-970E-431A-9A9B-B24AAF69C082@oracle.com> <51DE3DDB.2000303@dcrocker.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.65] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0035_01CE7E22.9173DB40" MIME-Version: 1.0 Cc: "york@isoc.org" , "sanjay.mishra@verizon.com" Subject: Re: [stir] Using Validated Numbers (was - Re: U.S. Senate hearing on robocalls July 10, 2013) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 14:37:05 -0000 ------=_NextPart_000_0035_01CE7E22.9173DB40 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Correct me if I am wrong, but I didn't think the LERG went to 10 digits. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Thursday, July 11, 2013 10:00 AM To: 'dcrocker@bbiw.net'; stir@ietf.org Cc: 'Dan York'; 'Mishra, Sanjay' Subject: Re: [stir] Using Validated Numbers (was - Re: U.S. Senate hearing on robocalls July 10, 2013) A crucial component will be that (1) *all* calls from a certain number are validated (2) the receiver can know that this is the case ("DANE") (2) can be a heuristic, given (1), but obviously explicit information is better. That way, targets that are particularly susceptible to individualized spoofing, such as financial institutions, can protect themselves first, just like they did by implementing TLS early on their web sites. That would prevent a fair amount of vishing. If we can then get the large outbound call centers to "incent" their carriers, most people will then only get three kinds of calls: (a) validated business calls (b) known numbers from friends and family (c) unvalidated calls that are very likely to be robocalls and can, at least, be sent to voicemail and CAPTCHA (2) may not be an Internet-facing directory, although that could be quite helpful. For example, this information could be contained in the LERG or other information made available by the numbering administrator. -----Original Message----- From: Dave Crocker [mailto:dhc@dcrocker.net] Sent: Thursday, July 11, 2013 1:09 AM To: stir@ietf.org Cc: 'Dan York'; 'Mishra, Sanjay'; Henning Schulzrinne Subject: Using Validated Numbers (was - Re: [stir] U.S. Senate hearing on robocalls July 10, 2013) > Regardless, none of the robocall-blocking tactics I've seen will do > much in the long run unless we get the caller-id's to at least be > authenticate-able. Once we know the caller-ids can't be randomly > generated or spoof legitimate sources, doing whitelist/blacklist > things will be a lot more tenable. Dumb question, since it seems clear that most folk already have a sense of the answer: Once there are some telephone numbers getting validated, how will this get used and by what components in the system? I'm asking for more detail that the above text has, so that it's possible to consider the specifics of what to change and how it will work, such as during initial years of only partial adoption. Over in email-abuse land, a wide range of assumptions were made about the use of authenticated names, but the actual uses have had some surprises. To the extent that there is agreement on the specific uses that are planned for validated telephone numbers, it can sometimes help to clarify engineering choices for the validation mechanism. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_0035_01CE7E22.9173DB40 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx MTE0MzY1N1owIwYJKoZIhvcNAQkEMRYEFKDslY0Z6FUG78+l8n+2KPBDG9EWMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAbJGUQdeKbDG/GAXlkn+BFO6q+N2bjIJNel4W5Af1 EqaS3FLNFY/Fu8DPyM9tpHxaOaTjZ2JRRJYslvKVgCFOdc0ipH6ZGLU+T+AwF42XzYlMw0vci7Ao kFKTbrNOig4HhMIBBgUcnBwtgXjePNr/lYlkB098ojFWUboSxnjG3jWx0vlD5Id8FxWvNThww5SG H1km3wZchOjvmvTkytp7ya/QFeL7VMjAlm30gUjppmN6lYmlIxfVWup5464yGO2GfD+HOqN8N5SH lIpKqZM6ysaQ/ErJFtnqOzqg8Z77ICx+2hFzWLUbgUpx85ZtVHeYzWxyZEPS1oRvptHq6Rb87wAA AAAAAA== ------=_NextPart_000_0035_01CE7E22.9173DB40-- From md3135@att.com Thu Jul 11 09:57: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 3D42121F8437 for ; Thu, 11 Jul 2013 09:57:38 -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 Kd8nFDd9lNpH for ; Thu, 11 Jul 2013 09:57:32 -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 EBA1A11E811F for ; Thu, 11 Jul 2013 09:56: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 7d3eed15.2aaad981b940.4444105.00-545.12351198.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 11 Jul 2013 16:56:55 +0000 (UTC) X-MXL-Hash: 51dee3d771421234-32a1cb3f28167c471b3f936c54485addbb5ce920 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 4d3eed15.0.4444084.00-497.12351119.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 11 Jul 2013 16:56:54 +0000 (UTC) X-MXL-Hash: 51dee3d67961e471-c08b40af401e6748268674ed734437993bbec48f 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 r6BGupMk011452; Thu, 11 Jul 2013 12:56:51 -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 r6BGufKb011269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jul 2013 12:56:43 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Thu, 11 Jul 2013 16:56:24 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; Thu, 11 Jul 2013 12:56:49 -0400 From: "DOLLY, MARTIN C" To: Russ Housley , "stir@ietf.org" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIWF49pdfh4OE+hrHXvRgYKJ5lfshJA Date: Thu, 11 Jul 2013 16:56:48 +0000 Message-ID: References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> 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.87] 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=Hb+juF48 c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=zf2O0rY4uxIA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=egEOtIQ-O] X-AnalysisOut: [6YA:10 a=48vgC7mUAAAA:8 a=MbtGe0Bifu3p_1ipTWUA:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=lZB815dzVvQA:10 a=aKlBUGp5lnA17Ght:21 a=H-qFAqY] X-AnalysisOut: [4f3lS--p0:21] Cc: Richard Barnes , Brian Rosen , Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 16:57:38 -0000 Russ Brian, Are we really doing a RFC4474bis or something that is 4474-like, but with = a smaller scope WRT the first task of " Initially, the working group will s= pecify an in-band mechanism to authenticate the originator of a SIP session= where the identity being authenticated is a telephone number and the sessi= on is established with SIP end to end. "? I would appreciate the clarification. Regards, Martin=20 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Rus= s Housley Sent: Thursday, July 11, 2013 10:22 AM To: stir@ietf.org Cc: Richard Barnes; Brian Rosen; Gonzalo Camarillo Subject: [stir] Draft STIR Charter Dear STIR Mail List Participants: Brian and I have tried to pull together charter text based on the discussio= n to date. The closer we can get to consensus on the list before the BOF, the more lik= ely that we can get a WG shortly after Berlin. To this end, please review = and comment on the attached text. Brian and I will hold the pen for update= s to the text. Russ =3D =3D =3D =3D =3D Name: Secure Telephone Identity Revisited (stir) Area: RAI Chairs: TBD Area Advisor: Richard Barnes Mailing list: stir@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/stir 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. As with email, the claimed source identity of a SIP request is not ver= ified, and this permits unauthorized use of source identities as part of de= ceptive and coercive activities, such as robocalling (bulk unsolicited comm= ercial communications), vishing (voicemail hacking, and impersonating banks= ) and swatting (impersonating callers to emergency services to stimulate un= warranted large scale law enforcement deployments). This working group wil= l define a deployable mechanism to validate the identity of the calling par= ty that can be verified by entities in the path of a call. =20 SIP is one of the main VoIP technologies used by parties that want to prese= nt an incorrect origination. A number of previous efforts have tried to se= cure the origins of SIP communications, including RFC 3325, RFC 4474, and t= he VIPR working group. To date, however, true validation of the source of S= IP calls has not seen any appreciable deployment. Several factors contribu= ted to this lack of success, including: failure of the problem to be seen a= s critical at the time; lack of any real means of asserting authority over = telephone numbers; misalignment of the mechanisms proposed by RFC 4474 with= the complex deployment environment that has emerged for SIP; lack of end-t= o-end SIP session establishment; and inherent operational problems with a t= ransitive trust model. Initially, the working group will specify an in-band mechanism to authentic= ate the originator of a SIP session where the identity being authenticated = is a telephone number and the session is established with SIP end to end. = The working group will consider choices for protecting the identity informa= tion and the credentials used, but will likely be similar to the methods de= scribed in RFC 4474, which employs a signature over a set of information in= the SIP headers using a credential assigned to the identity. In order to = be authoritative, credentials used with this mechanism will be derived from= existing telephone number assignment and delegation models. That is, when= a telephone number or range of telephone numbers is delegated to an entity= , a credential will accompany such delegation. The mechanism must allow pa= rties who are not delegated a telephone number, but are preauthorized by th= e entity who is delegated the number, to place calls using the identity. E= xpansion of the authentication mechanism to identities using the user@domain form should = be considered in the initial design. After completing the SIP end to end s= olution, the working group will consider session establishment where there = are one or more non-SIP hops, most likely using an out-of-band authenticati= on mechanism. However, the in-band and out-of-band mechanisms should share= as much in common as possible, especially the credentials. The working group will coordinate with the Security Area on credential mana= gement. The working group will coordinate with other working groups in the RAI Area= regarding signaling through existing deployments, including INSIPID. Authenticated identity is closely linked to privacy, and one frequently com= es 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 wi= ll find privacy-friendly solutions that leak minimal information about call= s to third parties. 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 The working group will deliver the following: - A problem statement detailing the deployment environment and situation that motivate work on secure telephone identity - A mechanism document describing the SIP end-to-end with telephone number-based identities=20 - A document describing the credentials required to support secure telephone identity - A fallback mechanism to allow out-of-band identity establishment during call setup Milestones Sep 2013 Submit problem statement for Informational Nov 2013 Submit RFC4474bis for Proposed Standard Feb 2014 Submit credential specification for Proposed Standard Jun 2014 Submit fallback for Proposed Standard _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From brian.rosen@neustar.biz Thu Jul 11 10:01: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 731B921F999C for ; Thu, 11 Jul 2013 10:01:42 -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 mRcqYY8t9oCh for ; Thu, 11 Jul 2013 10:01:35 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id EB1E821F9970 for ; Thu, 11 Jul 2013 10:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1373562595; x=1688920882; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=i0Tjl6Yg3s NhsA7U13C1dHPxvJhJkDTeYIoPoqwC5OE=; b=WCgyt6G+GOC7AO9cql4/WZgYSF 25WKhgYvt5B7iWmv29oXjd9w0Y2OAwgJ3w+WI7sZbnaaxBx3YGS+IDf1reTQ== Received: from ([10.31.58.70]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.27747028; Thu, 11 Jul 2013 13:09: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; Thu, 11 Jul 2013 13:01:25 -0400 From: "Rosen, Brian" To: "DOLLY, MARTIN C" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkH7PavsqszcIEumRBC5KQ07J5lf9c0AgAABRwA= Date: Thu, 11 Jul 2013 17:01:24 +0000 Message-ID: <968DA52D-551E-47CA-B6F9-127A00820746@neustar.biz> References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@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.192.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: gJDRI0bCpEcfWINrlGYvcg== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Richard Barnes , "stir@ietf.org" , Russ Housley , Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 17:01:44 -0000 The text says: The working group will consider choices for protecting the identity informa= tion and the credentials used, but will likely be similar to the methods de= scribed in RFC 4474, which employs a signature over a set of information in= the SIP headers using a credential assigned to the identity. "Consider choices" means we don't have to do anything like 4474 if we don't= want to. "similar to" is 4474-like I would say it's up to the WG if the RFC replaces 4474 or not, but it certa= inly has smaller scope than 4474 currently does. Is that acceptable? Brian On Jul 11, 2013, at 12:56 PM, "DOLLY, MARTIN C" wrote: > Russ > Brian, >=20 > Are we really doing a RFC4474bis or something that is 4474-like, but wit= h a smaller scope WRT the first task of " Initially, the working group will= specify an in-band mechanism to authenticate the originator of a SIP sessi= on where the identity being authenticated is a telephone number and the ses= sion is established with SIP end to end. "? >=20 > I would appreciate the clarification. >=20 > Regards, >=20 > Martin=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of R= uss Housley > Sent: Thursday, July 11, 2013 10:22 AM > To: stir@ietf.org > Cc: Richard Barnes; Brian Rosen; Gonzalo Camarillo > Subject: [stir] Draft STIR Charter >=20 > Dear STIR Mail List Participants: >=20 > Brian and I have tried to pull together charter text based on the discuss= ion to date. >=20 > The closer we can get to consensus on the list before the BOF, the more l= ikely that we can get a WG shortly after Berlin. To this end, please revie= w and comment on the attached text. Brian and I will hold the pen for upda= tes to the text. >=20 > Russ >=20 > =3D =3D =3D =3D =3D >=20 > Name: Secure Telephone Identity Revisited (stir) > Area: RAI >=20 > Chairs: TBD > Area Advisor: Richard Barnes >=20 > Mailing list: stir@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/stir >=20 > Over the last decade, a growing set of problems have resulted from the la= ck of security mechanisms for attesting the origins of real-time communicat= ions. As with email, the claimed source identity of a SIP request is not v= erified, and this permits unauthorized use of source identities as part of = deceptive and coercive activities, such as robocalling (bulk unsolicited co= mmercial communications), vishing (voicemail hacking, and impersonating ban= ks) and swatting (impersonating callers to emergency services to stimulate = unwarranted large scale law enforcement deployments). This working group w= ill define a deployable mechanism to validate the identity of the calling p= arty that can be verified by entities in the path of a call. =20 >=20 > SIP is one of the main VoIP technologies used by parties that want to pre= sent an incorrect origination. A number of previous efforts have tried to = secure the origins of SIP communications, including RFC 3325, RFC 4474, and= the VIPR working group. To date, however, true validation of the source of= SIP calls has not seen any appreciable deployment. Several factors contri= buted to this lack of success, including: failure of the problem to be seen= as critical at the time; lack of any real means of asserting authority ove= r telephone numbers; misalignment of the mechanisms proposed by RFC 4474 wi= th the complex deployment environment that has emerged for SIP; lack of end= -to-end SIP session establishment; and inherent operational problems with a= transitive trust model. >=20 > Initially, the working group will specify an in-band mechanism to authent= icate the originator of a SIP session where the identity being authenticate= d is a telephone number and the session is established with SIP end to end.= The working group will consider choices for protecting the identity infor= mation and the credentials used, but will likely be similar to the methods = described in RFC 4474, which employs a signature over a set of information = in the SIP headers using a credential assigned to the identity. In order t= o be authoritative, credentials used with this mechanism will be derived fr= om existing telephone number assignment and delegation models. That is, wh= en a telephone number or range of telephone numbers is delegated to an enti= ty, a credential will accompany such delegation. The mechanism must allow = parties who are not delegated a telephone number, but are preauthorized by = the entity who is delegated the number, to place calls using the identity. = Expansion of the > authentication mechanism to identities using the user@domain form should= be considered in the initial design. After completing the SIP end to end = solution, the working group will consider session establishment where there= are one or more non-SIP hops, most likely using an out-of-band authenticat= ion mechanism. However, the in-band and out-of-band mechanisms should shar= e as much in common as possible, especially the credentials. >=20 > The working group will coordinate with the Security Area on credential ma= nagement. >=20 > The working group will coordinate with other working groups in the RAI Ar= ea regarding signaling through existing deployments, including INSIPID. >=20 > Authenticated identity is closely linked to privacy, and one frequently c= omes at the cost of the other. This working group is not chartered to manda= te the presence of identity in SIP requests, and to the extent feasible it = will find privacy-friendly solutions that leak minimal information about ca= lls to third parties. >=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 > The working group will deliver the following: >=20 > - A problem statement detailing the deployment environment and > situation that motivate work on secure telephone identity >=20 > - A mechanism document describing the SIP end-to-end with telephone > number-based identities=20 >=20 > - A document describing the credentials required to support secure > telephone identity >=20 > - A fallback mechanism to allow out-of-band identity establishment > during call setup >=20 > Milestones >=20 > Sep 2013 Submit problem statement for Informational > Nov 2013 Submit RFC4474bis for Proposed Standard > Feb 2014 Submit credential specification for Proposed Standard > Jun 2014 Submit fallback for Proposed Standard >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From md3135@att.com Thu Jul 11 10: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 5636021F9974 for ; Thu, 11 Jul 2013 10:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.29 X-Spam-Level: X-Spam-Status: No, score=-5.29 tagged_above=-999 required=5 tests=[AWL=1.309, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrEpV9wF9JKe for ; Thu, 11 Jul 2013 10:03:32 -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 43F3511E8118 for ; Thu, 11 Jul 2013 10:03: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 265eed15.6126a940.169457.00-549.479312.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 11 Jul 2013 17:03:30 +0000 (UTC) X-MXL-Hash: 51dee5625d861c94-9d4c4d820a87b6b5422f5ac429de238cc904ef1e 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 f55eed15.0.169437.00-467.479237.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 11 Jul 2013 17:03:29 +0000 (UTC) X-MXL-Hash: 51dee56131d4efc8-777bbe660ffd6a8782ff24a66d08cfb909e993ca 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 r6BH3R77019267; Thu, 11 Jul 2013 13:03:27 -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 r6BH3Gwu019086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jul 2013 13:03:16 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Thu, 11 Jul 2013 17:02:57 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; Thu, 11 Jul 2013 13:03:22 -0400 From: "DOLLY, MARTIN C" To: "Rosen, Brian" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIWF49pdfh4OE+hrHXvRgYKJ5lfshJAgABFBAD//71Y4A== Date: Thu, 11 Jul 2013 17:03:21 +0000 Message-ID: References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <968DA52D-551E-47CA-B6F9-127A00820746@neustar.biz> In-Reply-To: <968DA52D-551E-47CA-B6F9-127A00820746@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.92.87] 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=esxoOPVX c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=zf2O0rY4uxIA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=egEOtIQ-O] X-AnalysisOut: [6YA:10 a=hGBaWAWWAAAA:8 a=48vgC7mUAAAA:8 a=wGUCHbBivwakslZ] X-AnalysisOut: [h_dwA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA] X-AnalysisOut: [:10 a=S57QgcEpIBZ85Ir3:21 a=HaVz4BXFzgir3Qi9:21] Cc: Richard Barnes , "stir@ietf.org" , Russ Housley , Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 17:03:38 -0000 Brian, Yes, but the milestone should reflect that. Thanks, Martin=20 -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 Sent: Thursday, July 11, 2013 1:01 PM To: DOLLY, MARTIN C Cc: Russ Housley; stir@ietf.org; Richard Barnes; Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter The text says: The working group will consider choices for protecting the identity informa= tion and the credentials used, but will likely be similar to the methods de= scribed in RFC 4474, which employs a signature over a set of information in= the SIP headers using a credential assigned to the identity. "Consider choices" means we don't have to do anything like 4474 if we don't= want to. "similar to" is 4474-like I would say it's up to the WG if the RFC replaces 4474 or not, but it certa= inly has smaller scope than 4474 currently does. Is that acceptable? Brian On Jul 11, 2013, at 12:56 PM, "DOLLY, MARTIN C" wrote: > Russ > Brian, >=20 > Are we really doing a RFC4474bis or something that is 4474-like, but wit= h a smaller scope WRT the first task of " Initially, the working group will= specify an in-band mechanism to authenticate the originator of a SIP sessi= on where the identity being authenticated is a telephone number and the ses= sion is established with SIP end to end. "? >=20 > I would appreciate the clarification. >=20 > Regards, >=20 > Martin=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of R= uss Housley > Sent: Thursday, July 11, 2013 10:22 AM > To: stir@ietf.org > Cc: Richard Barnes; Brian Rosen; Gonzalo Camarillo > Subject: [stir] Draft STIR Charter >=20 > Dear STIR Mail List Participants: >=20 > Brian and I have tried to pull together charter text based on the discuss= ion to date. >=20 > The closer we can get to consensus on the list before the BOF, the more l= ikely that we can get a WG shortly after Berlin. To this end, please revie= w and comment on the attached text. Brian and I will hold the pen for upda= tes to the text. >=20 > Russ >=20 > =3D =3D =3D =3D =3D >=20 > Name: Secure Telephone Identity Revisited (stir) > Area: RAI >=20 > Chairs: TBD > Area Advisor: Richard Barnes >=20 > Mailing list: stir@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/stir >=20 > Over the last decade, a growing set of problems have resulted from the la= ck of security mechanisms for attesting the origins of real-time communicat= ions. As with email, the claimed source identity of a SIP request is not v= erified, and this permits unauthorized use of source identities as part of = deceptive and coercive activities, such as robocalling (bulk unsolicited co= mmercial communications), vishing (voicemail hacking, and impersonating ban= ks) and swatting (impersonating callers to emergency services to stimulate = unwarranted large scale law enforcement deployments). This working group w= ill define a deployable mechanism to validate the identity of the calling p= arty that can be verified by entities in the path of a call. =20 >=20 > SIP is one of the main VoIP technologies used by parties that want to pre= sent an incorrect origination. A number of previous efforts have tried to = secure the origins of SIP communications, including RFC 3325, RFC 4474, and= the VIPR working group. To date, however, true validation of the source of= SIP calls has not seen any appreciable deployment. Several factors contri= buted to this lack of success, including: failure of the problem to be seen= as critical at the time; lack of any real means of asserting authority ove= r telephone numbers; misalignment of the mechanisms proposed by RFC 4474 wi= th the complex deployment environment that has emerged for SIP; lack of end= -to-end SIP session establishment; and inherent operational problems with a= transitive trust model. >=20 > Initially, the working group will specify an in-band mechanism to authent= icate the originator of a SIP session where the identity being authenticate= d is a telephone number and the session is established with SIP end to end.= The working group will consider choices for protecting the identity infor= mation and the credentials used, but will likely be similar to the methods = described in RFC 4474, which employs a signature over a set of information = in the SIP headers using a credential assigned to the identity. In order t= o be authoritative, credentials used with this mechanism will be derived fr= om existing telephone number assignment and delegation models. That is, wh= en a telephone number or range of telephone numbers is delegated to an enti= ty, a credential will accompany such delegation. The mechanism must allow = parties who are not delegated a telephone number, but are preauthorized by = the entity who is delegated the number, to place calls using the identity. = Expansion of the > authentication mechanism to identities using the user@domain form should= be considered in the initial design. After completing the SIP end to end = solution, the working group will consider session establishment where there= are one or more non-SIP hops, most likely using an out-of-band authenticat= ion mechanism. However, the in-band and out-of-band mechanisms should shar= e as much in common as possible, especially the credentials. >=20 > The working group will coordinate with the Security Area on credential ma= nagement. >=20 > The working group will coordinate with other working groups in the RAI Ar= ea regarding signaling through existing deployments, including INSIPID. >=20 > Authenticated identity is closely linked to privacy, and one frequently c= omes at the cost of the other. This working group is not chartered to manda= te the presence of identity in SIP requests, and to the extent feasible it = will find privacy-friendly solutions that leak minimal information about ca= lls to third parties. >=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 > The working group will deliver the following: >=20 > - A problem statement detailing the deployment environment and > situation that motivate work on secure telephone identity >=20 > - A mechanism document describing the SIP end-to-end with telephone > number-based identities=20 >=20 > - A document describing the credentials required to support secure > telephone identity >=20 > - A fallback mechanism to allow out-of-band identity establishment > during call setup >=20 > Milestones >=20 > Sep 2013 Submit problem statement for Informational > Nov 2013 Submit RFC4474bis for Proposed Standard > Feb 2014 Submit credential specification for Proposed Standard > Jun 2014 Submit fallback for Proposed Standard >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From brian.rosen@neustar.biz Thu Jul 11 10:08: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 82E9021F9C88 for ; Thu, 11 Jul 2013 10:08:35 -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 1sXhe9PtsHoQ for ; Thu, 11 Jul 2013 10:08:31 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 652A821F9C56 for ; Thu, 11 Jul 2013 10:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1373563012; x=1688920882; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=k3IJ1zVQMz VsINQmFWMZQkz2/84meo3ZNJ1bsBoxsWQ=; b=KiGp96lbSgqB55vhpIYqflKe1q P3T8xHX8Uix8mWxdHF9i6IUm0TxRT9nxb0MRrFMJRypodFOFnkg8QWZjjdng== Received: from ([10.31.58.71]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.27747605; Thu, 11 Jul 2013 13:16: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, 11 Jul 2013 13:08:20 -0400 From: "Rosen, Brian" To: "DOLLY, MARTIN C" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkH7PavsqszcIEumRBC5KQ07J5lf9c0AgAABRwCAAACOgIAAAWOA Date: Thu, 11 Jul 2013 17:08:20 +0000 Message-ID: <5D65B962-B487-419E-BA0B-BCC1D8852EE2@neustar.biz> References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <968DA52D-551E-47CA-B6F9-127A00820746@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.192.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: X23Rll4YxQu0iEbk+cVkrQ== Content-Type: text/plain; charset="us-ascii" Content-ID: <75732EE3CC636D4F82462A9CC0F567F5@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Richard Barnes , "stir@ietf.org" , Russ Housley , Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 17:08:35 -0000 Ahh, missed that. Let's change that text to: Nov 2013 Submit in-band mechanism for Proposed Standard Brian On Jul 11, 2013, at 1:03 PM, "DOLLY, MARTIN C" wrote: > Brian, >=20 > Yes, but the milestone should reflect that. >=20 > Thanks, >=20 > Martin=20 >=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 > Sent: Thursday, July 11, 2013 1:01 PM > To: DOLLY, MARTIN C > Cc: Russ Housley; stir@ietf.org; Richard Barnes; Gonzalo Camarillo > Subject: Re: [stir] Draft STIR Charter >=20 > The text says: > The working group will consider choices for protecting the identity infor= mation and the credentials used, but will likely be similar to the methods = described in RFC 4474, which employs a signature over a set of information = in the SIP headers using a credential assigned to the identity. >=20 > "Consider choices" means we don't have to do anything like 4474 if we don= 't want to. "similar to" is 4474-like >=20 > I would say it's up to the WG if the RFC replaces 4474 or not, but it cer= tainly has smaller scope than 4474 currently does. >=20 > Is that acceptable? >=20 > Brian >=20 >=20 >=20 > On Jul 11, 2013, at 12:56 PM, "DOLLY, MARTIN C" > wrote: >=20 >> Russ >> Brian, >>=20 >> Are we really doing a RFC4474bis or something that is 4474-like, but wi= th a smaller scope WRT the first task of " Initially, the working group wil= l specify an in-band mechanism to authenticate the originator of a SIP sess= ion where the identity being authenticated is a telephone number and the se= ssion is established with SIP end to end. "? >>=20 >> I would appreciate the clarification. >>=20 >> Regards, >>=20 >> Martin=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Russ Housley >> Sent: Thursday, July 11, 2013 10:22 AM >> To: stir@ietf.org >> Cc: Richard Barnes; Brian Rosen; Gonzalo Camarillo >> Subject: [stir] Draft STIR Charter >>=20 >> Dear STIR Mail List Participants: >>=20 >> Brian and I have tried to pull together charter text based on the discus= sion to date. >>=20 >> The closer we can get to consensus on the list before the BOF, the more = likely that we can get a WG shortly after Berlin. To this end, please revi= ew and comment on the attached text. Brian and I will hold the pen for upd= ates to the text. >>=20 >> Russ >>=20 >> =3D =3D =3D =3D =3D >>=20 >> Name: Secure Telephone Identity Revisited (stir) >> Area: RAI >>=20 >> Chairs: TBD >> Area Advisor: Richard Barnes >>=20 >> Mailing list: stir@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/stir >>=20 >> Over the last decade, a growing set of problems have resulted from the l= ack of security mechanisms for attesting the origins of real-time communica= tions. As with email, the claimed source identity of a SIP request is not = verified, and this permits unauthorized use of source identities as part of= deceptive and coercive activities, such as robocalling (bulk unsolicited c= ommercial communications), vishing (voicemail hacking, and impersonating ba= nks) and swatting (impersonating callers to emergency services to stimulate= unwarranted large scale law enforcement deployments). This working group = will define a deployable mechanism to validate the identity of the calling = party that can be verified by entities in the path of a call. =20 >>=20 >> SIP is one of the main VoIP technologies used by parties that want to pr= esent an incorrect origination. A number of previous efforts have tried to= secure the origins of SIP communications, including RFC 3325, RFC 4474, an= d the VIPR working group. To date, however, true validation of the source o= f SIP calls has not seen any appreciable deployment. Several factors contr= ibuted to this lack of success, including: failure of the problem to be see= n as critical at the time; lack of any real means of asserting authority ov= er telephone numbers; misalignment of the mechanisms proposed by RFC 4474 w= ith the complex deployment environment that has emerged for SIP; lack of en= d-to-end SIP session establishment; and inherent operational problems with = a transitive trust model. >>=20 >> Initially, the working group will specify an in-band mechanism to authen= ticate the originator of a SIP session where the identity being authenticat= ed is a telephone number and the session is established with SIP end to end= . The working group will consider choices for protecting the identity info= rmation and the credentials used, but will likely be similar to the methods= described in RFC 4474, which employs a signature over a set of information= in the SIP headers using a credential assigned to the identity. In order = to be authoritative, credentials used with this mechanism will be derived f= rom existing telephone number assignment and delegation models. That is, w= hen a telephone number or range of telephone numbers is delegated to an ent= ity, a credential will accompany such delegation. The mechanism must allow= parties who are not delegated a telephone number, but are preauthorized by= the entity who is delegated the number, to place calls using the identity.= Expansion of the >> authentication mechanism to identities using the user@domain form should= be considered in the initial design. After completing the SIP end to end = solution, the working group will consider session establishment where there= are one or more non-SIP hops, most likely using an out-of-band authenticat= ion mechanism. However, the in-band and out-of-band mechanisms should shar= e as much in common as possible, especially the credentials. >>=20 >> The working group will coordinate with the Security Area on credential m= anagement. >>=20 >> The working group will coordinate with other working groups in the RAI A= rea regarding signaling through existing deployments, including INSIPID. >>=20 >> Authenticated identity is closely linked to privacy, and one frequently = comes at the cost of the other. This working group is not chartered to mand= ate the presence of identity in SIP requests, and to the extent feasible it= will find privacy-friendly solutions that leak minimal information about c= alls to third parties. >>=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 >> The working group will deliver the following: >>=20 >> - A problem statement detailing the deployment environment and >> situation that motivate work on secure telephone identity >>=20 >> - A mechanism document describing the SIP end-to-end with telephone >> number-based identities=20 >>=20 >> - A document describing the credentials required to support secure >> telephone identity >>=20 >> - A fallback mechanism to allow out-of-band identity establishment >> during call setup >>=20 >> Milestones >>=20 >> Sep 2013 Submit problem statement for Informational >> Nov 2013 Submit RFC4474bis for Proposed Standard >> Feb 2014 Submit credential specification for Proposed Standard >> Jun 2014 Submit fallback for Proposed Standard >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 From pkyzivat@alum.mit.edu Thu Jul 11 10:08: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 B900621F9FCF for ; Thu, 11 Jul 2013 10:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.133 X-Spam-Level: X-Spam-Status: No, score=-0.133 tagged_above=-999 required=5 tests=[AWL=0.304, 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 9aqD4fv+AFPQ for ; Thu, 11 Jul 2013 10:08:42 -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 C5D7B11E8138 for ; Thu, 11 Jul 2013 10:08:41 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta01.westchester.pa.mail.comcast.net with comcast id z2dt1l00B0vyq2s5158hbw; Thu, 11 Jul 2013 17:08:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id z58g1l00y3ZTu2S3R58hwg; Thu, 11 Jul 2013 17:08:41 +0000 Message-ID: <51DEE698.9090300@alum.mit.edu> Date: Thu, 11 Jul 2013 13:08:40 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: stir@ietf.org References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <968DA52D-551E-47CA-B6F9-127A00820746@neustar.biz> In-Reply-To: <968DA52D-551E-47CA-B6F9-127A00820746@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=1373562521; bh=e5IlKH+gSqwJ2Vq/aRjA91T+WAKxQA3sBZLCCpCqPgE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=oy+kUOgcqtogKOV5yBNrQUMx/0ukIBViODYqe7n4r+gwhSUwVQe+lj2LzVV4OxvB8 zkKXy5yYhBXLeY3ZemXm2CH9XYPSYT1VCQ5/lIS86yzxryrixkRBkD1T/y59zXMrA/ S9ul/TGWtbqOHmXmkXcnvEXcSmMq0c4wZL8ECAIiFu0O/FWNijh8hpM282ngk0w13h 6wGIxTNcuee4R0F7bPZYzfwDaT1MpI9eJ7NzngKDFthAMcXvWujBFnDZoTo7ldSINn dnzY6RrevxWi+h9FQTd/N843WwmeDGVOQa7RBV9IWiO1cebcVrrVIGkfYxB4LnU1fu cgnYNNkWv7P7g== Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 17:08:46 -0000 On 7/11/13 1:01 PM, Rosen, Brian wrote: > The text says: > The working group will consider choices for protecting the identity information and the credentials used, but will likely be similar to the methods described in RFC 4474, which employs a signature over a set of information in the SIP headers using a credential assigned to the identity. > > "Consider choices" means we don't have to do anything like 4474 if we don't want to. "similar to" is 4474-like > > I would say it's up to the WG if the RFC replaces 4474 or not, but it certainly has smaller scope than 4474 currently does. ISTM the scope is *different* from 4474, not necessarily smaller. - 4474 only covers email-style addresses, not phone numbers - this work (at least initially) only covers phone numbers Trying to decide which is bigger is a useless task. > Is that acceptable? I'm not Martin, but IMO yes. Thanks, Paul > Brian > > > > On Jul 11, 2013, at 12:56 PM, "DOLLY, MARTIN C" > wrote: > >> Russ >> Brian, >> >> Are we really doing a RFC4474bis or something that is 4474-like, but with a smaller scope WRT the first task of " Initially, the working group will specify an in-band mechanism to authenticate the originator of a SIP session where the identity being authenticated is a telephone number and the session is established with SIP end to end. "? >> >> I would appreciate the clarification. >> >> Regards, >> >> Martin >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Russ Housley >> Sent: Thursday, July 11, 2013 10:22 AM >> To: stir@ietf.org >> Cc: Richard Barnes; Brian Rosen; Gonzalo Camarillo >> Subject: [stir] Draft STIR Charter >> >> Dear STIR Mail List Participants: >> >> Brian and I have tried to pull together charter text based on the discussion to date. >> >> The closer we can get to consensus on the list before the BOF, the more likely that we can get a WG shortly after Berlin. To this end, please review and comment on the attached text. Brian and I will hold the pen for updates to the text. >> >> Russ >> >> = = = = = >> >> Name: Secure Telephone Identity Revisited (stir) >> Area: RAI >> >> Chairs: TBD >> Area Advisor: Richard Barnes >> >> Mailing list: stir@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/stir >> >> 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. As with email, the claimed source identity of a SIP request is not verified, and this permits unauthorized use of source identities as part of deceptive and coercive activities, such as robocalling (bulk unsolicited commercial communications), vishing (voicemail hacking, and impersonating banks) and swatting (impersonating callers to emergency services to stimulate unwarranted large scale law enforcement deployments). This working group will define a deployable mechanism to validate the identity of the calling party that can be verified by entities in the path of a call. >> >> SIP is one of the main VoIP technologies used by parties that want to present an incorrect origination. A number of previous efforts have tried to secure the origins of SIP communications, including RFC 3325, RFC 4474, and the VIPR working group. To date, however, true validation of the source of SIP calls has not seen any appreciable deployment. Several factors contributed to this lack of success, including: failure of the problem to be seen as critical at the time; lack of any real means of asserting authority over telephone numbers; misalignment of the mechanisms proposed by RFC 4474 with the complex deployment environment that has emerged for SIP; lack of end-to-end SIP session establishment; and inherent operational problems with a transitive trust model. >> >> Initially, the working group will specify an in-band mechanism to authenticate the originator of a SIP session where the identity being authenticated is a telephone number and the session is established with SIP end to end. The working group will consider choices for protecting the identity information and the credentials used, but will likely be similar to the methods described in RFC 4474, which employs a signature over a set of information in the SIP headers using a credential assigned to the identity. In order to be authoritative, credentials used with this mechanism will be derived from existing telephone number assignment and delegation models. That is, when a telephone number or range of telephone numbers is delegated to an entity, a credential will accompany such delegation. The mechanism must allow parties who are not delegated a telephone number, but are preauthorized by the entity who is delegated the number, to place calls using the identity. Expansion of t > he >> authentication mechanism to identities using the user@domain form should be considered in the initial design. After completing the SIP end to end solution, the working group will consider session establishment where there are one or more non-SIP hops, most likely using an out-of-band authentication mechanism. However, the in-band and out-of-band mechanisms should share as much in common as possible, especially the credentials. >> >> The working group will coordinate with the Security Area on credential management. >> >> The working group will coordinate with other working groups in the RAI Area regarding signaling through existing deployments, including INSIPID. >> >> Authenticated identity is closely linked to privacy, and one frequently 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. >> >> 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 >> >> The working group will deliver the following: >> >> - A problem statement detailing the deployment environment and >> situation that motivate work on secure telephone identity >> >> - A mechanism document describing the SIP end-to-end with telephone >> number-based identities >> >> - A document describing the credentials required to support secure >> telephone identity >> >> - A fallback mechanism to allow out-of-band identity establishment >> during call setup >> >> Milestones >> >> Sep 2013 Submit problem statement for Informational >> Nov 2013 Submit RFC4474bis for Proposed Standard >> Feb 2014 Submit credential specification for Proposed Standard >> Jun 2014 Submit fallback for Proposed Standard >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From dhc@dcrocker.net Thu Jul 11 10:16: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 E4B2521F9E4E for ; Thu, 11 Jul 2013 10:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.594 X-Spam-Level: X-Spam-Status: No, score=-6.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VaY5YGJRdzV for ; Thu, 11 Jul 2013 10:16:40 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 03DDD21F9E1A for ; Thu, 11 Jul 2013 10:16:40 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r6BHGVZW012874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Jul 2013 10:16:35 -0700 Message-ID: <51DEE855.1060506@dcrocker.net> Date: Thu, 11 Jul 2013 10:16:05 -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: "Rosen, Brian" References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <968DA52D-551E-47CA-B6F9-127A00820746@neustar.biz> In-Reply-To: <968DA52D-551E-47CA-B6F9-127A00820746@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]); Thu, 11 Jul 2013 10:16:35 -0700 (PDT) Cc: Richard Barnes , "stir@ietf.org" , Russ Housley , "DOLLY, MARTIN C" , Gonzalo Camarillo Subject: Re: [stir] Draft STIR 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, 11 Jul 2013 17:16:45 -0000 On 7/11/2013 10:01 AM, Rosen, Brian wrote: > The text says: > The working group will consider choices for protecting the identity information and the credentials used, > but will likely be similar to the methods described in RFC 4474, which employs a signature over a set of information in the SIP headers using a credential assigned to the identity. > > "Consider choices" means we don't have to do anything like 4474 if we don't want to. "similar to" is 4474-like > > I would say it's up to the WG if the RFC replaces 4474 or not, but it certainly has smaller scope than 4474 currently does. > > Is that acceptable? However "will likely be similar to the methods described in RFC 4474" is text that is explicitly and formally biasing. Worse, there are no criteria that make it possible to know what 'similar to the methods in RFC 4474' does and does not mean. Hence, the text actually adds ambiguity to the charter. At a minimum, it creates an extra barrier to any approach or details that differ from 4484, since it will impose a charter-based requirement to justify the deviation. Why is it important to cite 4474 in this way? In chartering, working group management and engineering terms, what is the benefit in having that text? What is lost by eliminating it? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From brian.rosen@neustar.biz Thu Jul 11 10: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 0A1EB21F9ED1 for ; Thu, 11 Jul 2013 10:23:49 -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.276, 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 Xbhm6Hd9PfS4 for ; Thu, 11 Jul 2013 10:23:42 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC1521F99F9 for ; Thu, 11 Jul 2013 10:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1373563919; x=1688920882; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=8R8047p6Ky F6dBFBcCoVffIROCun5B7RE6qpuXHSZ/s=; b=EyA/5bnFZPmhDJCv7PZYF/Zd41 ij1vnIQehDB2dwE0pSoy9zMtJWlat6A1qgflPnTFl4VsmPiXhyFPVL+W5Zdw== Received: from ([10.31.58.71]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.27748755; Thu, 11 Jul 2013 13:31: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; Thu, 11 Jul 2013 13:23:27 -0400 From: "Rosen, Brian" To: "" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkH7PavsqszcIEumRBC5KQ07J5lf9c0AgAABRwCAAAQcgIAAAg4A Date: Thu, 11 Jul 2013 17:23:27 +0000 Message-ID: <05889381-CFB4-4E66-B978-FDAD242E989E@neustar.biz> References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <968DA52D-551E-47CA-B6F9-127A00820746@neustar.biz> <51DEE855.1060506@dcrocker.net> In-Reply-To: <51DEE855.1060506@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.192.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: nUvMwrHiqDEHVXi2qvEX7Q== Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Richard Barnes , "stir@ietf.org" , Russ Housley , "DOLLY, MARTIN C" , Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 17:23:49 -0000 We are trying to limit the scope. We do have an assumption that we're crypto-signing a set of info from SIP h= eaders using some kind of credential. We are assuming 4474-like solutions. That might, in the end, not work, but yes, I think we should have to justif= y a deviation. The way the text is written, we don't have to recharter to = change the approach. I think limiting scope and stating intended direction is helpful. It makes= it more of an engineering problem and less of a research effort. Brian On Jul 11, 2013, at 1:16 PM, Dave Crocker wrote: > On 7/11/2013 10:01 AM, Rosen, Brian wrote: >> The text says: >> The working group will consider choices for protecting the identity info= rmation and the credentials used, > > but will likely be similar to the methods described in RFC 4474, which = employs a signature over a set of information in the SIP headers using a cr= edential assigned to the identity. >>=20 >> "Consider choices" means we don't have to do anything like 4474 if we do= n't want to. "similar to" is 4474-like >>=20 >> I would say it's up to the WG if the RFC replaces 4474 or not, but it ce= rtainly has smaller scope than 4474 currently does. >>=20 >> Is that acceptable? >=20 >=20 > However "will likely be similar to the methods described in RFC 4474" is = text that is explicitly and formally biasing. >=20 > Worse, there are no criteria that make it possible to know what 'similar = to the methods in RFC 4474' does and does not mean. Hence, the text actual= ly adds ambiguity to the charter. >=20 > At a minimum, it creates an extra barrier to any approach or details that= differ from 4484, since it will impose a charter-based requirement to just= ify the deviation. >=20 > Why is it important to cite 4474 in this way? In chartering, working gro= up management and engineering terms, what is the benefit in having that tex= t? What is lost by eliminating it? >=20 > d/ > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net From jon.peterson@neustar.biz Thu Jul 11 10:28: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 4BFA321F9F03 for ; Thu, 11 Jul 2013 10:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.207 X-Spam-Level: X-Spam-Status: No, score=-106.207 tagged_above=-999 required=5 tests=[AWL=0.392, 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 OSPxJ4srrlaj for ; Thu, 11 Jul 2013 10:28:45 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 91C8621F9A1E for ; Thu, 11 Jul 2013 10:28:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1373563673; x=1688920342; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=B1eP9+4tTj ohCohml39Q+5a6hP9KWnzH/hBjYNpU5EU=; b=HcA3TH5neiFWqch/wx0mEdu00w h8NnspgTVYA/zzCr/vCM3xoAcNtzQQrqkVu9xQh5gfFjPynR17Uz9gfx4c/Q== Received: from ([10.31.58.69]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.22197804; Thu, 11 Jul 2013 13:27:52 -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, 11 Jul 2013 13:28:26 -0400 From: "Peterson, Jon" To: Paul Kyzivat , "stir@ietf.org" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkICx1fsldqNdEa1H4oCYTQLxplf9c0AgAABSQCAAAIIAP//kCmA Date: Thu, 11 Jul 2013 17:28:25 +0000 Message-ID: In-Reply-To: <51DEE698.9090300@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.129.119] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: WxdAt7UplvdFB4dQJ4VQ3Q== Content-Type: text/plain; charset="us-ascii" Content-ID: <05874CD5B9767F46BFA254679F2CC41A@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 17:28:57 -0000 >> >> >> >> I would say it's up to the WG if the RFC replaces 4474 or not, but it >>certainly has smaller scope than 4474 currently does. > >ISTM the scope is *different* from 4474, not necessarily smaller. >- 4474 only covers email-style addresses, not phone numbers Not true. See Section 11; RFC4474 does contain some (unhelpful) guidance about telephone numbers. This is guidance STIR will be replacing, no matter what. >- this work (at least initially) only covers phone numbers The scope of this proposed working group is to solve the impersonation problems associated with robocalling, yes, but that doesn't necessarily mean that a work we do to address that problems won't also have applicability to other problems. If we still believe that some SIP requests will originate from greenfield SIP URIs, then I think we need a story about verification service behavior that's going to at least acknowledge both of these cases exist. If a service that validates for telephone numbers could conceivably get a request from a non-TN URI, I think at least we need to have a hook for how it will behave in that case. If the answer is, "do roughly the procedures in RFC4474," then that's telling for how we should structure the work. Moreover, it's not like the proposed reductions to the scope to the digest-string shouldn't apply equally to the greenfield SIP URI case as the TN case. If those changes were unique to the TN case, I could see arguing this should be separate work. Again, we're going to want implementations that do identity to not use the digest-string of RFC4474 but instead use the one coming out of this work. But that said, I don't think we need the milestone in the charter to say "RFC4474bis," so I'm fine if it doesn't. There are however good reasons for the work here to be an RFC4474bis. Jon Peterson Neustar, Inc. > >> Brian >> >> >> >> On Jul 11, 2013, at 12:56 PM, "DOLLY, MARTIN C" >> wrote: >> >>> Russ >>> Brian, >>> >>> Are we really doing a RFC4474bis or something that is 4474-like, but >>>with a smaller scope WRT the first task of " Initially, the working >>>group will specify an in-band mechanism to authenticate the originator >>>of a SIP session where the identity being authenticated is a telephone >>>number and the session is established with SIP end to end. "? >>> >>> I would appreciate the clarification. >>> >>> Regards, >>> >>> Martin >>> >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >>>Of Russ Housley >>> Sent: Thursday, July 11, 2013 10:22 AM >>> To: stir@ietf.org >>> Cc: Richard Barnes; Brian Rosen; Gonzalo Camarillo >>> Subject: [stir] Draft STIR Charter >>> >>> Dear STIR Mail List Participants: >>> >>> Brian and I have tried to pull together charter text based on the >>>discussion to date. >>> >>> The closer we can get to consensus on the list before the BOF, the >>>more likely that we can get a WG shortly after Berlin. To this end, >>>please review and comment on the attached text. Brian and I will hold >>>the pen for updates to the text. >>> >>> Russ >>> >>> =3D =3D =3D =3D =3D >>> >>> Name: Secure Telephone Identity Revisited (stir) >>> Area: RAI >>> >>> Chairs: TBD >>> Area Advisor: Richard Barnes >>> >>> Mailing list: stir@ietf.org >>> To Subscribe: https://www.ietf.org/mailman/listinfo/stir >>> >>> 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. As with email, the claimed source identity of a SIP >>>request is not verified, and this permits unauthorized use of source >>>identities as part of deceptive and coercive activities, such as >>>robocalling (bulk unsolicited commercial communications), vishing >>>(voicemail hacking, and impersonating banks) and swatting >>>(impersonating callers to emergency services to stimulate unwarranted >>>large scale law enforcement deployments). This working group will >>>define a deployable mechanism to validate the identity of the calling >>>party that can be verified by entities in the path of a call. >>> >>> SIP is one of the main VoIP technologies used by parties that want to >>>present an incorrect origination. A number of previous efforts have >>>tried to secure the origins of SIP communications, including RFC 3325, >>>RFC 4474, and the VIPR working group. To date, however, true validation >>>of the source of SIP calls has not seen any appreciable deployment. >>>Several factors contributed to this lack of success, including: failure >>>of the problem to be seen as critical at the time; lack of any real >>>means of asserting authority over telephone numbers; misalignment of >>>the mechanisms proposed by RFC 4474 with the complex deployment >>>environment that has emerged for SIP; lack of end-to-end SIP session >>>establishment; and inherent operational problems with a transitive >>>trust model. >>> >>> Initially, the working group will specify an in-band mechanism to >>>authenticate the originator of a SIP session where the identity being >>>authenticated is a telephone number and the session is established with >>>SIP end to end. The working group will consider choices for protecting >>>the identity information and the credentials used, but will likely be >>>similar to the methods described in RFC 4474, which employs a signature >>>over a set of information in the SIP headers using a credential >>>assigned to the identity. In order to be authoritative, credentials >>>used with this mechanism will be derived from existing telephone number >>>assignment and delegation models. That is, when a telephone number or >>>range of telephone numbers is delegated to an entity, a credential will >>>accompany such delegation. The mechanism must allow parties who are >>>not delegated a telephone number, but are preauthorized by the entity >>>who is delegated the number, to place calls using the identity. >>>Expansion of=20 > t >> he >>> authentication mechanism to identities using the user@domain form >>>should be considered in the initial design. After completing the SIP >>>end to end solution, the working group will consider session >>>establishment where there are one or more non-SIP hops, most likely >>>using an out-of-band authentication mechanism. However, the in-band >>>and out-of-band mechanisms should share as much in common as possible, >>>especially the credentials. >>> >>> The working group will coordinate with the Security Area on credential >>>management. >>> >>> The working group will coordinate with other working groups in the RAI >>>Area regarding signaling through existing deployments, including >>>INSIPID. >>> >>> Authenticated identity is closely linked to privacy, and one >>>frequently 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. >>> >>> 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 >>> >>> The working group will deliver the following: >>> >>> - A problem statement detailing the deployment environment and >>> situation that motivate work on secure telephone identity >>> >>> - A mechanism document describing the SIP end-to-end with telephone >>> number-based identities >>> >>> - A document describing the credentials required to support secure >>> telephone identity >>> >>> - A fallback mechanism to allow out-of-band identity establishment >>> during call setup >>> >>> Milestones >>> >>> Sep 2013 Submit problem statement for Informational >>> Nov 2013 Submit RFC4474bis for Proposed Standard >>> Feb 2014 Submit credential specification for Proposed Standard >>> Jun 2014 Submit fallback for Proposed Standard >>> >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From dhc@dcrocker.net Thu Jul 11 10:38: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 2E3A721F9C0A for ; Thu, 11 Jul 2013 10:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.594 X-Spam-Level: X-Spam-Status: No, score=-6.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cWxG6PmrQIS for ; Thu, 11 Jul 2013 10:38:06 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF7421F9BB1 for ; Thu, 11 Jul 2013 10:38: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 r6BHbu5i013360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Jul 2013 10:37:59 -0700 Message-ID: <51DEED59.7020405@dcrocker.net> Date: Thu, 11 Jul 2013 10:37: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: "Rosen, Brian" References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <968DA52D-551E-47CA-B6F9-127A00820746@neustar.biz> <51DEE855.1060506@dcrocker.net> <05889381-CFB4-4E66-B978-FDAD242E989E@neustar.biz> In-Reply-To: <05889381-CFB4-4E66-B978-FDAD242E989E@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]); Thu, 11 Jul 2013 10:37:59 -0700 (PDT) Cc: Richard Barnes , Russ Housley , Gonzalo Camarillo , "DOLLY, MARTIN C" , "stir@ietf.org" , "" Subject: Re: [stir] Draft STIR 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, 11 Jul 2013 17:38:13 -0000 On 7/11/2013 10:23 AM, Rosen, Brian wrote: > We are trying to limit the scope. > > We do have an assumption that we're crypto-signing a set of info from > SIP headers using some kind of credential. We are assuming 4474-like > solutions. > > That might, in the end, not work, but yes, I think we should have to > justify a deviation. The way the text is written, we don't have to > recharter to change the approach. > > I think limiting scope and stating intended direction is helpful. It > makes it more of an engineering problem and less of a research > effort. Limiting scope is good. Unfortunately the cited text doesn't really achieve that. Rhere's no obvious and clear meaning to "similar to 4474". On the other hand, the phrase in your response is, I think, extremely clear and helpful. Cast as charterese, it would be something like: The solution is expected to be based on the use of cryptographic signing of a set of SIP headers, with authentication of the associated identifier employing some type of credential mechanism. I think such language is both technically meaningful and politically neutral, in that it entirely avoids any of the current set of controversies on the list. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hadriel.kaplan@oracle.com Thu Jul 11 10:40: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 A2DF721F9C06 for ; Thu, 11 Jul 2013 10:40:49 -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 wQPKe3hCvBkF for ; Thu, 11 Jul 2013 10:40:44 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7A25021F842E for ; Thu, 11 Jul 2013 10:40:44 -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 r6BHeUhM006987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Jul 2013 17:40:31 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 r6BHeTJ7009401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jul 2013 17:40:29 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6BHeTpb009389; Thu, 11 Jul 2013 17:40:29 GMT Received: from [192.168.2.80] (/184.74.74.115) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Jul 2013 10:40:28 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC13E48@EX2K10MB1.corp.yaanatech.com> Date: Thu, 11 Jul 2013 12:47:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <007201ce799a$34539360$9cfaba20$@shockey.us> <900A1E2059ADB149B905E3C8FA0046A62C77C39220@FHDP1LUMXC7V23.us.one.verizon.com> <01ad01ce7da0$5af26f00$10d74d00$@shockey.us> <52705969-970E-431A-9A9B-B24AAF69C082@oracle.com> <51DE3DDB.2000303@dcrocker.net> <00C069FD01E0324C9FFCADF539701DB3BBC13E48@EX2K10MB1.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "sanjay.mishra@verizon.com" , "stir@ietf.org" , "york@isoc.org" , "dcrocker@bbiw.net" , "Henning.Schulzrinne@fcc.gov" Subject: Re: [stir] Using Validated Numbers (was - Re: U.S. Senate hearing on robocalls July 10, 2013) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 17:40:49 -0000 I think he meant the NPAC. Even if the NPAC held the keys/certs, we'd still want a way to do STIR = delegation... because afaict the NPAC in its current form doesn't truly = know the ultimate service provider. It appears to only know the = regulated "carrier" the number is assigned to, but that's not the = ultimate service provider really. There are hundreds of providers who = aren't classified as "carriers", and don't want to be for legal/monetary = reasons. They pay a real "carrier" to handle the number porting, so the = NPAC only has that official carrier in its database instead of the = ultimate service provider. That official carrier could be the one to = sign the caller-id coming from its customer service providers, but we = probably need a way for the real originating service provider to do it = instead. -hadriel On Jul 11, 2013, at 10:36 AM, Michael Hammer = wrote: > Correct me if I am wrong, but I didn't think the LERG went to 10 = digits. >=20 > Mike >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of > Henning Schulzrinne > Sent: Thursday, July 11, 2013 10:00 AM > To: 'dcrocker@bbiw.net'; stir@ietf.org > Cc: 'Dan York'; 'Mishra, Sanjay' > Subject: Re: [stir] Using Validated Numbers (was - Re: U.S. Senate = hearing > on robocalls July 10, 2013) >=20 > A crucial component will be that=20 >=20 > (1) *all* calls from a certain number are validated > (2) the receiver can know that this is the case ("DANE") >=20 > (2) can be a heuristic, given (1), but obviously explicit information = is > better. That way, targets that are particularly susceptible to > individualized spoofing, such as financial institutions, can protect > themselves first, just like they did by implementing TLS early on = their web > sites. That would prevent a fair amount of vishing. If we can then get = the > large outbound call centers to "incent" their carriers, most people = will > then only get three kinds of calls: > (a) validated business calls > (b) known numbers from friends and family > (c) unvalidated calls that are very likely to be robocalls and can, at > least, be sent to voicemail and CAPTCHA >=20 > (2) may not be an Internet-facing directory, although that could be = quite > helpful. For example, this information could be contained in the LERG = or > other information made available by the numbering administrator. >=20 > -----Original Message----- > From: Dave Crocker [mailto:dhc@dcrocker.net]=20 > Sent: Thursday, July 11, 2013 1:09 AM > To: stir@ietf.org > Cc: 'Dan York'; 'Mishra, Sanjay'; Henning Schulzrinne > Subject: Using Validated Numbers (was - Re: [stir] U.S. Senate hearing = on > robocalls July 10, 2013) >=20 >=20 >> Regardless, none of the robocall-blocking tactics I've seen will do=20= >> much in the long run unless we get the caller-id's to at least be=20 >> authenticate-able. Once we know the caller-ids can't be randomly=20 >> generated or spoof legitimate sources, doing whitelist/blacklist=20 >> things will be a lot more tenable. >=20 >=20 > Dumb question, since it seems clear that most folk already have a = sense of > the answer: Once there are some telephone numbers getting validated, = how > will this get used and by what components in the system? >=20 > I'm asking for more detail that the above text has, so that it's = possible to > consider the specifics of what to change and how it will work, such as > during initial years of only partial adoption. >=20 > Over in email-abuse land, a wide range of assumptions were made about = the > use of authenticated names, but the actual uses have had some = surprises. >=20 > To the extent that there is agreement on the specific uses that are = planned > for validated telephone numbers, it can sometimes help to clarify > engineering choices for the validation mechanism. >=20 > d/ >=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 stephen.farrell@cs.tcd.ie Thu Jul 11 10: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 1727B21F9F3C for ; Thu, 11 Jul 2013 10:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.078, 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 0P-T+gC+VI+X for ; Thu, 11 Jul 2013 10:55: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 7E67921F9DE9 for ; Thu, 11 Jul 2013 10:55:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2DE46BEB3; Thu, 11 Jul 2013 18:54: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 MjgeUZAL5-pq; Thu, 11 Jul 2013 18:54:54 +0100 (IST) Received: from [10.87.48.9] (unknown [86.42.17.76]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B8D2ABEC0; Thu, 11 Jul 2013 18:54:53 +0100 (IST) Message-ID: <51DEF16D.2070909@cs.tcd.ie> Date: Thu, 11 Jul 2013 18:54:53 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Russ Housley References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Richard Barnes , stir@ietf.org, Gonzalo Camarillo , Brian Rosen Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 17:55:40 -0000 Hi Russ, I think this looks pretty good. A few wordsmithing changes and a question below but I have one addition to suggest: Somewhere this should say that the solution chosen needs to have an acceptable overhead at both signer and verifer or else it also won't be deployed. There may be some on here who could suggest indicative timing or networking constraints (e.g. not having to do ~5 OCSP transactions to possibly anywhere in the world) and if so, that'd be a good thing to include IMO. On 07/11/2013 03:21 PM, Russ Housley wrote: > Dear STIR Mail List Participants: > > Brian and I have tried to pull together charter text based on the > discussion to date. > > The closer we can get to consensus on the list before the BOF, the > more likely that we can get a WG shortly after Berlin. To this end, > please review and comment on the attached text. Brian and I will > hold the pen for updates to the text. > > Russ > > = = = = = > > Name: Secure Telephone Identity Revisited (stir) Area: RAI > > Chairs: TBD Area Advisor: Richard Barnes > > Mailing list: stir@ietf.org To Subscribe: > https://www.ietf.org/mailman/listinfo/stir > > 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. As with email, the claimed source identity > of a SIP request is not verified, and this permits unauthorized use > of source identities as part of deceptive and coercive activities, > such as robocalling (bulk unsolicited commercial communications), > vishing (voicemail hacking, and impersonating banks) and swatting > (impersonating callers to emergency services to stimulate unwarranted > large scale law enforcement deployments). This working group will > define a deployable mechanism to validate the identity of the calling > party that can be verified by entities in the path of a call. > > SIP is one of the main VoIP technologies used by parties that want to > present an incorrect origination. A number of previous efforts have > tried to secure the origins of SIP communications, including RFC > 3325, RFC 4474, and the VIPR working group. To date, however, true > validation of the source of SIP calls has not seen any appreciable > deployment. Several factors contributed to this lack of success, > including: failure of the problem to be seen as critical at the time; > lack of any real means of asserting authority over telephone numbers; > misalignment of the mechanisms proposed by RFC 4474 with the complex > deployment environment that has emerged for SIP; lack of end-to-end > SIP session establishment; and inherent operational problems with a > transitive trust model. > > Initially, the working group will specify an in-band mechanism to > authenticate the originator of a SIP session where the identity being > authenticated is a telephone number and the session is established > with SIP end to end. The working group will consider choices for > protecting the identity information and the credentials used, but > will likely be similar to the methods described in RFC 4474, which > employs a signature over a set of information in the SIP headers > using a credential assigned to the identity. I suggest replacing the above with "will likely be based on a digital signature mechanism that is cryptographically similar to the one described in RFC 4474 and where the signature continues to be represented in SIP headers." Saying "methods" and 4474 is a bit vague and could be read to mean "s/mime-based" or "cms based" or "x.509 based" whereas what I think we want is just to say its a signature. Similarly "assigned to the identity" is very ambiguous and probably better just omitted for now. > In order to be > authoritative, credentials used with this mechanism will be derived > from existing telephone number assignment and delegation models. No specific change suggested but are we using credential here to mean the private key or a (set of) TN(s) associated with a public key? I think it ought be the latter. > That is, when a telephone number or range of telephone numbers is > delegated to an entity, a credential will accompany such delegation. That's problematic with either definition of credential. I think it'd be ok to say: That is, when a telephone number or range of telephone numbers is delegated to an entity, relevant credentials will be generated (or modified) to reflect such delegation. > The mechanism must allow parties who are not delegated a telephone > number, but are preauthorized by the entity who is delegated the > number, to place calls using the identity. No specific change suggested, but I've always wondered if this requirement is real. I'd argue enough good would be done without try to stretch for this. But I defer to those who know more about the application. > Expansion of the > authentication mechanism to identities using the user@domain form > should be considered in the initial design. To be honest, I didn't read that thread (one too many:-) but I'm surprised that this is to be part of the initial design. But "considered" is sort of weasel-wordy so I'm not sure what's really meant - what is "considered" meant to mean here? Cheers, S. > After completing the SIP > end to end solution, the working group will consider session > establishment where there are one or more non-SIP hops, most likely > using an out-of-band authentication mechanism. However, the in-band > and out-of-band mechanisms should share as much in common as > possible, especially the credentials. > > The working group will coordinate with the Security Area on > credential management. > > The working group will coordinate with other working groups in the > RAI Area regarding signaling through existing deployments, including > INSIPID. > > Authenticated identity is closely linked to privacy, and one > frequently 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. > > 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 > > The working group will deliver the following: > > - A problem statement detailing the deployment environment and > situation that motivate work on secure telephone identity > > - A mechanism document describing the SIP end-to-end with telephone > number-based identities > > - A document describing the credentials required to support secure > telephone identity > > - A fallback mechanism to allow out-of-band identity establishment > during call setup > > Milestones > > Sep 2013 Submit problem statement for Informational Nov 2013 > Submit RFC4474bis for Proposed Standard Feb 2014 Submit credential > specification for Proposed Standard Jun 2014 Submit fallback for > Proposed Standard > > _______________________________________________ stir mailing list > stir@ietf.org https://www.ietf.org/mailman/listinfo/stir > > From br@brianrosen.net Thu Jul 11 10:55: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 2551B21F9C90 for ; Thu, 11 Jul 2013 10:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.221 X-Spam-Level: X-Spam-Status: No, score=-100.221 tagged_above=-999 required=5 tests=[AWL=0.216, 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 2kTEHJjYUTOG for ; Thu, 11 Jul 2013 10:55:40 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 9B97521F9DE9 for ; Thu, 11 Jul 2013 10:55:40 -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=e7ZZgHaeaQDhU2kBtelXNhqxT296ZJsoQC+LcbMz2Fw=; b=iBYmxUiY33bKqg8g3W/xYopoYMJsMGIp0fWpeMy2NA7oMboZKli9uSRLR6kRgQG5me1TTp8G1qX7Dea/TMnHeNW8QMmHVXe2ZOErzDDDeI2byJSmttOjhiMVj7HfToOcbnCz14v4DCZPGHtLFOVu+dOXgSNdFSLq7aIsY//niTk=; Received: from neustargw.va.neustar.com ([209.173.53.233]:44908 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UxL5R-0006XA-4q; Thu, 11 Jul 2013 13:55:25 -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, 11 Jul 2013 13:55:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <007201ce799a$34539360$9cfaba20$@shockey.us> <900A1E2059ADB149B905E3C8FA0046A62C77C39220@FHDP1LUMXC7V23.us.one.verizon.com> <01ad01ce7da0$5af26f00$10d74d00$@shockey.us> <52705969-970E-431A-9A9B-B24AAF69C082@oracle.com> <51DE3DDB.2000303@dcrocker.net> <00C069FD01E0324C9FFCADF539701DB3BBC13E48@EX2K10MB1.corp.yaanatech.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: "york@isoc.org" , "sanjay.mishra@verizon.com" , "stir@ietf.org" , "dcrocker@bbiw.net" , Michael Hammer , "Henning.Schulzrinne@fcc.gov" Subject: Re: [stir] Using Validated Numbers (was - Re: U.S. Senate hearing on robocalls July 10, 2013) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 17:55:45 -0000 This is very US specific, but NPAC has two fields called "AltSPID" and "LastAltSPID", which are = intended to hold SP IDs for number resell. They are used in that way = for several specific purposes, including the iTRS directory, where it = holds the VRS or IP Relay provider SPID, and they are not "carriers". Unfortunately, it has only the two fields, and the first is for the = customer of the "carrier" and the last is for the SP the customer knows. = There could have been several other number delegations between them, = which could not be recorded. Use of these fields is optional for the = carrier, but many carriers are beginning to do so. It would be fairly easy to add the additional fields to capture the = intermediate SPs, but doing so requires work at LNPA and in the NPAC = code, although the latter is a greased pole (we like adding fields). = Associating certs with these records would be additional work, of = course. Brian On Jul 11, 2013, at 12:47 PM, Hadriel Kaplan = wrote: >=20 > I think he meant the NPAC. >=20 > Even if the NPAC held the keys/certs, we'd still want a way to do STIR = delegation... because afaict the NPAC in its current form doesn't truly = know the ultimate service provider. It appears to only know the = regulated "carrier" the number is assigned to, but that's not the = ultimate service provider really. There are hundreds of providers who = aren't classified as "carriers", and don't want to be for legal/monetary = reasons. They pay a real "carrier" to handle the number porting, so the = NPAC only has that official carrier in its database instead of the = ultimate service provider. That official carrier could be the one to = sign the caller-id coming from its customer service providers, but we = probably need a way for the real originating service provider to do it = instead. >=20 > -hadriel >=20 >=20 > On Jul 11, 2013, at 10:36 AM, Michael Hammer = wrote: >=20 >> Correct me if I am wrong, but I didn't think the LERG went to 10 = digits. >>=20 >> Mike >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of >> Henning Schulzrinne >> Sent: Thursday, July 11, 2013 10:00 AM >> To: 'dcrocker@bbiw.net'; stir@ietf.org >> Cc: 'Dan York'; 'Mishra, Sanjay' >> Subject: Re: [stir] Using Validated Numbers (was - Re: U.S. Senate = hearing >> on robocalls July 10, 2013) >>=20 >> A crucial component will be that=20 >>=20 >> (1) *all* calls from a certain number are validated >> (2) the receiver can know that this is the case ("DANE") >>=20 >> (2) can be a heuristic, given (1), but obviously explicit information = is >> better. That way, targets that are particularly susceptible to >> individualized spoofing, such as financial institutions, can protect >> themselves first, just like they did by implementing TLS early on = their web >> sites. That would prevent a fair amount of vishing. If we can then = get the >> large outbound call centers to "incent" their carriers, most people = will >> then only get three kinds of calls: >> (a) validated business calls >> (b) known numbers from friends and family >> (c) unvalidated calls that are very likely to be robocalls and can, = at >> least, be sent to voicemail and CAPTCHA >>=20 >> (2) may not be an Internet-facing directory, although that could be = quite >> helpful. For example, this information could be contained in the LERG = or >> other information made available by the numbering administrator. >>=20 >> -----Original Message----- >> From: Dave Crocker [mailto:dhc@dcrocker.net]=20 >> Sent: Thursday, July 11, 2013 1:09 AM >> To: stir@ietf.org >> Cc: 'Dan York'; 'Mishra, Sanjay'; Henning Schulzrinne >> Subject: Using Validated Numbers (was - Re: [stir] U.S. Senate = hearing on >> robocalls July 10, 2013) >>=20 >>=20 >>> Regardless, none of the robocall-blocking tactics I've seen will do=20= >>> much in the long run unless we get the caller-id's to at least be=20 >>> authenticate-able. Once we know the caller-ids can't be randomly=20 >>> generated or spoof legitimate sources, doing whitelist/blacklist=20 >>> things will be a lot more tenable. >>=20 >>=20 >> Dumb question, since it seems clear that most folk already have a = sense of >> the answer: Once there are some telephone numbers getting validated, = how >> will this get used and by what components in the system? >>=20 >> I'm asking for more detail that the above text has, so that it's = possible to >> consider the specifics of what to change and how it will work, such = as >> during initial years of only partial adoption. >>=20 >> Over in email-abuse land, a wide range of assumptions were made about = the >> use of authenticated names, but the actual uses have had some = surprises. >>=20 >> To the extent that there is agreement on the specific uses that are = planned >> for validated telephone numbers, it can sometimes help to clarify >> engineering choices for the validation mechanism. >>=20 >> d/ >>=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 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From brian.rosen@neustar.biz Thu Jul 11 11:11: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 05A2321F9A78 for ; Thu, 11 Jul 2013 11:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9Vz7TtrK4Dh for ; Thu, 11 Jul 2013 11:11:14 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 7081921F9F62 for ; Thu, 11 Jul 2013 11:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1373566771; x=1688920882; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=vnQ1vpZfNj l7FqvA4c4mzatyAkGZqHj2Ui+byt7YDcA=; b=FoqtuPGyA2mPnCuTWD+haDgXPE o7QzERbqmBbC77WCu9P+WHwa4rNWNCsphFTp017GIGzfsVkGV1WNeaBcTnNQ== Received: from ([10.31.58.69]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.27753311; Thu, 11 Jul 2013 14:19:30 -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, 11 Jul 2013 14:11:00 -0400 From: "Rosen, Brian" To: Stephen Farrell Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkH7PavsqszcIEumRBC5KQ07J5lgBgeAgAAEgIA= Date: Thu, 11 Jul 2013 18:11:00 +0000 Message-ID: References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> In-Reply-To: <51DEF16D.2070909@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.192.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 4pNnPVi1OOiRG2dOwuOPmQ== Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Richard Barnes , "" , Russ Housley , Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 18:11:18 -0000 Inline On Jul 11, 2013, at 1:54 PM, Stephen Farrell wr= ote: >=20 > Hi Russ, >=20 > I think this looks pretty good. A few wordsmithing changes > and a question below but I have one addition to suggest: >=20 > Somewhere this should say that the solution chosen needs to > have an acceptable overhead at both signer and verifer or > else it also won't be deployed. There may be some on here > who could suggest indicative timing or networking constraints > (e.g. not having to do ~5 OCSP transactions to possibly > anywhere in the world) and if so, that'd be a good thing > to include IMO. I'll think about how to add some text for this. I think "deployable" is re= ally, really important in this effort. >=20 > On 07/11/2013 03:21 PM, Russ Housley wrote: >> Dear STIR Mail List Participants: >>=20 >> Brian and I have tried to pull together charter text based on the >> discussion to date. >>=20 >> The closer we can get to consensus on the list before the BOF, the >> more likely that we can get a WG shortly after Berlin. To this end, >> please review and comment on the attached text. Brian and I will >> hold the pen for updates to the text. >>=20 >> Russ >>=20 >> =3D =3D =3D =3D =3D >>=20 >> Name: Secure Telephone Identity Revisited (stir) Area: RAI >>=20 >> Chairs: TBD Area Advisor: Richard Barnes >>=20 >> Mailing list: stir@ietf.org To Subscribe: >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> 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. As with email, the claimed source identity >> of a SIP request is not verified, and this permits unauthorized use >> of source identities as part of deceptive and coercive activities, >> such as robocalling (bulk unsolicited commercial communications), >> vishing (voicemail hacking, and impersonating banks) and swatting >> (impersonating callers to emergency services to stimulate unwarranted >> large scale law enforcement deployments). This working group will >> define a deployable mechanism to validate the identity of the calling >> party that can be verified by entities in the path of a call. >>=20 >> SIP is one of the main VoIP technologies used by parties that want to >> present an incorrect origination. A number of previous efforts have >> tried to secure the origins of SIP communications, including RFC >> 3325, RFC 4474, and the VIPR working group. To date, however, true >> validation of the source of SIP calls has not seen any appreciable >> deployment. Several factors contributed to this lack of success, >> including: failure of the problem to be seen as critical at the time; >> lack of any real means of asserting authority over telephone numbers; >> misalignment of the mechanisms proposed by RFC 4474 with the complex >> deployment environment that has emerged for SIP; lack of end-to-end >> SIP session establishment; and inherent operational problems with a >> transitive trust model. >>=20 >> Initially, the working group will specify an in-band mechanism to >> authenticate the originator of a SIP session where the identity being >> authenticated is a telephone number and the session is established >> with SIP end to end. The working group will consider choices for >> protecting the identity information and the credentials used, but >> will likely be similar to the methods described in RFC 4474, which >> employs a signature over a set of information in the SIP headers >> using a credential assigned to the identity. >=20 > I suggest replacing the above with >=20 > "will likely be based on a digital signature mechanism that is > cryptographically similar to the one described in RFC 4474 and > where the signature continues to be represented in SIP headers." >=20 > Saying "methods" and 4474 is a bit vague and could be read to > mean "s/mime-based" or "cms based" or "x.509 based" whereas > what I think we want is just to say its a signature. >=20 > Similarly "assigned to the identity" is very ambiguous and > probably better just omitted for now. We're discussing changes to this text on this thread. >=20 >=20 >> In order to be >> authoritative, credentials used with this mechanism will be derived >> from existing telephone number assignment and delegation models. >=20 > No specific change suggested but are we using credential here to > mean the private key or a (set of) TN(s) associated with a > public key? I think it ought be the latter. Of course it's both - the sender needs the private key to sign and the ver= ifier needs the public key to verify, so "credentials" means both. We're trying not to start with a firm assumption of X.509 certs, so it's in= tentionally somewhat vague. A credential is associated with a (set of) TN(s). >=20 >> That is, when a telephone number or range of telephone numbers is >> delegated to an entity, a credential will accompany such delegation. >=20 > That's problematic with either definition of credential. I think > it'd be ok to say: >=20 > That is, when a telephone number or range of telephone numbers is > delegated to an entity, relevant credentials will be generated (or > modified) to reflect such delegation. I am fine making this edit >=20 >> The mechanism must allow parties who are not delegated a telephone >> number, but are preauthorized by the entity who is delegated the >> number, to place calls using the identity. =20 >=20 > No specific change suggested, but I've always wondered if this > requirement is real. I'd argue enough good would be done without > try to stretch for this. But I defer to those who know more about > the application. It's very real and we could not deploy without it. An easy example is a co= ntracted outbound call center operating on behalf of your bank. The bank w= ants it's number used as the calling party number, not the call center's tr= unk assignment. Among other things, it wants a return call resulting from = the outbound call. The bank explicitly permits this. In our terms, it wou= ld do another level of delegation. >=20 >> Expansion of the >> authentication mechanism to identities using the user@domain form >> should be considered in the initial design. =20 >=20 > To be honest, I didn't read that thread (one too many:-) but I'm > surprised that this is to be part of the initial design. But > "considered" is sort of weasel-wordy so I'm not sure what's > really meant - what is "considered" meant to mean here? The problem we're solving is existing robocalling, vishing and swatting, wh= ich presently is TN based. I think we all want to anticipate greenfield si= p uri's, lest we fix one problem and cause another. >=20 > Cheers, > S. >=20 >> After completing the SIP >> end to end solution, the working group will consider session >> establishment where there are one or more non-SIP hops, most likely >> using an out-of-band authentication mechanism. However, the in-band >> and out-of-band mechanisms should share as much in common as >> possible, especially the credentials. >>=20 >> The working group will coordinate with the Security Area on >> credential management. >>=20 >> The working group will coordinate with other working groups in the >> RAI Area regarding signaling through existing deployments, including >> INSIPID. >>=20 >> Authenticated identity is closely linked to privacy, and one >> frequently 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 >> 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=20 >> http://tools.ietf.org/html/draft-cooper-iab-secure-origin-00 >>=20 >> Secure Origin Identification: Problem Statement, Requirements, and >> Roadmap=20 >> http://tools.ietf.org/html/draft-peterson-secure-origin-ps-00 >>=20 >> Authenticated Identity Management in the Session Initiation Protocol >> (SIP)=20 >> http://tools.ietf.org/html/draft-jennings-dispatch-rfc4474bis-00 >>=20 >> The working group will deliver the following: >>=20 >> - A problem statement detailing the deployment environment and=20 >> situation that motivate work on secure telephone identity >>=20 >> - A mechanism document describing the SIP end-to-end with telephone=20 >> number-based identities >>=20 >> - A document describing the credentials required to support secure=20 >> telephone identity >>=20 >> - A fallback mechanism to allow out-of-band identity establishment=20 >> during call setup >>=20 >> Milestones >>=20 >> Sep 2013 Submit problem statement for Informational Nov 2013 >> Submit RFC4474bis for Proposed Standard Feb 2014 Submit credential >> specification for Proposed Standard Jun 2014 Submit fallback for >> Proposed Standard >>=20 >> _______________________________________________ stir mailing list=20 >> stir@ietf.org https://www.ietf.org/mailman/listinfo/stir >>=20 >>=20 From richard@shockey.us Thu Jul 11 11:17: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 8BDB621F9E94 for ; Thu, 11 Jul 2013 11:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.659 X-Spam-Level: X-Spam-Status: No, score=-101.659 tagged_above=-999 required=5 tests=[AWL=0.606, 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 jPlkH6-Y9ghs for ; Thu, 11 Jul 2013 11:17: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 1F69321F9396 for ; Thu, 11 Jul 2013 11:17:36 -0700 (PDT) Received: (qmail 24616 invoked by uid 0); 11 Jul 2013 18:09:28 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy14.unifiedlayer.com with SMTP; 11 Jul 2013 18:09: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:In-Reply-To:References:Cc:To:From; bh=2LnS/HC8aq8WWxZEhFdmoBwbJW6jwpaIecVB7x7kjNc=; b=Gb3Gb6ygwUmg+OXBmEN06scmK1WC+W6tydWwZzzZ6/RTuDvDa7ZUaKf5/dCcjq4zYRT2mAT2VqeZzMXk5J+YK2P6IE9bx9JlK6XiosPZQCwPuayyXc9KeoIohwuwmCeW; Received: from [72.66.111.124] (port=53509 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UxLH4-0004p5-9u; Thu, 11 Jul 2013 12:07:26 -0600 From: "Richard Shockey" To: "'Hadriel Kaplan'" , "'Michael Hammer'" References: , <007201ce799a$34539360$9cfaba20$@shockey.us> <900A1E2059ADB149B905E3C8FA0046A62C77C39220@FHDP1LUMXC7V23.us.one.verizon.com> <01ad01ce7da0$5af26f00$10d74d00$@shockey.us> <52705969-970E-431A-9A9B-B24AAF69C082@oracle.com> <51DE3DDB.2000303@dcrocker.net> <00C069FD01E0324C9FFCADF539701DB3BBC13E48@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Date: Thu, 11 Jul 2013 14:07:22 -0400 Message-ID: <00fe01ce7e61$7f02a3d0$7d07eb70$@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: AQHodzCA9LgCAfhuWd/FCK4mTC0xcwHl+TKPAd+zOkYCZJUWewIb/khJAeRXx3cBxiujuQFk6TZcAV2G8OECLT/tIAHXhWlbmJYRCWA= 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@fcc.gov, york@isoc.org, sanjay.mishra@verizon.com, dcrocker@bbiw.net Subject: Re: [stir] Using Validated Numbers (was - Re: U.S. Senate hearing on robocalls July 10, 2013) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 18:17:40 -0000 Well they are all 10 digit .. but the NPAC has both the OCN, the NECA Operator Carrier Number as well as the SPID ALT-SPID identifiers which is honored by the secondary carrier often in the breach. This is an excellent point BTW that the structure of the existing national numbering databases (plural!) must in some way shape or form be modified to reflect the delegation model for a E.164 number. This highlights again the general issue that STIR is not in and of itself a silver bullet but will require some matched actions by the National Regulators to implement properly. What are the Roles and Responsibilities of the Carrier of Record for both the entity that has direct access to the NANPA and the secondary operator who is not licensed to directly access the NANP. Though this discussion focuses on the North Americian problem it will be perfectly applicable to other national jurisdictions when the issue arises. That is precisely the subject of the open Comment Period at the FCC on Numbering. 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 ! -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Thursday, July 11, 2013 12:47 PM To: Michael Hammer Cc: sanjay.mishra@verizon.com; stir@ietf.org; york@isoc.org; dcrocker@bbiw.net; Henning.Schulzrinne@fcc.gov Subject: Re: [stir] Using Validated Numbers (was - Re: U.S. Senate hearing on robocalls July 10, 2013) I think he meant the NPAC. Even if the NPAC held the keys/certs, we'd still want a way to do STIR delegation... because afaict the NPAC in its current form doesn't truly know the ultimate service provider. It appears to only know the regulated "carrier" the number is assigned to, but that's not the ultimate service provider really. There are hundreds of providers who aren't classified as "carriers", and don't want to be for legal/monetary reasons. They pay a real "carrier" to handle the number porting, so the NPAC only has that official carrier in its database instead of the ultimate service provider. That official carrier could be the one to sign the caller-id coming from its customer service providers, but we probably need a way for the real originating service provider to do it instead. -hadriel On Jul 11, 2013, at 10:36 AM, Michael Hammer wrote: > Correct me if I am wrong, but I didn't think the LERG went to 10 digits. > > Mike > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of Henning Schulzrinne > Sent: Thursday, July 11, 2013 10:00 AM > To: 'dcrocker@bbiw.net'; stir@ietf.org > Cc: 'Dan York'; 'Mishra, Sanjay' > Subject: Re: [stir] Using Validated Numbers (was - Re: U.S. Senate > hearing on robocalls July 10, 2013) > > A crucial component will be that > > (1) *all* calls from a certain number are validated > (2) the receiver can know that this is the case ("DANE") > > (2) can be a heuristic, given (1), but obviously explicit information > is better. That way, targets that are particularly susceptible to > individualized spoofing, such as financial institutions, can protect > themselves first, just like they did by implementing TLS early on > their web sites. That would prevent a fair amount of vishing. If we > can then get the large outbound call centers to "incent" their > carriers, most people will then only get three kinds of calls: > (a) validated business calls > (b) known numbers from friends and family > (c) unvalidated calls that are very likely to be robocalls and can, at > least, be sent to voicemail and CAPTCHA > > (2) may not be an Internet-facing directory, although that could be > quite helpful. For example, this information could be contained in the > LERG or other information made available by the numbering administrator. > > -----Original Message----- > From: Dave Crocker [mailto:dhc@dcrocker.net] > Sent: Thursday, July 11, 2013 1:09 AM > To: stir@ietf.org > Cc: 'Dan York'; 'Mishra, Sanjay'; Henning Schulzrinne > Subject: Using Validated Numbers (was - Re: [stir] U.S. Senate hearing > on robocalls July 10, 2013) > > >> Regardless, none of the robocall-blocking tactics I've seen will do >> much in the long run unless we get the caller-id's to at least be >> authenticate-able. Once we know the caller-ids can't be randomly >> generated or spoof legitimate sources, doing whitelist/blacklist >> things will be a lot more tenable. > > > Dumb question, since it seems clear that most folk already have a > sense of the answer: Once there are some telephone numbers getting > validated, how will this get used and by what components in the system? > > I'm asking for more detail that the above text has, so that it's > possible to consider the specifics of what to change and how it will > work, such as during initial years of only partial adoption. > > Over in email-abuse land, a wide range of assumptions were made about > the use of authenticated names, but the actual uses have had some surprises. > > To the extent that there is agreement on the specific uses that are > planned for validated telephone numbers, it can sometimes help to > clarify engineering choices for the validation mechanism. > > 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 stephen.farrell@cs.tcd.ie Thu Jul 11 11: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 B580E11E8112 for ; Thu, 11 Jul 2013 11:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 L8ZjlCpxD5Ib for ; Thu, 11 Jul 2013 11:23: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 C7EF011E8141 for ; Thu, 11 Jul 2013 11:23:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 05E57BEA1; Thu, 11 Jul 2013 19:23:20 +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 hKBR8T++9D4m; Thu, 11 Jul 2013 19:23:18 +0100 (IST) Received: from [10.87.48.9] (unknown [86.42.17.76]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A1589BE9C; Thu, 11 Jul 2013 19:23:17 +0100 (IST) Message-ID: <51DEF814.9080704@cs.tcd.ie> Date: Thu, 11 Jul 2013 19:23:16 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Rosen, Brian" References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Richard Barnes , "" , Russ Housley , Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 18:23:55 -0000 Hiya, Sorry one other thing I forgot before. There was a longish thread on what's a phone number (full E.164, local etc.) that I thought did reach a sort of conclusion that full E.164 will be the thing that is signed. If that's your and Russ' reading of the result then it might be good to say that too. If you and Russ are less sure then I guess the current text is right. And a little more below... On 07/11/2013 07:11 PM, Rosen, Brian wrote: > Inline On Jul 11, 2013, at 1:54 PM, Stephen Farrell > wrote: > >> >> Hi Russ, >> >> I think this looks pretty good. A few wordsmithing changes and a >> question below but I have one addition to suggest: >> >> Somewhere this should say that the solution chosen needs to have an >> acceptable overhead at both signer and verifer or else it also >> won't be deployed. There may be some on here who could suggest >> indicative timing or networking constraints (e.g. not having to do >> ~5 OCSP transactions to possibly anywhere in the world) and if so, >> that'd be a good thing to include IMO. > I'll think about how to add some text for this. I think "deployable" > is really, really important in this effort. Fully agree and look forward to seeing that text. >> >> On 07/11/2013 03:21 PM, Russ Housley wrote: >>> Dear STIR Mail List Participants: >>> >>> Brian and I have tried to pull together charter text based on >>> the discussion to date. >>> >>> The closer we can get to consensus on the list before the BOF, >>> the more likely that we can get a WG shortly after Berlin. To >>> this end, please review and comment on the attached text. Brian >>> and I will hold the pen for updates to the text. >>> >>> Russ >>> >>> = = = = = >>> >>> Name: Secure Telephone Identity Revisited (stir) Area: RAI >>> >>> Chairs: TBD Area Advisor: Richard Barnes >>> >>> Mailing list: stir@ietf.org To Subscribe: >>> https://www.ietf.org/mailman/listinfo/stir >>> >>> 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. As with email, the claimed source >>> identity of a SIP request is not verified, and this permits >>> unauthorized use of source identities as part of deceptive and >>> coercive activities, such as robocalling (bulk unsolicited >>> commercial communications), vishing (voicemail hacking, and >>> impersonating banks) and swatting (impersonating callers to >>> emergency services to stimulate unwarranted large scale law >>> enforcement deployments). This working group will define a >>> deployable mechanism to validate the identity of the calling >>> party that can be verified by entities in the path of a call. >>> >>> SIP is one of the main VoIP technologies used by parties that >>> want to present an incorrect origination. A number of previous >>> efforts have tried to secure the origins of SIP communications, >>> including RFC 3325, RFC 4474, and the VIPR working group. To >>> date, however, true validation of the source of SIP calls has not >>> seen any appreciable deployment. Several factors contributed to >>> this lack of success, including: failure of the problem to be >>> seen as critical at the time; lack of any real means of asserting >>> authority over telephone numbers; misalignment of the mechanisms >>> proposed by RFC 4474 with the complex deployment environment that >>> has emerged for SIP; lack of end-to-end SIP session >>> establishment; and inherent operational problems with a >>> transitive trust model. >>> >>> Initially, the working group will specify an in-band mechanism >>> to authenticate the originator of a SIP session where the >>> identity being authenticated is a telephone number and the >>> session is established with SIP end to end. The working group >>> will consider choices for protecting the identity information and >>> the credentials used, but will likely be similar to the methods >>> described in RFC 4474, which employs a signature over a set of >>> information in the SIP headers using a credential assigned to the >>> identity. >> >> I suggest replacing the above with >> >> "will likely be based on a digital signature mechanism that is >> cryptographically similar to the one described in RFC 4474 and >> where the signature continues to be represented in SIP headers." >> >> Saying "methods" and 4474 is a bit vague and could be read to mean >> "s/mime-based" or "cms based" or "x.509 based" whereas what I think >> we want is just to say its a signature. >> >> Similarly "assigned to the identity" is very ambiguous and probably >> better just omitted for now. > We're discussing changes to this text on this thread. Yeah. Consider the above another suggestion along the lines of what (I think) Dave was getting at (I think - I've been known to get that wrong before:-) >>> In order to be authoritative, credentials used with this >>> mechanism will be derived from existing telephone number >>> assignment and delegation models. >> >> No specific change suggested but are we using credential here to >> mean the private key or a (set of) TN(s) associated with a public >> key? I think it ought be the latter. > Of course it's both - the sender needs the private key to sign and > the verifier needs the public key to verify, so "credentials" means > both. We're trying not to start with a firm assumption of X.509 > certs, so it's intentionally somewhat vague. A credential is > associated with a (set of) TN(s). Probably best to leave the precise definition to the WG so I won't quibble with the above (yet:-). >>> That is, when a telephone number or range of telephone numbers >>> is delegated to an entity, a credential will accompany such >>> delegation. >> >> That's problematic with either definition of credential. I think >> it'd be ok to say: >> >> That is, when a telephone number or range of telephone numbers is >> delegated to an entity, relevant credentials will be generated (or >> modified) to reflect such delegation. > I am fine making this edit Great. >>> The mechanism must allow parties who are not delegated a >>> telephone number, but are preauthorized by the entity who is >>> delegated the number, to place calls using the identity. >> >> No specific change suggested, but I've always wondered if this >> requirement is real. I'd argue enough good would be done without >> try to stretch for this. But I defer to those who know more about >> the application. > It's very real and we could not deploy without it. An easy example > is a contracted outbound call center operating on behalf of your > bank. The bank wants it's number used as the calling party number, > not the call center's trunk assignment. Among other things, it wants > a return call resulting from the outbound call. The bank explicitly > permits this. In our terms, it would do another level of > delegation. Fair enough. > > >> >>> Expansion of the authentication mechanism to identities using the >>> user@domain form should be considered in the initial design. >> >> To be honest, I didn't read that thread (one too many:-) but I'm >> surprised that this is to be part of the initial design. But >> "considered" is sort of weasel-wordy so I'm not sure what's really >> meant - what is "considered" meant to mean here? > The problem we're solving is existing robocalling, vishing and > swatting, which presently is TN based. I think we all want to > anticipate greenfield sip uri's, lest we fix one problem and cause > another. So your response doesn't help me interpret "considered." Maybe it is meant as weasel-wording and sometimes that is the right thing to do, but I suspect it reads a bit too strong - as if the WG are gonna spend a lot of time on non-E.164 names so I'd say weakening it at least and ideally being more precise about what "considered" means would be good and might avoid later problems. Cheers, S. > >> >> Cheers, S. >> >>> After completing the SIP end to end solution, the working group >>> will consider session establishment where there are one or more >>> non-SIP hops, most likely using an out-of-band authentication >>> mechanism. However, the in-band and out-of-band mechanisms >>> should share as much in common as possible, especially the >>> credentials. >>> >>> The working group will coordinate with the Security Area on >>> credential management. >>> >>> The working group will coordinate with other working groups in >>> the RAI Area regarding signaling through existing deployments, >>> including INSIPID. >>> >>> Authenticated identity is closely linked to privacy, and one >>> frequently 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. >>> >>> 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 >>> >>> The working group will deliver the following: >>> >>> - A problem statement detailing the deployment environment and >>> situation that motivate work on secure telephone identity >>> >>> - A mechanism document describing the SIP end-to-end with >>> telephone number-based identities >>> >>> - A document describing the credentials required to support >>> secure telephone identity >>> >>> - A fallback mechanism to allow out-of-band identity >>> establishment during call setup >>> >>> Milestones >>> >>> Sep 2013 Submit problem statement for Informational Nov 2013 >>> Submit RFC4474bis for Proposed Standard Feb 2014 Submit >>> credential specification for Proposed Standard Jun 2014 Submit >>> fallback for Proposed Standard >>> >>> _______________________________________________ stir mailing list >>> stir@ietf.org https://www.ietf.org/mailman/listinfo/stir >>> >>> > > _______________________________________________ stir mailing list > stir@ietf.org https://www.ietf.org/mailman/listinfo/stir > > From brian.rosen@neustar.biz Thu Jul 11 11:29: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 165A621F9C69 for ; Thu, 11 Jul 2013 11:29:27 -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.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSvugikLc+H6 for ; Thu, 11 Jul 2013 11:29:23 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFCE21F9E00 for ; Thu, 11 Jul 2013 11:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1373567856; x=1688920882; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=1Y3wXzfGFK E+HuiIBBD2yBHkcNTE36RsaMNKreRzP3s=; b=Hd5G6wPMeQKP2kbpYQg7S+dMWy 0MBCYM4ItxjYHFXEa1D3Pk7Kzou74tqdaO69Ru8ypiXU6/ESAaYhc6DfKE4A== Received: from ([10.31.58.69]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.27754621; Thu, 11 Jul 2013 14:37:35 -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, 11 Jul 2013 14:29:07 -0400 From: "Rosen, Brian" To: Stephen Farrell Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkH7PavsqszcIEumRBC5KQ07J5lgBgeAgAAEgICAAANvAIAAAaEA Date: Thu, 11 Jul 2013 18:29:06 +0000 Message-ID: <66490626-323F-46DF-8D22-D1677C17FE76@neustar.biz> References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <51DEF814.9080704@cs.tcd.ie> In-Reply-To: <51DEF814.9080704@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.192.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: SAWSOH0S08AcCHRPpqjNbQ== Content-Type: text/plain; charset="iso-8859-1" Content-ID: <546992B3D7875D4FBBA8A4D6FA0FE818@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Richard Barnes , "" , Russ Housley , Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 18:29:27 -0000 So maybe where we say "where the identity being authenticated is a telephon= e number" add "in e.164 format"? Brian On Jul 11, 2013, at 2:23 PM, Stephen Farrell wrote: >=20 > Hiya, >=20 > Sorry one other thing I forgot before. There was a longish thread > on what's a phone number (full E.164, local etc.) that I thought > did reach a sort of conclusion that full E.164 will be the thing > that is signed. If that's your and Russ' reading of the result > then it might be good to say that too. If you and Russ are less > sure then I guess the current text is right. >=20 > And a little more below... >=20 > On 07/11/2013 07:11 PM, Rosen, Brian wrote: >> Inline On Jul 11, 2013, at 1:54 PM, Stephen Farrell >> wrote: >>=20 >>>=20 >>> Hi Russ, >>>=20 >>> I think this looks pretty good. A few wordsmithing changes and a >>> question below but I have one addition to suggest: >>>=20 >>> Somewhere this should say that the solution chosen needs to have an >>> acceptable overhead at both signer and verifer or else it also >>> won't be deployed. There may be some on here who could suggest >>> indicative timing or networking constraints (e.g. not having to do >>> ~5 OCSP transactions to possibly anywhere in the world) and if so, >>> that'd be a good thing to include IMO. >> I'll think about how to add some text for this. I think "deployable" >> is really, really important in this effort. >=20 > Fully agree and look forward to seeing that text. >=20 >>>=20 >>> On 07/11/2013 03:21 PM, Russ Housley wrote: >>>> Dear STIR Mail List Participants: >>>>=20 >>>> Brian and I have tried to pull together charter text based on >>>> the discussion to date. >>>>=20 >>>> The closer we can get to consensus on the list before the BOF, >>>> the more likely that we can get a WG shortly after Berlin. To >>>> this end, please review and comment on the attached text. Brian >>>> and I will hold the pen for updates to the text. >>>>=20 >>>> Russ >>>>=20 >>>> =3D =3D =3D =3D =3D >>>>=20 >>>> Name: Secure Telephone Identity Revisited (stir) Area: RAI >>>>=20 >>>> Chairs: TBD Area Advisor: Richard Barnes >>>>=20 >>>> Mailing list: stir@ietf.org To Subscribe:=20 >>>> https://www.ietf.org/mailman/listinfo/stir >>>>=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. As with email, the claimed source >>>> identity of a SIP request is not verified, and this permits >>>> unauthorized use of source identities as part of deceptive and >>>> coercive activities, such as robocalling (bulk unsolicited >>>> commercial communications), vishing (voicemail hacking, and >>>> impersonating banks) and swatting (impersonating callers to >>>> emergency services to stimulate unwarranted large scale law >>>> enforcement deployments). This working group will define a >>>> deployable mechanism to validate the identity of the calling=20 >>>> party that can be verified by entities in the path of a call. >>>>=20 >>>> SIP is one of the main VoIP technologies used by parties that >>>> want to present an incorrect origination. A number of previous >>>> efforts have tried to secure the origins of SIP communications, >>>> including RFC 3325, RFC 4474, and the VIPR working group. To >>>> date, however, true validation of the source of SIP calls has not >>>> seen any appreciable deployment. Several factors contributed to >>>> this lack of success, including: failure of the problem to be >>>> seen as critical at the time; lack of any real means of asserting >>>> authority over telephone numbers; misalignment of the mechanisms >>>> proposed by RFC 4474 with the complex deployment environment that >>>> has emerged for SIP; lack of end-to-end SIP session >>>> establishment; and inherent operational problems with a=20 >>>> transitive trust model. >>>>=20 >>>> Initially, the working group will specify an in-band mechanism >>>> to authenticate the originator of a SIP session where the >>>> identity being authenticated is a telephone number and the >>>> session is established with SIP end to end. The working group >>>> will consider choices for protecting the identity information and >>>> the credentials used, but will likely be similar to the methods >>>> described in RFC 4474, which employs a signature over a set of >>>> information in the SIP headers using a credential assigned to the >>>> identity. >>>=20 >>> I suggest replacing the above with >>>=20 >>> "will likely be based on a digital signature mechanism that is=20 >>> cryptographically similar to the one described in RFC 4474 and=20 >>> where the signature continues to be represented in SIP headers." >>>=20 >>> Saying "methods" and 4474 is a bit vague and could be read to mean >>> "s/mime-based" or "cms based" or "x.509 based" whereas what I think >>> we want is just to say its a signature. >>>=20 >>> Similarly "assigned to the identity" is very ambiguous and probably >>> better just omitted for now. >> We're discussing changes to this text on this thread. >=20 > Yeah. Consider the above another suggestion along the lines > of what (I think) Dave was getting at (I think - I've been > known to get that wrong before:-) >=20 >>>> In order to be authoritative, credentials used with this >>>> mechanism will be derived from existing telephone number >>>> assignment and delegation models. >>>=20 >>> No specific change suggested but are we using credential here to=20 >>> mean the private key or a (set of) TN(s) associated with a public >>> key? I think it ought be the latter. >> Of course it's both - the sender needs the private key to sign and >> the verifier needs the public key to verify, so "credentials" means >> both. We're trying not to start with a firm assumption of X.509 >> certs, so it's intentionally somewhat vague. A credential is >> associated with a (set of) TN(s). >=20 > Probably best to leave the precise definition to the WG so I > won't quibble with the above (yet:-). >=20 >>>> That is, when a telephone number or range of telephone numbers >>>> is delegated to an entity, a credential will accompany such >>>> delegation. >>>=20 >>> That's problematic with either definition of credential. I think=20 >>> it'd be ok to say: >>>=20 >>> That is, when a telephone number or range of telephone numbers is=20 >>> delegated to an entity, relevant credentials will be generated (or=20 >>> modified) to reflect such delegation. >> I am fine making this edit >=20 > Great. >=20 >>>> The mechanism must allow parties who are not delegated a >>>> telephone number, but are preauthorized by the entity who is >>>> delegated the number, to place calls using the identity. >>>=20 >>> No specific change suggested, but I've always wondered if this=20 >>> requirement is real. I'd argue enough good would be done without=20 >>> try to stretch for this. But I defer to those who know more about=20 >>> the application. >> It's very real and we could not deploy without it. An easy example >> is a contracted outbound call center operating on behalf of your >> bank. The bank wants it's number used as the calling party number, >> not the call center's trunk assignment. Among other things, it wants >> a return call resulting from the outbound call. The bank explicitly >> permits this. In our terms, it would do another level of >> delegation. >=20 > Fair enough. >=20 >>=20 >>=20 >>>=20 >>>> Expansion of the authentication mechanism to identities using the >>>> user@domain form should be considered in the initial design. >>>=20 >>> To be honest, I didn't read that thread (one too many:-) but I'm=20 >>> surprised that this is to be part of the initial design. But=20 >>> "considered" is sort of weasel-wordy so I'm not sure what's really >>> meant - what is "considered" meant to mean here? >> The problem we're solving is existing robocalling, vishing and >> swatting, which presently is TN based. I think we all want to >> anticipate greenfield sip uri's, lest we fix one problem and cause >> another. >=20 > So your response doesn't help me interpret "considered." Maybe > it is meant as weasel-wording and sometimes that is the right > thing to do, but I suspect it reads a bit too strong - as if > the WG are gonna spend a lot of time on non-E.164 names so I'd > say weakening it at least and ideally being more precise about > what "considered" means would be good and might avoid later > problems. >=20 > Cheers, > S. >=20 >>=20 >>>=20 >>> Cheers, S. >>>=20 >>>> After completing the SIP end to end solution, the working group >>>> will consider session establishment where there are one or more >>>> non-SIP hops, most likely using an out-of-band authentication >>>> mechanism. However, the in-band and out-of-band mechanisms >>>> should share as much in common as possible, especially the >>>> credentials. >>>>=20 >>>> The working group will coordinate with the Security Area on=20 >>>> credential management. >>>>=20 >>>> The working group will coordinate with other working groups in >>>> the RAI Area regarding signaling through existing deployments, >>>> including INSIPID. >>>>=20 >>>> Authenticated identity is closely linked to privacy, and one=20 >>>> frequently 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 >>>> Input to working group discussions shall include: >>>>=20 >>>> Private Extensions to the Session Initiation Protocol (SIP) for=20 >>>> 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=20 >>>> http://tools.ietf.org/html/draft-cooper-iab-secure-origin-00 >>>>=20 >>>> Secure Origin Identification: Problem Statement, Requirements, >>>> and Roadmap=20 >>>> http://tools.ietf.org/html/draft-peterson-secure-origin-ps-00 >>>>=20 >>>> Authenticated Identity Management in the Session Initiation >>>> Protocol (SIP)=20 >>>> http://tools.ietf.org/html/draft-jennings-dispatch-rfc4474bis-00 >>>>=20 >>>> The working group will deliver the following: >>>>=20 >>>> - A problem statement detailing the deployment environment and=20 >>>> situation that motivate work on secure telephone identity >>>>=20 >>>> - A mechanism document describing the SIP end-to-end with >>>> telephone number-based identities >>>>=20 >>>> - A document describing the credentials required to support >>>> secure telephone identity >>>>=20 >>>> - A fallback mechanism to allow out-of-band identity >>>> establishment during call setup >>>>=20 >>>> Milestones >>>>=20 >>>> Sep 2013 Submit problem statement for Informational Nov 2013=20 >>>> Submit RFC4474bis for Proposed Standard Feb 2014 Submit >>>> credential specification for Proposed Standard Jun 2014 Submit >>>> fallback for Proposed Standard >>>>=20 >>>> _______________________________________________ stir mailing list >>>> stir@ietf.org https://www.ietf.org/mailman/listinfo/stir >>>>=20 >>>>=20 >>=20 >> _______________________________________________ stir mailing list=20 >> stir@ietf.org https://www.ietf.org/mailman/listinfo/stir >>=20 >>=20 From dhc@dcrocker.net Thu Jul 11 11:46: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 99F2E21F9E9E for ; Thu, 11 Jul 2013 11:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.594 X-Spam-Level: X-Spam-Status: No, score=-6.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4wCx3HPZc7S for ; Thu, 11 Jul 2013 11:46:08 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B90D221F9A34 for ; Thu, 11 Jul 2013 11:46:02 -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 r6BIjp5O014723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Jul 2013 11:45:54 -0700 Message-ID: <51DEFD44.8090100@dcrocker.net> Date: Thu, 11 Jul 2013 11:45:24 -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: "Rosen, Brian" References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> 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, 11 Jul 2013 11:45:54 -0700 (PDT) Cc: Richard Barnes , "" , Russ Housley , Gonzalo Camarillo , Stephen Farrell Subject: Re: [stir] Draft STIR 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, 11 Jul 2013 18:46:13 -0000 On 7/11/2013 11:11 AM, Rosen, Brian wrote: >> Somewhere this should say that the solution chosen needs to >> have an acceptable overhead at both signer and verifer or >> else it also won't be deployed. There may be some on here >> who could suggest indicative timing or networking constraints >> (e.g. not having to do ~5 OCSP transactions to possibly >> anywhere in the world) and if so, that'd be a good thing >> to include IMO. > I'll think about how to add some text for this. I think "deployable" is really, really important in this effort. I assume Stephen means computational overhead. There's also the matter of administrative overhead, which has been a much higher barrier to adoption for DKIM and DMARC. To say "acceptable" invites debate about what it means. If the charter simply says "the design will attend to computational and administrative overhead, and exchange latency", it raises the necessary flags while avoiding concern for criteria in the charter. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From stephen.farrell@cs.tcd.ie Thu Jul 11 11:53:59 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB3E21F9EEF for ; Thu, 11 Jul 2013 11:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 J7HKMf8XWB3D for ; Thu, 11 Jul 2013 11:53:54 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDCA21F9C4F for ; Thu, 11 Jul 2013 11:53:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0DCD8BEC6; Thu, 11 Jul 2013 19:53:26 +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 zcPYczrkMK4w; Thu, 11 Jul 2013 19:53:23 +0100 (IST) Received: from [10.87.48.9] (unknown [86.42.17.76]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4E75CBE74; Thu, 11 Jul 2013 19:53:23 +0100 (IST) Message-ID: <51DEFF23.20002@cs.tcd.ie> Date: Thu, 11 Jul 2013 19:53:23 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Rosen, Brian" References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <51DEF814.9080704@cs.tcd.ie> <66490626-323F-46DF-8D22-D1677C17FE76@neustar.biz> In-Reply-To: <66490626-323F-46DF-8D22-D1677C17FE76@neustar.biz> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Richard Barnes , "" , Russ Housley , Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 18:53:59 -0000 On 07/11/2013 07:29 PM, Rosen, Brian wrote: > So maybe where we say "where the identity being authenticated is a > telephone number" add "in e.164 format"? Better all right. Some people were saying "full e.164" which I guess means including country code and a +, which'd be even better, if its not already implied in e.164. S > > Brian > > On Jul 11, 2013, at 2:23 PM, Stephen Farrell > wrote: > >> >> Hiya, >> >> Sorry one other thing I forgot before. There was a longish thread >> on what's a phone number (full E.164, local etc.) that I thought >> did reach a sort of conclusion that full E.164 will be the thing >> that is signed. If that's your and Russ' reading of the result then >> it might be good to say that too. If you and Russ are less sure >> then I guess the current text is right. >> >> And a little more below... >> >> On 07/11/2013 07:11 PM, Rosen, Brian wrote: >>> Inline On Jul 11, 2013, at 1:54 PM, Stephen Farrell >>> wrote: >>> >>>> >>>> Hi Russ, >>>> >>>> I think this looks pretty good. A few wordsmithing changes and >>>> a question below but I have one addition to suggest: >>>> >>>> Somewhere this should say that the solution chosen needs to >>>> have an acceptable overhead at both signer and verifer or else >>>> it also won't be deployed. There may be some on here who could >>>> suggest indicative timing or networking constraints (e.g. not >>>> having to do ~5 OCSP transactions to possibly anywhere in the >>>> world) and if so, that'd be a good thing to include IMO. >>> I'll think about how to add some text for this. I think >>> "deployable" is really, really important in this effort. >> >> Fully agree and look forward to seeing that text. >> >>>> >>>> On 07/11/2013 03:21 PM, Russ Housley wrote: >>>>> Dear STIR Mail List Participants: >>>>> >>>>> Brian and I have tried to pull together charter text based >>>>> on the discussion to date. >>>>> >>>>> The closer we can get to consensus on the list before the >>>>> BOF, the more likely that we can get a WG shortly after >>>>> Berlin. To this end, please review and comment on the >>>>> attached text. Brian and I will hold the pen for updates to >>>>> the text. >>>>> >>>>> Russ >>>>> >>>>> = = = = = >>>>> >>>>> Name: Secure Telephone Identity Revisited (stir) Area: RAI >>>>> >>>>> Chairs: TBD Area Advisor: Richard Barnes >>>>> >>>>> Mailing list: stir@ietf.org To Subscribe: >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>> >>>>> 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. As with email, the >>>>> claimed source identity of a SIP request is not verified, and >>>>> this permits unauthorized use of source identities as part of >>>>> deceptive and coercive activities, such as robocalling (bulk >>>>> unsolicited commercial communications), vishing (voicemail >>>>> hacking, and impersonating banks) and swatting (impersonating >>>>> callers to emergency services to stimulate unwarranted large >>>>> scale law enforcement deployments). This working group will >>>>> define a deployable mechanism to validate the identity of the >>>>> calling party that can be verified by entities in the path of >>>>> a call. >>>>> >>>>> SIP is one of the main VoIP technologies used by parties >>>>> that want to present an incorrect origination. A number of >>>>> previous efforts have tried to secure the origins of SIP >>>>> communications, including RFC 3325, RFC 4474, and the VIPR >>>>> working group. To date, however, true validation of the >>>>> source of SIP calls has not seen any appreciable deployment. >>>>> Several factors contributed to this lack of success, >>>>> including: failure of the problem to be seen as critical at >>>>> the time; lack of any real means of asserting authority over >>>>> telephone numbers; misalignment of the mechanisms proposed by >>>>> RFC 4474 with the complex deployment environment that has >>>>> emerged for SIP; lack of end-to-end SIP session >>>>> establishment; and inherent operational problems with a >>>>> transitive trust model. >>>>> >>>>> Initially, the working group will specify an in-band >>>>> mechanism to authenticate the originator of a SIP session >>>>> where the identity being authenticated is a telephone number >>>>> and the session is established with SIP end to end. The >>>>> working group will consider choices for protecting the >>>>> identity information and the credentials used, but will >>>>> likely be similar to the methods described in RFC 4474, which >>>>> employs a signature over a set of information in the SIP >>>>> headers using a credential assigned to the identity. >>>> >>>> I suggest replacing the above with >>>> >>>> "will likely be based on a digital signature mechanism that is >>>> cryptographically similar to the one described in RFC 4474 and >>>> where the signature continues to be represented in SIP >>>> headers." >>>> >>>> Saying "methods" and 4474 is a bit vague and could be read to >>>> mean "s/mime-based" or "cms based" or "x.509 based" whereas >>>> what I think we want is just to say its a signature. >>>> >>>> Similarly "assigned to the identity" is very ambiguous and >>>> probably better just omitted for now. >>> We're discussing changes to this text on this thread. >> >> Yeah. Consider the above another suggestion along the lines of what >> (I think) Dave was getting at (I think - I've been known to get >> that wrong before:-) >> >>>>> In order to be authoritative, credentials used with this >>>>> mechanism will be derived from existing telephone number >>>>> assignment and delegation models. >>>> >>>> No specific change suggested but are we using credential here >>>> to mean the private key or a (set of) TN(s) associated with a >>>> public key? I think it ought be the latter. >>> Of course it's both - the sender needs the private key to sign >>> and the verifier needs the public key to verify, so "credentials" >>> means both. We're trying not to start with a firm assumption of >>> X.509 certs, so it's intentionally somewhat vague. A credential >>> is associated with a (set of) TN(s). >> >> Probably best to leave the precise definition to the WG so I won't >> quibble with the above (yet:-). >> >>>>> That is, when a telephone number or range of telephone >>>>> numbers is delegated to an entity, a credential will >>>>> accompany such delegation. >>>> >>>> That's problematic with either definition of credential. I >>>> think it'd be ok to say: >>>> >>>> That is, when a telephone number or range of telephone numbers >>>> is delegated to an entity, relevant credentials will be >>>> generated (or modified) to reflect such delegation. >>> I am fine making this edit >> >> Great. >> >>>>> The mechanism must allow parties who are not delegated a >>>>> telephone number, but are preauthorized by the entity who is >>>>> delegated the number, to place calls using the identity. >>>> >>>> No specific change suggested, but I've always wondered if this >>>> requirement is real. I'd argue enough good would be done >>>> without try to stretch for this. But I defer to those who know >>>> more about the application. >>> It's very real and we could not deploy without it. An easy >>> example is a contracted outbound call center operating on behalf >>> of your bank. The bank wants it's number used as the calling >>> party number, not the call center's trunk assignment. Among >>> other things, it wants a return call resulting from the outbound >>> call. The bank explicitly permits this. In our terms, it would >>> do another level of delegation. >> >> Fair enough. >> >>> >>> >>>> >>>>> Expansion of the authentication mechanism to identities using >>>>> the user@domain form should be considered in the initial >>>>> design. >>>> >>>> To be honest, I didn't read that thread (one too many:-) but >>>> I'm surprised that this is to be part of the initial design. >>>> But "considered" is sort of weasel-wordy so I'm not sure what's >>>> really meant - what is "considered" meant to mean here? >>> The problem we're solving is existing robocalling, vishing and >>> swatting, which presently is TN based. I think we all want to >>> anticipate greenfield sip uri's, lest we fix one problem and >>> cause another. >> >> So your response doesn't help me interpret "considered." Maybe it >> is meant as weasel-wording and sometimes that is the right thing to >> do, but I suspect it reads a bit too strong - as if the WG are >> gonna spend a lot of time on non-E.164 names so I'd say weakening >> it at least and ideally being more precise about what "considered" >> means would be good and might avoid later problems. >> >> Cheers, S. >> >>> >>>> >>>> Cheers, S. >>>> >>>>> After completing the SIP end to end solution, the working >>>>> group will consider session establishment where there are one >>>>> or more non-SIP hops, most likely using an out-of-band >>>>> authentication mechanism. However, the in-band and >>>>> out-of-band mechanisms should share as much in common as >>>>> possible, especially the credentials. >>>>> >>>>> The working group will coordinate with the Security Area on >>>>> credential management. >>>>> >>>>> The working group will coordinate with other working groups >>>>> in the RAI Area regarding signaling through existing >>>>> deployments, including INSIPID. >>>>> >>>>> Authenticated identity is closely linked to privacy, and one >>>>> frequently 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. >>>>> >>>>> 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 >>>>> >>>>> >>>>> The working group will deliver the following: >>>>> >>>>> - A problem statement detailing the deployment environment >>>>> and situation that motivate work on secure telephone >>>>> identity >>>>> >>>>> - A mechanism document describing the SIP end-to-end with >>>>> telephone number-based identities >>>>> >>>>> - A document describing the credentials required to support >>>>> secure telephone identity >>>>> >>>>> - A fallback mechanism to allow out-of-band identity >>>>> establishment during call setup >>>>> >>>>> Milestones >>>>> >>>>> Sep 2013 Submit problem statement for Informational Nov >>>>> 2013 Submit RFC4474bis for Proposed Standard Feb 2014 >>>>> Submit credential specification for Proposed Standard Jun >>>>> 2014 Submit fallback for Proposed Standard >>>>> >>>>> _______________________________________________ stir mailing >>>>> list stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>> >>>>> >>> >>> _______________________________________________ stir mailing list >>> stir@ietf.org https://www.ietf.org/mailman/listinfo/stir >>> >>> > > _______________________________________________ stir mailing list > stir@ietf.org https://www.ietf.org/mailman/listinfo/stir > > From timothy.dwight@verizon.com Thu Jul 11 11:55: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 CF78421F9C0F for ; Thu, 11 Jul 2013 11:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 OFafJW-Bv2J9 for ; Thu, 11 Jul 2013 11:55:03 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id 736B721F9EEF for ; Thu, 11 Jul 2013 11:55:03 -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; 11 Jul 2013 18:54:58 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.89,1045,1367971200"; d="scan'208";a="515254308" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi01.verizon.com with ESMTP; 11 Jul 2013 18:54:57 +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, 11 Jul 2013 14:54:48 -0400 To: Hadriel Kaplan , Michael Hammer Date: Thu, 11 Jul 2013 14:54:47 -0400 Thread-Topic: [stir] Using Validated Numbers (was - Re: U.S. Senate hearing on robocalls July 10, 2013) Thread-Index: Ac5+XkAAXSDfmgWrQhqv9AYz/1ZF/gAAY7ew Message-ID: <2B0F677F0B95454297753F58D4A07FA3012938CDEB@FHDP1LUMXC7V31.us.one.verizon.com> References: , <007201ce799a$34539360$9cfaba20$@shockey.us> <900A1E2059ADB149B905E3C8FA0046A62C77C39220@FHDP1LUMXC7V23.us.one.verizon.com> <01ad01ce7da0$5af26f00$10d74d00$@shockey.us> <52705969-970E-431A-9A9B-B24AAF69C082@oracle.com> <51DE3DDB.2000303@dcrocker.net> <00C069FD01E0324C9FFCADF539701DB3BBC13E48@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "Henning.Schulzrinne@fcc.gov" , "york@isoc.org" , "Mishra, Sanjay" , "dcrocker@bbiw.net" Subject: Re: [stir] Using Validated Numbers (was - Re: U.S. Senate hearing on robocalls July 10, 2013) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 18:55:09 -0000 Whether the NPAC plays any role seems like a North America -specific, large= ly-commercial distraction. Certainly I would object to any effort to bias = the square peg (solution) so that it fits that particular (need I say North= America -specific?) round hole (NPAC). =20 tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Had= riel Kaplan Sent: Thursday, July 11, 2013 11:47 AM To: Michael Hammer Cc: Mishra, Sanjay; stir@ietf.org; york@isoc.org; dcrocker@bbiw.net; Hennin= g.Schulzrinne@fcc.gov Subject: Re: [stir] Using Validated Numbers (was - Re: U.S. Senate hearing = on robocalls July 10, 2013) I think he meant the NPAC. Even if the NPAC held the keys/certs, we'd still want a way to do STIR dele= gation... because afaict the NPAC in its current form doesn't truly know t= he ultimate service provider. It appears to only know the regulated "carri= er" the number is assigned to, but that's not the ultimate service provider= really. There are hundreds of providers who aren't classified as "carrier= s", and don't want to be for legal/monetary reasons. They pay a real "carr= ier" to handle the number porting, so the NPAC only has that official carri= er in its database instead of the ultimate service provider. That official= carrier could be the one to sign the caller-id coming from its customer se= rvice providers, but we probably need a way for the real originating servic= e provider to do it instead. -hadriel On Jul 11, 2013, at 10:36 AM, Michael Hammer = wrote: > Correct me if I am wrong, but I didn't think the LERG went to 10 digits. >=20 > Mike >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 > Of Henning Schulzrinne > Sent: Thursday, July 11, 2013 10:00 AM > To: 'dcrocker@bbiw.net'; stir@ietf.org > Cc: 'Dan York'; 'Mishra, Sanjay' > Subject: Re: [stir] Using Validated Numbers (was - Re: U.S. Senate=20 > hearing on robocalls July 10, 2013) >=20 > A crucial component will be that >=20 > (1) *all* calls from a certain number are validated > (2) the receiver can know that this is the case ("DANE") >=20 > (2) can be a heuristic, given (1), but obviously explicit information=20 > is better. That way, targets that are particularly susceptible to=20 > individualized spoofing, such as financial institutions, can protect=20 > themselves first, just like they did by implementing TLS early on=20 > their web sites. That would prevent a fair amount of vishing. If we=20 > can then get the large outbound call centers to "incent" their=20 > carriers, most people will then only get three kinds of calls: > (a) validated business calls > (b) known numbers from friends and family > (c) unvalidated calls that are very likely to be robocalls and can, at=20 > least, be sent to voicemail and CAPTCHA >=20 > (2) may not be an Internet-facing directory, although that could be=20 > quite helpful. For example, this information could be contained in the=20 > LERG or other information made available by the numbering administrator. >=20 > -----Original Message----- > From: Dave Crocker [mailto:dhc@dcrocker.net] > Sent: Thursday, July 11, 2013 1:09 AM > To: stir@ietf.org > Cc: 'Dan York'; 'Mishra, Sanjay'; Henning Schulzrinne > Subject: Using Validated Numbers (was - Re: [stir] U.S. Senate hearing=20 > on robocalls July 10, 2013) >=20 >=20 >> Regardless, none of the robocall-blocking tactics I've seen will do=20 >> much in the long run unless we get the caller-id's to at least be=20 >> authenticate-able. Once we know the caller-ids can't be randomly=20 >> generated or spoof legitimate sources, doing whitelist/blacklist=20 >> things will be a lot more tenable. >=20 >=20 > Dumb question, since it seems clear that most folk already have a=20 > sense of the answer: Once there are some telephone numbers getting=20 > validated, how will this get used and by what components in the system? >=20 > I'm asking for more detail that the above text has, so that it's=20 > possible to consider the specifics of what to change and how it will=20 > work, such as during initial years of only partial adoption. >=20 > Over in email-abuse land, a wide range of assumptions were made about=20 > the use of authenticated names, but the actual uses have had some surpris= es. >=20 > To the extent that there is agreement on the specific uses that are=20 > planned for validated telephone numbers, it can sometimes help to=20 > clarify engineering choices for the validation mechanism. >=20 > d/ >=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 _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From stephen.farrell@cs.tcd.ie Thu Jul 11 11:57:24 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769F511E8114 for ; Thu, 11 Jul 2013 11:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 hT0pf04vGX72 for ; Thu, 11 Jul 2013 11:57:17 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id E195E21F9FFB for ; Thu, 11 Jul 2013 11:57:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2BED0BEA1; Thu, 11 Jul 2013 19:56:55 +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 CCWQUm6LEg5h; Thu, 11 Jul 2013 19:56:54 +0100 (IST) Received: from [10.87.48.9] (unknown [86.42.17.76]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0936FBE74; Thu, 11 Jul 2013 19:56:54 +0100 (IST) Message-ID: <51DEFFF5.8050001@cs.tcd.ie> Date: Thu, 11 Jul 2013 19:56:53 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <51DEFD44.8090100@dcrocker.net> In-Reply-To: <51DEFD44.8090100@dcrocker.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Dave Crocker , Richard Barnes , Russ Housley , Gonzalo Camarillo , "" , "Rosen, Brian" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 18:57:24 -0000 On 07/11/2013 07:45 PM, Dave Crocker wrote: > > > If the charter simply says "the design will attend to computational and > administrative overhead, and exchange latency", it raises the necessary > flags while avoiding concern for criteria in the charter. Something like that'd be a good improvement I think. The more concrete it can be, without diving into specific solutions the better it'd be as well IMO. But in asking for more, I'm assuming that there are accepted and reasonably well understood limits to those types of overhead and maybe there aren't. S. From Henning.Schulzrinne@fcc.gov Thu Jul 11 12:01: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 648F221E80AD for ; Thu, 11 Jul 2013 12:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.955 X-Spam-Level: X-Spam-Status: No, score=-1.955 tagged_above=-999 required=5 tests=[AWL=0.644, 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 jZTY03pjADcr for ; Thu, 11 Jul 2013 12:01:15 -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 755B221F969F for ; Thu, 11 Jul 2013 12:00:59 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Stephen Farrell' , "Rosen, Brian" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIF2w2hhDzu+kKP+YqzEEYfuplgBgeAgAAEgQCAAANuAIAAAaEAgAAGyYD//73RMA== Date: Thu, 11 Jul 2013 19:00:28 +0000 References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <51DEF814.9080704@cs.tcd.ie> <66490626-323F-46DF-8D22-D1677C17FE76@neustar.biz> <51DEFF23.20002@cs.tcd.ie> In-Reply-To: <51DEFF23.20002@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Richard Barnes , "" , Russ Housley , Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 19:01:20 -0000 E.164 implies full phone number. >From E.164, Section 6.2: The international ITU-T E.164-number is composed of a variable number of de= cimal digits arranged in specific code fields. The international ITU-T E.164-number code= fields are the country code (CC) and remaining fields are specific to the use being made of the in= ternational ITU-T E.164 number as shown in Figures 1 to 5. A numbering plan does not include prefixes, suffixes, and additional inform= ation required to complete a call. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Ste= phen Farrell Sent: Thursday, July 11, 2013 2:53 PM To: Rosen, Brian Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter On 07/11/2013 07:29 PM, Rosen, Brian wrote: > So maybe where we say "where the identity being authenticated is a=20 > telephone number" add "in e.164 format"? Better all right. Some people were saying "full e.164" which I guess means = including country code and a +, which'd be even better, if its not already = implied in e.164. From dhc@dcrocker.net Thu Jul 11 12: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 7BF2221F9931 for ; Thu, 11 Jul 2013 12:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.594 X-Spam-Level: X-Spam-Status: No, score=-6.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0v1a6Gk7-Tn for ; Thu, 11 Jul 2013 12:10:20 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9756021F9E62 for ; Thu, 11 Jul 2013 12:10: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 r6BJAB7Q015106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Jul 2013 12:10:14 -0700 Message-ID: <51DF02F9.9080802@dcrocker.net> Date: Thu, 11 Jul 2013 12:09:45 -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: Stephen Farrell References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <51DEFD44.8090100@dcrocker.net> <51DEFFF5.8050001@cs.tcd.ie> In-Reply-To: <51DEFFF5.8050001@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]); Thu, 11 Jul 2013 12:10:15 -0700 (PDT) Cc: Richard Barnes , "Rosen, Brian" , Russ Housley , Gonzalo Camarillo , "" Subject: Re: [stir] Draft STIR 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, 11 Jul 2013 19:10:25 -0000 On 7/11/2013 11:56 AM, Stephen Farrell wrote: > On 07/11/2013 07:45 PM, Dave Crocker wrote: >> If the charter simply says "the design will attend to computational and >> administrative overhead, and exchange latency", it raises the necessary >> flags while avoiding concern for criteria in the charter. > > Something like that'd be a good improvement I think. The more > concrete it can be, without diving into specific solutions the > better it'd be as well IMO. > > But in asking for more, I'm assuming that there are accepted and > reasonably well understood limits to those types of overhead and > maybe there aren't. My understanding is that for DKIM, most/all sites implementing it to sign all outgoing mail have not had to increase their processing infrastructure at all. As with all financial predictions, past performance is no guarantee of... In any event, one purpose of the suggested language is to defer the question of any specific numbers, limits, etc., to the wg. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From brian.rosen@neustar.biz Thu Jul 11 12:11: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 E5EE021F962D for ; Thu, 11 Jul 2013 12:11:08 -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 QBtBYe-Pa93N for ; Thu, 11 Jul 2013 12:11:04 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 60F1E21F9546 for ; Thu, 11 Jul 2013 12:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1373569759; x=1688922090; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=mVJdC7p4q5 LXHU9TJY4BnSN+HMw6FoKQT5iBlFYqeQY=; b=FJ5pPp7IYqpOM/Q8FvFBQxVBJj Mm+xpUTJx7iZm+PgTzJFBOCC2ezfViRWvIGBorcMzG5SYk3KTOM7232o+ppw== Received: from ([10.31.58.70]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.20731828; Thu, 11 Jul 2013 15:09:18 -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, 11 Jul 2013 15:10:46 -0400 From: "Rosen, Brian" To: Henning Schulzrinne Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkH7PavsqszcIEumRBC5KQ07J5lgBgeAgAAEgICAAANvAIAAAaEAgAAGyYCAAAH6AIAAAuCA Date: Thu, 11 Jul 2013 19:10:45 +0000 Message-ID: <8089F9F5-8FC2-4F2D-AA25-D6D7F1C9356B@neustar.biz> References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <51DEF814.9080704@cs.tcd.ie> <66490626-323F-46DF-8D22-D1677C17FE76@neustar.biz> <51DEFF23.20002@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.192.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: nnZQJEFEeNDOnB8xDgJ2Kg== Content-Type: text/plain; charset="us-ascii" Content-ID: <60E1A18061C51D4DAC036049497192EF@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Richard Barnes , "" , Russ Housley , Gonzalo Camarillo , Stephen Farrell Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 19:11:09 -0000 Getting technical: What we're describing is an "international ITU-T E.164-number for geographi= c areas", which "is composed of decimal digits arranged in two code fields:= the country code (CC) and the national (significant) number N(S)N" The "+" convention is actually not part of e.164, but is a very common way = to denote that the digit string is an E.1640-number for geographic areas. Brian On Jul 11, 2013, at 3:00 PM, Henning Schulzrinne wrote: > E.164 implies full phone number. >=20 > From E.164, Section 6.2: >=20 > The international ITU-T E.164-number is composed of a variable number of = decimal digits > arranged in specific code fields. The international ITU-T E.164-number co= de fields are the country > code (CC) and remaining fields are specific to the use being made of the = international ITU-T E.164 > number as shown in Figures 1 to 5. > A numbering plan does not include prefixes, suffixes, and additional info= rmation required to > complete a call. >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of S= tephen Farrell > Sent: Thursday, July 11, 2013 2:53 PM > To: Rosen, Brian > Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo > Subject: Re: [stir] Draft STIR Charter >=20 >=20 >=20 > On 07/11/2013 07:29 PM, Rosen, Brian wrote: >> So maybe where we say "where the identity being authenticated is a=20 >> telephone number" add "in e.164 format"? >=20 > Better all right. Some people were saying "full e.164" which I guess mean= s including country code and a +, which'd be even better, if its not alread= y implied in e.164. >=20 From dhc@dcrocker.net Thu Jul 11 12:12: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 EAA8221F9D0D for ; Thu, 11 Jul 2013 12:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.594 X-Spam-Level: X-Spam-Status: No, score=-6.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFM4YxlaLn4x for ; Thu, 11 Jul 2013 12:12:16 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0D86B21F9CEC for ; Thu, 11 Jul 2013 12:12: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 r6BJC47o015146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Jul 2013 12:12:07 -0700 Message-ID: <51DF036A.206@dcrocker.net> Date: Thu, 11 Jul 2013 12:11:38 -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: Henning Schulzrinne References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <51DEF814.9080704@cs.tcd.ie> <66490626-323F-46DF-8D22-D1677C17FE76@neustar.biz> <51DEFF23.20002@cs.tcd.ie> 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, 11 Jul 2013 12:12:08 -0700 (PDT) Cc: Richard Barnes , Russ Housley , Gonzalo Camarillo , "" , "Rosen, Brian" , 'Stephen Farrell' Subject: Re: [stir] Draft STIR 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, 11 Jul 2013 19:12:21 -0000 On 7/11/2013 12:00 PM, Henning Schulzrinne wrote: > E.164 implies full phone number. > >>From E.164, Section 6.2: > > The international ITU-T E.164-number is composed of a variable number of decimal digits > arranged in specific code fields. The international ITU-T E.164-number code fields are the country > code (CC) and remaining fields are specific to the use being made of the international ITU-T E.164 > number as shown in Figures 1 to 5. > A numbering plan does not include prefixes, suffixes, and additional information required to > complete a call. Sounds like a globally-unique string, on a par with FQDN. It might be worth having the charter note the mapping function that will often be required, to convert a local-form of telephone number in the From field to it's standardized E.164 form. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From timothy.dwight@verizon.com Thu Jul 11 12:14: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 1D00821F9E69 for ; Thu, 11 Jul 2013 12:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 xM-mDKNrQBbU for ; Thu, 11 Jul 2013 12:13:55 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id F240D21F9D2B for ; Thu, 11 Jul 2013 12:13:54 -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; 11 Jul 2013 19:13:44 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.89,1045,1367971200"; d="scan'208";a="515273746" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi01.verizon.com with ESMTP; 11 Jul 2013 19:13:40 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Thu, 11 Jul 2013 15:13:36 -0400 To: Stephen Farrell , "Rosen, Brian" Date: Thu, 11 Jul 2013 15:13:35 -0400 Thread-Topic: [stir] Draft STIR Charter Thread-Index: Ac5+aAXERlv17ZzZTfiY/BmtyzMuRAAAaOtA Message-ID: <2B0F677F0B95454297753F58D4A07FA3012938CE38@FHDP1LUMXC7V31.us.one.verizon.com> References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <51DEF814.9080704@cs.tcd.ie> <66490626-323F-46DF-8D22-D1677C17FE76@neustar.biz> <51DEFF23.20002@cs.tcd.ie> In-Reply-To: <51DEFF23.20002@cs.tcd.ie> 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: Richard Barnes , "" , Russ Housley , Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 19:14:01 -0000 How about "International E.164 number"? That's the phrase actually used in= Rec. E.164 to refer to the combination of Country Code and National Signif= icant Number. The practice of preceding an International E.164 number with a '+' comes fr= om Rec. E.123, "Notation for national and international telephone numbers, = e-mail addresses and web addresses". E.123 addresses how certain types of = addresses should be expressed, for maximum clarity. It refers to the '+' s= ymbol, by the way, as the "International prefix symbol". In principle the = '+ is not part of the number, it is a "visual clue" to the reader, remindin= g him or her to dial the international prefix (e.g., '01' in the U.S.). tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Ste= phen Farrell Sent: Thursday, July 11, 2013 1:53 PM To: Rosen, Brian Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter On 07/11/2013 07:29 PM, Rosen, Brian wrote: > So maybe where we say "where the identity being authenticated is a=20 > telephone number" add "in e.164 format"? Better all right. Some people were saying "full e.164" which I guess means = including country code and a +, which'd be even better, if its not already = implied in e.164. S >=20 > Brian >=20 > On Jul 11, 2013, at 2:23 PM, Stephen Farrell=20 > wrote: >=20 >>=20 >> Hiya, >>=20 >> Sorry one other thing I forgot before. There was a longish thread on=20 >> what's a phone number (full E.164, local etc.) that I thought did=20 >> reach a sort of conclusion that full E.164 will be the thing that is=20 >> signed. If that's your and Russ' reading of the result then it might=20 >> be good to say that too. If you and Russ are less sure then I guess=20 >> the current text is right. >>=20 >> And a little more below... >>=20 >> On 07/11/2013 07:11 PM, Rosen, Brian wrote: >>> Inline On Jul 11, 2013, at 1:54 PM, Stephen Farrell=20 >>> wrote: >>>=20 >>>>=20 >>>> Hi Russ, >>>>=20 >>>> I think this looks pretty good. A few wordsmithing changes and a=20 >>>> question below but I have one addition to suggest: >>>>=20 >>>> Somewhere this should say that the solution chosen needs to have an=20 >>>> acceptable overhead at both signer and verifer or else it also=20 >>>> won't be deployed. There may be some on here who could suggest=20 >>>> indicative timing or networking constraints (e.g. not having to do=20 >>>> ~5 OCSP transactions to possibly anywhere in the >>>> world) and if so, that'd be a good thing to include IMO. >>> I'll think about how to add some text for this. I think=20 >>> "deployable" is really, really important in this effort. >>=20 >> Fully agree and look forward to seeing that text. >>=20 >>>>=20 >>>> On 07/11/2013 03:21 PM, Russ Housley wrote: >>>>> Dear STIR Mail List Participants: >>>>>=20 >>>>> Brian and I have tried to pull together charter text based on the=20 >>>>> discussion to date. >>>>>=20 >>>>> The closer we can get to consensus on the list before the BOF, the=20 >>>>> more likely that we can get a WG shortly after Berlin. To this=20 >>>>> end, please review and comment on the attached text. Brian and I=20 >>>>> will hold the pen for updates to the text. >>>>>=20 >>>>> Russ >>>>>=20 >>>>> =3D =3D =3D =3D =3D >>>>>=20 >>>>> Name: Secure Telephone Identity Revisited (stir) Area: RAI >>>>>=20 >>>>> Chairs: TBD Area Advisor: Richard Barnes >>>>>=20 >>>>> Mailing list: stir@ietf.org To Subscribe:=20 >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>=20 >>>>> Over the last decade, a growing set of problems have resulted from=20 >>>>> the lack of security mechanisms for attesting the origins of=20 >>>>> real-time communications. As with email, the claimed source=20 >>>>> identity of a SIP request is not verified, and this permits=20 >>>>> unauthorized use of source identities as part of deceptive and=20 >>>>> coercive activities, such as robocalling (bulk unsolicited=20 >>>>> commercial communications), vishing (voicemail hacking, and=20 >>>>> impersonating banks) and swatting (impersonating callers to=20 >>>>> emergency services to stimulate unwarranted large scale law=20 >>>>> enforcement deployments). This working group will define a=20 >>>>> deployable mechanism to validate the identity of the calling party=20 >>>>> that can be verified by entities in the path of a call. >>>>>=20 >>>>> SIP is one of the main VoIP technologies used by parties that want=20 >>>>> to present an incorrect origination. A number of previous efforts=20 >>>>> have tried to secure the origins of SIP communications, including=20 >>>>> RFC 3325, RFC 4474, and the VIPR working group. To date, however,=20 >>>>> true validation of the source of SIP calls has not seen any=20 >>>>> appreciable deployment. >>>>> Several factors contributed to this lack of success, >>>>> including: failure of the problem to be seen as critical at the=20 >>>>> time; lack of any real means of asserting authority over telephone=20 >>>>> numbers; misalignment of the mechanisms proposed by RFC 4474 with=20 >>>>> the complex deployment environment that has emerged for SIP; lack=20 >>>>> of end-to-end SIP session establishment; and inherent operational=20 >>>>> problems with a transitive trust model. >>>>>=20 >>>>> Initially, the working group will specify an in-band mechanism to=20 >>>>> authenticate the originator of a SIP session where the identity=20 >>>>> being authenticated is a telephone number and the session is=20 >>>>> established with SIP end to end. The working group will consider=20 >>>>> choices for protecting the identity information and the=20 >>>>> credentials used, but will likely be similar to the methods=20 >>>>> described in RFC 4474, which employs a signature over a set of=20 >>>>> information in the SIP headers using a credential assigned to the=20 >>>>> identity. >>>>=20 >>>> I suggest replacing the above with >>>>=20 >>>> "will likely be based on a digital signature mechanism that is =20 >>>> cryptographically similar to the one described in RFC 4474 and =20 >>>> where the signature continues to be represented in SIP headers." >>>>=20 >>>> Saying "methods" and 4474 is a bit vague and could be read to mean=20 >>>> "s/mime-based" or "cms based" or "x.509 based" whereas what I think=20 >>>> we want is just to say its a signature. >>>>=20 >>>> Similarly "assigned to the identity" is very ambiguous and probably=20 >>>> better just omitted for now. >>> We're discussing changes to this text on this thread. >>=20 >> Yeah. Consider the above another suggestion along the lines of what=20 >> (I think) Dave was getting at (I think - I've been known to get that=20 >> wrong before:-) >>=20 >>>>> In order to be authoritative, credentials used with this mechanism=20 >>>>> will be derived from existing telephone number assignment and=20 >>>>> delegation models. >>>>=20 >>>> No specific change suggested but are we using credential here to=20 >>>> mean the private key or a (set of) TN(s) associated with a public=20 >>>> key? I think it ought be the latter. >>> Of course it's both - the sender needs the private key to sign and=20 >>> the verifier needs the public key to verify, so "credentials" >>> means both. We're trying not to start with a firm assumption of >>> X.509 certs, so it's intentionally somewhat vague. A credential is=20 >>> associated with a (set of) TN(s). >>=20 >> Probably best to leave the precise definition to the WG so I won't=20 >> quibble with the above (yet:-). >>=20 >>>>> That is, when a telephone number or range of telephone numbers is=20 >>>>> delegated to an entity, a credential will accompany such=20 >>>>> delegation. >>>>=20 >>>> That's problematic with either definition of credential. I think=20 >>>> it'd be ok to say: >>>>=20 >>>> That is, when a telephone number or range of telephone numbers is=20 >>>> delegated to an entity, relevant credentials will be generated (or=20 >>>> modified) to reflect such delegation. >>> I am fine making this edit >>=20 >> Great. >>=20 >>>>> The mechanism must allow parties who are not delegated a telephone=20 >>>>> number, but are preauthorized by the entity who is delegated the=20 >>>>> number, to place calls using the identity. >>>>=20 >>>> No specific change suggested, but I've always wondered if this =20 >>>> requirement is real. I'd argue enough good would be done without=20 >>>> try to stretch for this. But I defer to those who know more about=20 >>>> the application. >>> It's very real and we could not deploy without it. An easy example=20 >>> is a contracted outbound call center operating on behalf of your=20 >>> bank. The bank wants it's number used as the calling party number,=20 >>> not the call center's trunk assignment. Among other things, it=20 >>> wants a return call resulting from the outbound call. The bank=20 >>> explicitly permits this. In our terms, it would do another level of=20 >>> delegation. >>=20 >> Fair enough. >>=20 >>>=20 >>>=20 >>>>=20 >>>>> Expansion of the authentication mechanism to identities using the=20 >>>>> user@domain form should be considered in the initial design. >>>>=20 >>>> To be honest, I didn't read that thread (one too many:-) but I'm=20 >>>> surprised that this is to be part of the initial design. >>>> But "considered" is sort of weasel-wordy so I'm not sure what's=20 >>>> really meant - what is "considered" meant to mean here? >>> The problem we're solving is existing robocalling, vishing and=20 >>> swatting, which presently is TN based. I think we all want to=20 >>> anticipate greenfield sip uri's, lest we fix one problem and cause=20 >>> another. >>=20 >> So your response doesn't help me interpret "considered." Maybe it is=20 >> meant as weasel-wording and sometimes that is the right thing to do,=20 >> but I suspect it reads a bit too strong - as if the WG are gonna=20 >> spend a lot of time on non-E.164 names so I'd say weakening it at=20 >> least and ideally being more precise about what "considered" >> means would be good and might avoid later problems. >>=20 >> Cheers, S. >>=20 >>>=20 >>>>=20 >>>> Cheers, S. >>>>=20 >>>>> After completing the SIP end to end solution, the working group=20 >>>>> will consider session establishment where there are one or more=20 >>>>> non-SIP hops, most likely using an out-of-band authentication=20 >>>>> mechanism. However, the in-band and out-of-band mechanisms should=20 >>>>> share as much in common as possible, especially the credentials. >>>>>=20 >>>>> The working group will coordinate with the Security Area on=20 >>>>> credential management. >>>>>=20 >>>>> The working group will coordinate with other working groups in the=20 >>>>> RAI Area regarding signaling through existing deployments,=20 >>>>> including INSIPID. >>>>>=20 >>>>> Authenticated identity is closely linked to privacy, and one =20 >>>>> frequently comes at the cost of the other. This working group is=20 >>>>> not chartered to mandate the presence of identity in SIP requests,=20 >>>>> and to the extent feasible it will find privacy-friendly solutions=20 >>>>> that leak minimal information about calls to third parties. >>>>>=20 >>>>> Input to working group discussions shall include: >>>>>=20 >>>>> Private Extensions to the Session Initiation Protocol (SIP) for=20 >>>>> Asserted Identity within Trusted Networks RFC 3325 >>>>>=20 >>>>> Enhancements for Authenticated Identity Management in the Session=20 >>>>> 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=20 >>>>> 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 The working group will deliver the following: >>>>>=20 >>>>> - A problem statement detailing the deployment environment and=20 >>>>> situation that motivate work on secure telephone identity >>>>>=20 >>>>> - A mechanism document describing the SIP end-to-end with=20 >>>>> telephone number-based identities >>>>>=20 >>>>> - A document describing the credentials required to support secure=20 >>>>> telephone identity >>>>>=20 >>>>> - A fallback mechanism to allow out-of-band identity establishment=20 >>>>> during call setup >>>>>=20 >>>>> Milestones >>>>>=20 >>>>> Sep 2013 Submit problem statement for Informational Nov >>>>> 2013 Submit RFC4474bis for Proposed Standard Feb 2014 Submit=20 >>>>> credential specification for Proposed Standard Jun >>>>> 2014 Submit fallback for Proposed Standard >>>>>=20 >>>>> _______________________________________________ stir mailing list=20 >>>>> stir@ietf.org https://www.ietf.org/mailman/listinfo/stir >>>>>=20 >>>>>=20 >>>=20 >>> _______________________________________________ stir mailing list =20 >>> stir@ietf.org https://www.ietf.org/mailman/listinfo/stir >>>=20 >>>=20 >=20 > _______________________________________________ stir mailing list=20 > 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 michael.hammer@yaanatech.com Thu Jul 11 12:17:39 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF2F21F9D55 for ; Thu, 11 Jul 2013 12:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 JMnSaHgrockv for ; Thu, 11 Jul 2013 12:17:35 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id AAA5A21F9D49 for ; Thu, 11 Jul 2013 12:17:35 -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, 11 Jul 2013 12:17:33 -0700 From: Michael Hammer To: "timothy.dwight@verizon.com" , "stephen.farrell@cs.tcd.ie" , "Brian.Rosen@neustar.biz" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIBWXEGbn3ibkCpY0NkPYfuGZlgOFKAgAAEgQCAAANtAIAAAaEAgAAGyYCAAAWlgP//i45A Date: Thu, 11 Jul 2013 19:17:32 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC1433A@EX2K10MB1.corp.yaanatech.com> References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <51DEF814.9080704@cs.tcd.ie> <66490626-323F-46DF-8D22-D1677C17FE76@neustar.biz> <51DEFF23.20002@cs.tcd.ie> <2B0F677F0B95454297753F58D4A07FA3012938CE38@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3012938CE38@FHDP1LUMXC7V31.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.65] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0274_01CE7E49.C37E74C0" MIME-Version: 1.0 Cc: "rlb@ipv.sx" , "stir@ietf.org" , "housley@vigilsec.com" , "Gonzalo.Camarillo@ericsson.com" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 19:17:40 -0000 ------=_NextPart_000_0274_01CE7E49.C37E74C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We could refer to the use of associated delimiters/tags, such as the "+" as needed. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dwight, Timothy M (Tim) Sent: Thursday, July 11, 2013 3:14 PM To: Stephen Farrell; Rosen, Brian Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter How about "International E.164 number"? That's the phrase actually used in Rec. E.164 to refer to the combination of Country Code and National Significant Number. The practice of preceding an International E.164 number with a '+' comes from Rec. E.123, "Notation for national and international telephone numbers, e-mail addresses and web addresses". E.123 addresses how certain types of addresses should be expressed, for maximum clarity. It refers to the '+' symbol, by the way, as the "International prefix symbol". In principle the '+ is not part of the number, it is a "visual clue" to the reader, reminding him or her to dial the international prefix (e.g., '01' in the U.S.). tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: Thursday, July 11, 2013 1:53 PM To: Rosen, Brian Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter On 07/11/2013 07:29 PM, Rosen, Brian wrote: > So maybe where we say "where the identity being authenticated is a > telephone number" add "in e.164 format"? Better all right. Some people were saying "full e.164" which I guess means including country code and a +, which'd be even better, if its not already implied in e.164. S > > Brian > > On Jul 11, 2013, at 2:23 PM, Stephen Farrell > wrote: > >> >> Hiya, >> >> Sorry one other thing I forgot before. There was a longish thread on >> what's a phone number (full E.164, local etc.) that I thought did >> reach a sort of conclusion that full E.164 will be the thing that is >> signed. If that's your and Russ' reading of the result then it might >> be good to say that too. If you and Russ are less sure then I guess >> the current text is right. >> >> And a little more below... >> >> On 07/11/2013 07:11 PM, Rosen, Brian wrote: >>> Inline On Jul 11, 2013, at 1:54 PM, Stephen Farrell >>> wrote: >>> >>>> >>>> Hi Russ, >>>> >>>> I think this looks pretty good. A few wordsmithing changes and a >>>> question below but I have one addition to suggest: >>>> >>>> Somewhere this should say that the solution chosen needs to have an >>>> acceptable overhead at both signer and verifer or else it also >>>> won't be deployed. There may be some on here who could suggest >>>> indicative timing or networking constraints (e.g. not having to do >>>> ~5 OCSP transactions to possibly anywhere in the >>>> world) and if so, that'd be a good thing to include IMO. >>> I'll think about how to add some text for this. I think >>> "deployable" is really, really important in this effort. >> >> Fully agree and look forward to seeing that text. >> >>>> >>>> On 07/11/2013 03:21 PM, Russ Housley wrote: >>>>> Dear STIR Mail List Participants: >>>>> >>>>> Brian and I have tried to pull together charter text based on the >>>>> discussion to date. >>>>> >>>>> The closer we can get to consensus on the list before the BOF, the >>>>> more likely that we can get a WG shortly after Berlin. To this >>>>> end, please review and comment on the attached text. Brian and I >>>>> will hold the pen for updates to the text. >>>>> >>>>> Russ >>>>> >>>>> = = = = = >>>>> >>>>> Name: Secure Telephone Identity Revisited (stir) Area: RAI >>>>> >>>>> Chairs: TBD Area Advisor: Richard Barnes >>>>> >>>>> Mailing list: stir@ietf.org To Subscribe: >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>> >>>>> 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. As with email, the claimed source >>>>> identity of a SIP request is not verified, and this permits >>>>> unauthorized use of source identities as part of deceptive and >>>>> coercive activities, such as robocalling (bulk unsolicited >>>>> commercial communications), vishing (voicemail hacking, and >>>>> impersonating banks) and swatting (impersonating callers to >>>>> emergency services to stimulate unwarranted large scale law >>>>> enforcement deployments). This working group will define a >>>>> deployable mechanism to validate the identity of the calling party >>>>> that can be verified by entities in the path of a call. >>>>> >>>>> SIP is one of the main VoIP technologies used by parties that want >>>>> to present an incorrect origination. A number of previous efforts >>>>> have tried to secure the origins of SIP communications, including >>>>> RFC 3325, RFC 4474, and the VIPR working group. To date, however, >>>>> true validation of the source of SIP calls has not seen any >>>>> appreciable deployment. >>>>> Several factors contributed to this lack of success, >>>>> including: failure of the problem to be seen as critical at the >>>>> time; lack of any real means of asserting authority over telephone >>>>> numbers; misalignment of the mechanisms proposed by RFC 4474 with >>>>> the complex deployment environment that has emerged for SIP; lack >>>>> of end-to-end SIP session establishment; and inherent operational >>>>> problems with a transitive trust model. >>>>> >>>>> Initially, the working group will specify an in-band mechanism to >>>>> authenticate the originator of a SIP session where the identity >>>>> being authenticated is a telephone number and the session is >>>>> established with SIP end to end. The working group will consider >>>>> choices for protecting the identity information and the >>>>> credentials used, but will likely be similar to the methods >>>>> described in RFC 4474, which employs a signature over a set of >>>>> information in the SIP headers using a credential assigned to the >>>>> identity. >>>> >>>> I suggest replacing the above with >>>> >>>> "will likely be based on a digital signature mechanism that is >>>> cryptographically similar to the one described in RFC 4474 and >>>> where the signature continues to be represented in SIP headers." >>>> >>>> Saying "methods" and 4474 is a bit vague and could be read to mean >>>> "s/mime-based" or "cms based" or "x.509 based" whereas what I think >>>> we want is just to say its a signature. >>>> >>>> Similarly "assigned to the identity" is very ambiguous and probably >>>> better just omitted for now. >>> We're discussing changes to this text on this thread. >> >> Yeah. Consider the above another suggestion along the lines of what >> (I think) Dave was getting at (I think - I've been known to get that >> wrong before:-) >> >>>>> In order to be authoritative, credentials used with this mechanism >>>>> will be derived from existing telephone number assignment and >>>>> delegation models. >>>> >>>> No specific change suggested but are we using credential here to >>>> mean the private key or a (set of) TN(s) associated with a public >>>> key? I think it ought be the latter. >>> Of course it's both - the sender needs the private key to sign and >>> the verifier needs the public key to verify, so "credentials" >>> means both. We're trying not to start with a firm assumption of >>> X.509 certs, so it's intentionally somewhat vague. A credential is >>> associated with a (set of) TN(s). >> >> Probably best to leave the precise definition to the WG so I won't >> quibble with the above (yet:-). >> >>>>> That is, when a telephone number or range of telephone numbers is >>>>> delegated to an entity, a credential will accompany such >>>>> delegation. >>>> >>>> That's problematic with either definition of credential. I think >>>> it'd be ok to say: >>>> >>>> That is, when a telephone number or range of telephone numbers is >>>> delegated to an entity, relevant credentials will be generated (or >>>> modified) to reflect such delegation. >>> I am fine making this edit >> >> Great. >> >>>>> The mechanism must allow parties who are not delegated a telephone >>>>> number, but are preauthorized by the entity who is delegated the >>>>> number, to place calls using the identity. >>>> >>>> No specific change suggested, but I've always wondered if this >>>> requirement is real. I'd argue enough good would be done without >>>> try to stretch for this. But I defer to those who know more about >>>> the application. >>> It's very real and we could not deploy without it. An easy example >>> is a contracted outbound call center operating on behalf of your >>> bank. The bank wants it's number used as the calling party number, >>> not the call center's trunk assignment. Among other things, it >>> wants a return call resulting from the outbound call. The bank >>> explicitly permits this. In our terms, it would do another level of >>> delegation. >> >> Fair enough. >> >>> >>> >>>> >>>>> Expansion of the authentication mechanism to identities using the >>>>> user@domain form should be considered in the initial design. >>>> >>>> To be honest, I didn't read that thread (one too many:-) but I'm >>>> surprised that this is to be part of the initial design. >>>> But "considered" is sort of weasel-wordy so I'm not sure what's >>>> really meant - what is "considered" meant to mean here? >>> The problem we're solving is existing robocalling, vishing and >>> swatting, which presently is TN based. I think we all want to >>> anticipate greenfield sip uri's, lest we fix one problem and cause >>> another. >> >> So your response doesn't help me interpret "considered." Maybe it is >> meant as weasel-wording and sometimes that is the right thing to do, >> but I suspect it reads a bit too strong - as if the WG are gonna >> spend a lot of time on non-E.164 names so I'd say weakening it at >> least and ideally being more precise about what "considered" >> means would be good and might avoid later problems. >> >> Cheers, S. >> >>> >>>> >>>> Cheers, S. >>>> >>>>> After completing the SIP end to end solution, the working group >>>>> will consider session establishment where there are one or more >>>>> non-SIP hops, most likely using an out-of-band authentication >>>>> mechanism. However, the in-band and out-of-band mechanisms should >>>>> share as much in common as possible, especially the credentials. >>>>> >>>>> The working group will coordinate with the Security Area on >>>>> credential management. >>>>> >>>>> The working group will coordinate with other working groups in the >>>>> RAI Area regarding signaling through existing deployments, >>>>> including INSIPID. >>>>> >>>>> Authenticated identity is closely linked to privacy, and one >>>>> frequently 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. >>>>> >>>>> 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 >>>>> >>>>> >>>>> The working group will deliver the following: >>>>> >>>>> - A problem statement detailing the deployment environment and >>>>> situation that motivate work on secure telephone identity >>>>> >>>>> - A mechanism document describing the SIP end-to-end with >>>>> telephone number-based identities >>>>> >>>>> - A document describing the credentials required to support secure >>>>> telephone identity >>>>> >>>>> - A fallback mechanism to allow out-of-band identity establishment >>>>> during call setup >>>>> >>>>> Milestones >>>>> >>>>> Sep 2013 Submit problem statement for Informational Nov >>>>> 2013 Submit RFC4474bis for Proposed Standard Feb 2014 Submit >>>>> credential specification for Proposed Standard Jun >>>>> 2014 Submit fallback for Proposed Standard >>>>> >>>>> _______________________________________________ stir mailing list >>>>> stir@ietf.org https://www.ietf.org/mailman/listinfo/stir >>>>> >>>>> >>> >>> _______________________________________________ stir mailing list >>> stir@ietf.org https://www.ietf.org/mailman/listinfo/stir >>> >>> > > _______________________________________________ stir mailing list > stir@ietf.org https://www.ietf.org/mailman/listinfo/stir > > _______________________________________________ stir mailing 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_0274_01CE7E49.C37E74C0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx MTE5MTczMVowIwYJKoZIhvcNAQkEMRYEFOYcr1qCbnT7M7Ol7UByOEwU+1LDMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAKGYaBq7MB0ECVL+kX9H1+n9SUHFgyCDFQhGWIK2Q oJV+/aima4D1B5LmC500DCID3/tti7Jq6+LbVJRDn3lnDDwYIzg4oDH8Me/+ACJwBi8c8vY1bh6f wGO+MtRSoof63P8ih2ReDROSZGQN3G83sQ1/6lfC5FgSxJVMgpCiqvHNOqbdJYgZBtN46I246XAg 1uzw8U3ODTNYQuGc3oBV0daCj9zFo6GN7/9v610sHRNOi1W1+UYpYTtP6LTMwoCOx/YWIm26Eg9w 9DBmaFsx+2WBlH20Jyv4WIRrxdGFhTP6o4IVOyasbM3Z5RxrKyM+kFfLL/o85a73DJc+J5zxOwAA AAAAAA== ------=_NextPart_000_0274_01CE7E49.C37E74C0-- From michael.hammer@yaanatech.com Thu Jul 11 12:20: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 7D7B721F9E6B for ; Thu, 11 Jul 2013 12:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 itFkNgUVoQ6O for ; Thu, 11 Jul 2013 12:20: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 86CD821F9D28 for ; Thu, 11 Jul 2013 12:20: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; Thu, 11 Jul 2013 12:20:23 -0700 From: Michael Hammer To: "dcrocker@bbiw.net" , "Brian.Rosen@neustar.biz" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIBWXEGbn3ibkCpY0NkPYfuGZlgOFKAgAAEgQCAAAmcAP//k9fw Date: Thu, 11 Jul 2013 19:20:22 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC14378@EX2K10MB1.corp.yaanatech.com> References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <51DEFD44.8090100@dcrocker.net> In-Reply-To: <51DEFD44.8090100@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_0279_01CE7E4A.28C0B280" MIME-Version: 1.0 Cc: "rlb@ipv.sx" , "stir@ietf.org" , "housley@vigilsec.com" , "Gonzalo.Camarillo@ericsson.com" , "stephen.farrell@cs.tcd.ie" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 19:20:27 -0000 ------=_NextPart_000_0279_01CE7E4A.28C0B280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit It is more than just computation. It is the question of call setup time, which is very important for telephony. You don't want to have people hang up and dial again and again because they think the system is not working right. It is a quality of experience measure. We don't want the cure to be worse than the disease. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dave Crocker Sent: Thursday, July 11, 2013 2:45 PM To: Rosen, Brian Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo; Stephen Farrell Subject: Re: [stir] Draft STIR Charter On 7/11/2013 11:11 AM, Rosen, Brian wrote: >> Somewhere this should say that the solution chosen needs to have an >> acceptable overhead at both signer and verifer or else it also won't >> be deployed. There may be some on here who could suggest indicative >> timing or networking constraints (e.g. not having to do ~5 OCSP >> transactions to possibly anywhere in the world) and if so, that'd be >> a good thing to include IMO. > I'll think about how to add some text for this. I think "deployable" is really, really important in this effort. I assume Stephen means computational overhead. There's also the matter of administrative overhead, which has been a much higher barrier to adoption for DKIM and DMARC. To say "acceptable" invites debate about what it means. If the charter simply says "the design will attend to computational and administrative overhead, and exchange latency", it raises the necessary flags while avoiding concern for criteria in the charter. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_0279_01CE7E4A.28C0B280 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx MTE5MjAyMVowIwYJKoZIhvcNAQkEMRYEFIWE8InrMZE0dVxM+BleJIDFG0asMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAagByZRzMFH8s90nGH8H9Cuw2o54gK815cGNP3yY2 N2GpXtXq/bpD7UiHnIonjQiUaPHYkg5NBn2rAwBVfdVZeQ3d+/LvoRnPnv2shdwrVF7B9dJOIXGV ylfVpjgvguRfE1lSWMnbfJCD6i3vPjb0P2mKj7mzKC5eCTuIfZ1LXBF8HwXAS+beAWZKepB15Y5L MIIgk5LLulvG0jBWJ+Rp4LXJv/hhatOCHgFZcNFwJ0jgHxBKpTcBF/iHNTUABBFHiTMJ8dxzjCfl Scjdcy0pFUkdNT3J3ZYdLTCjnYvJXWDrh4i2YcjF/xPQsKDupt65W0xrnp0zKhhurmluHw4rywAA AAAAAA== ------=_NextPart_000_0279_01CE7E4A.28C0B280-- From timothy.dwight@verizon.com Thu Jul 11 12:23: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 464BE21F9C06 for ; Thu, 11 Jul 2013 12:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 FKh9I0Xz-lHR for ; Thu, 11 Jul 2013 12:23:00 -0700 (PDT) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) by ietfa.amsl.com (Postfix) with ESMTP id B1FCF21F9CC7 for ; Thu, 11 Jul 2013 12:23:00 -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; 11 Jul 2013 19:22:58 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.89,1045,1367971200"; d="scan'208";a="515281741" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi01.verizon.com with ESMTP; 11 Jul 2013 19:22:57 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Thu, 11 Jul 2013 15:22:57 -0400 To: Henning Schulzrinne , 'Stephen Farrell' , "Rosen, Brian" Date: Thu, 11 Jul 2013 15:22:55 -0400 Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIF2w2hhDzu+kKP+YqzEEYfuplgBgeAgAAEgQCAAANuAIAAAaEAgAAGyYD//73RMIAABfoQ Message-ID: <2B0F677F0B95454297753F58D4A07FA3012938CE59@FHDP1LUMXC7V31.us.one.verizon.com> References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <51DEF814.9080704@cs.tcd.ie> <66490626-323F-46DF-8D22-D1677C17FE76@neustar.biz> <51DEFF23.20002@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Richard Barnes , "" , Russ Housley , Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 19:23:06 -0000 Henning, I think what you describe is what Rec. E.164 calls an International E.164 n= umber. It also discusses National (Significant) Numbers, which are the Int= ernational E.164 number minus the Country Code. tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hen= ning Schulzrinne Sent: Thursday, July 11, 2013 2:00 PM To: 'Stephen Farrell'; Rosen, Brian Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter E.164 implies full phone number. >From E.164, Section 6.2: The international ITU-T E.164-number is composed of a variable number of de= cimal digits arranged in specific code fields. The international ITU-T E.16= 4-number code fields are the country code (CC) and remaining fields are spe= cific to the use being made of the international ITU-T E.164 number as show= n in Figures 1 to 5. A numbering plan does not include prefixes, suffixes, and additional inform= ation required to complete a call. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Ste= phen Farrell Sent: Thursday, July 11, 2013 2:53 PM To: Rosen, Brian Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter On 07/11/2013 07:29 PM, Rosen, Brian wrote: > So maybe where we say "where the identity being authenticated is a=20 > telephone number" add "in e.164 format"? Better all right. Some people were saying "full e.164" which I guess means = including country code and a +, which'd be even better, if its not already = implied in e.164. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From brian.rosen@neustar.biz Thu Jul 11 12: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 7904021F9EE6 for ; Thu, 11 Jul 2013 12:25:29 -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 oF9CweQQ4-Ob for ; Thu, 11 Jul 2013 12:25:25 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 9252D21F9C06 for ; Thu, 11 Jul 2013 12:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1373570675; x=1688929392; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=viqBzmmwwi nOYwPwu2pMMECKA8bKAD8yLHb3HK46dUE=; b=Fm/i54M/bNmf6l9D7k2GWipHHV CbxTY5tZXRwxDdhsuAU3f2OuTY+dpzNX4X+Nhx9rdz5DfDpEQkTA+QQAINPw== Received: from ([10.31.58.69]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.22205269; Thu, 11 Jul 2013 15:24:34 -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, 11 Jul 2013 15:25:06 -0400 From: "Rosen, Brian" To: Michael Hammer Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkH7PavsqszcIEumRBC5KQ07J5lgBgeAgAAEgICAAAmeAIAACcUAgAABUgA= Date: Thu, 11 Jul 2013 19:25:06 +0000 Message-ID: References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <51DEFD44.8090100@dcrocker.net> <00C069FD01E0324C9FFCADF539701DB3BBC14378@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC14378@EX2K10MB1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.192.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: pw89RJJY+9IyEUHpNG5B7w== Content-Type: text/plain; charset="us-ascii" Content-ID: <8813AF9B5C66ED469B6FD388E1539905@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rlb@ipv.sx" , "housley@vigilsec.com" , "Gonzalo.Camarillo@ericsson.com" , "stir@ietf.org" , "dcrocker@bbiw.net" , "stephen.farrell@cs.tcd.ie" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 19:25:29 -0000 Send text please. I'm willing to add something, buy don't see consensus on= what yet. I'd rewrite Dave's suggestion to use "consider" as opposed to "attend to", = but what do you want to do? Brian On Jul 11, 2013, at 3:20 PM, Michael Hammer wrote: > It is more than just computation. It is the question of call setup time, > which is very important for telephony. > You don't want to have people hang up and dial again and again because th= ey > think the system is not working right. > It is a quality of experience measure. We don't want the cure to be wors= e > than the disease. >=20 > Mike >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of D= ave > Crocker > Sent: Thursday, July 11, 2013 2:45 PM > To: Rosen, Brian > Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo; > Stephen Farrell > Subject: Re: [stir] Draft STIR Charter >=20 > On 7/11/2013 11:11 AM, Rosen, Brian wrote: >>> Somewhere this should say that the solution chosen needs to have an=20 >>> acceptable overhead at both signer and verifer or else it also won't=20 >>> be deployed. There may be some on here who could suggest indicative=20 >>> timing or networking constraints (e.g. not having to do ~5 OCSP=20 >>> transactions to possibly anywhere in the world) and if so, that'd be=20 >>> a good thing to include IMO. >> I'll think about how to add some text for this. I think "deployable" is > really, really important in this effort. >=20 >=20 > I assume Stephen means computational overhead. There's also the matter o= f > administrative overhead, which has been a much higher barrier to adoption > for DKIM and DMARC. >=20 > To say "acceptable" invites debate about what it means. >=20 > If the charter simply says "the design will attend to computational and > administrative overhead, and exchange latency", it raises the necessary > flags while avoiding concern for criteria in the charter. >=20 > d/ >=20 > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From housley@vigilsec.com Thu Jul 11 12:31: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 15F3A21F9EE4 for ; Thu, 11 Jul 2013 12:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 g7-L8-Ds1mV6 for ; Thu, 11 Jul 2013 12:31:14 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id D56ED21F9EAE for ; Thu, 11 Jul 2013 12:31:13 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 55412F24086; Thu, 11 Jul 2013 15:31:29 -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 7qig9FYsxEyX; Thu, 11 Jul 2013 15:31: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 8D957F24085; Thu, 11 Jul 2013 15:31:24 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <51DEF16D.2070909@cs.tcd.ie> Date: Thu, 11 Jul 2013 15:31:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1085) Cc: Richard Barnes , stir@ietf.org, Gonzalo Camarillo , Brian Rosen Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 19:31:19 -0000 Stephen: > I think this looks pretty good. A few wordsmithing changes > and a question below but I have one addition to suggest: >=20 > Somewhere this should say that the solution chosen needs to > have an acceptable overhead at both signer and verifer or > else it also won't be deployed. There may be some on here > who could suggest indicative timing or networking constraints > (e.g. not having to do ~5 OCSP transactions to possibly > anywhere in the world) and if so, that'd be a good thing > to include IMO. Does this single sentence capture your point? To make deployment of this solution more likely, consideration must be = given to the overhead for the call source and all verifiers. >=20 > On 07/11/2013 03:21 PM, Russ Housley wrote: >> Dear STIR Mail List Participants: >>=20 >> Brian and I have tried to pull together charter text based on the >> discussion to date. >>=20 >> The closer we can get to consensus on the list before the BOF, the >> more likely that we can get a WG shortly after Berlin. To this end, >> please review and comment on the attached text. Brian and I will >> hold the pen for updates to the text. >>=20 >> Russ >>=20 >> =3D =3D =3D =3D =3D >>=20 >> Name: Secure Telephone Identity Revisited (stir) Area: RAI >>=20 >> Chairs: TBD Area Advisor: Richard Barnes >>=20 >> Mailing list: stir@ietf.org To Subscribe: >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> 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. As with email, the claimed source identity >> of a SIP request is not verified, and this permits unauthorized use >> of source identities as part of deceptive and coercive activities, >> such as robocalling (bulk unsolicited commercial communications), >> vishing (voicemail hacking, and impersonating banks) and swatting >> (impersonating callers to emergency services to stimulate unwarranted >> large scale law enforcement deployments). This working group will >> define a deployable mechanism to validate the identity of the calling >> party that can be verified by entities in the path of a call. >>=20 >> SIP is one of the main VoIP technologies used by parties that want to >> present an incorrect origination. A number of previous efforts have >> tried to secure the origins of SIP communications, including RFC >> 3325, RFC 4474, and the VIPR working group. To date, however, true >> validation of the source of SIP calls has not seen any appreciable >> deployment. Several factors contributed to this lack of success, >> including: failure of the problem to be seen as critical at the time; >> lack of any real means of asserting authority over telephone numbers; >> misalignment of the mechanisms proposed by RFC 4474 with the complex >> deployment environment that has emerged for SIP; lack of end-to-end >> SIP session establishment; and inherent operational problems with a >> transitive trust model. >>=20 >> Initially, the working group will specify an in-band mechanism to >> authenticate the originator of a SIP session where the identity being >> authenticated is a telephone number and the session is established >> with SIP end to end. The working group will consider choices for >> protecting the identity information and the credentials used, but >> will likely be similar to the methods described in RFC 4474, which >> employs a signature over a set of information in the SIP headers >> using a credential assigned to the identity. >=20 > I suggest replacing the above with >=20 > "will likely be based on a digital signature mechanism that is > cryptographically similar to the one described in RFC 4474 and > where the signature continues to be represented in SIP headers." >=20 > Saying "methods" and 4474 is a bit vague and could be read to > mean "s/mime-based" or "cms based" or "x.509 based" whereas > what I think we want is just to say its a signature. >=20 > Similarly "assigned to the identity" is very ambiguous and > probably better just omitted for now. Some means of associating the identity with the public key is needed. How about: The working group will consider choices for protecting the identity = information and the credentials used, but will likely be based on a = digital signature mechanism that covers a set of information in the SIP = headers, and verification will employ a credential that contains the = public key and is associated with the identity.=20 >=20 >=20 >> In order to be >> authoritative, credentials used with this mechanism will be derived >> from existing telephone number assignment and delegation models. >=20 > No specific change suggested but are we using credential here to > mean the private key or a (set of) TN(s) associated with a > public key? I think it ought be the latter. Does the above also resolve this question? >=20 >> That is, when a telephone number or range of telephone numbers is >> delegated to an entity, a credential will accompany such delegation. >=20 > That's problematic with either definition of credential. I think > it'd be ok to say: >=20 > That is, when a telephone number or range of telephone numbers is > delegated to an entity, relevant credentials will be generated (or > modified) to reflect such delegation. This seems fine to me. >=20 >> The mechanism must allow parties who are not delegated a telephone >> number, but are preauthorized by the entity who is delegated the >> number, to place calls using the identity. =20 >=20 > No specific change suggested, but I've always wondered if this > requirement is real. I'd argue enough good would be done without > try to stretch for this. But I defer to those who know more about > the application. >=20 >> Expansion of the >> authentication mechanism to identities using the user@domain form >> should be considered in the initial design. =20 >=20 > To be honest, I didn't read that thread (one too many:-) but I'm > surprised that this is to be part of the initial design. But > "considered" is sort of weasel-wordy so I'm not sure what's > really meant - what is "considered" meant to mean here? If we come up with a clean way to handle both identity forms (telephone = numbers and user@domain), then this would be really useful for everyone. = But, we are chartered for telephone numbers... Russ From michael.hammer@yaanatech.com Thu Jul 11 12:32: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 0E8DE21F9F37 for ; Thu, 11 Jul 2013 12:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 GMPFXtpm9ouG for ; Thu, 11 Jul 2013 12:32: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 4FD0921F9EAE for ; Thu, 11 Jul 2013 12:32:25 -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, 11 Jul 2013 12:32:24 -0700 From: Michael Hammer To: "timothy.dwight@verizon.com" , "Henning.Schulzrinne@fcc.gov" , "stephen.farrell@cs.tcd.ie" , "Brian.Rosen@neustar.biz" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIBWXEGbn3ibkCpY0NkPYfuGZlgOFKAgAAEgQCAAANtAIAAAaEAgAAGyYCAAAH7AIAABkaA//+MAvA= Date: Thu, 11 Jul 2013 19:32:22 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC143E4@EX2K10MB1.corp.yaanatech.com> References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <51DEF814.9080704@cs.tcd.ie> <66490626-323F-46DF-8D22-D1677C17FE76@neustar.biz> <51DEFF23.20002@cs.tcd.ie> <2B0F677F0B95454297753F58D4A07FA3012938CE59@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3012938CE59@FHDP1LUMXC7V31.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.65] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02A1_01CE7E4B.D64AB3F0" MIME-Version: 1.0 Cc: "rlb@ipv.sx" , "stir@ietf.org" , "housley@vigilsec.com" , "Gonzalo.Camarillo@ericsson.com" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 19:32:38 -0000 ------=_NextPart_000_02A1_01CE7E4B.D64AB3F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tim, The national specific part is a sub-component of the complete E.164 number. You wouldn't call a car complete if you took the engine out. :) Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dwight, Timothy M (Tim) Sent: Thursday, July 11, 2013 3:23 PM To: Henning Schulzrinne; 'Stephen Farrell'; Rosen, Brian Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter Henning, I think what you describe is what Rec. E.164 calls an International E.164 number. It also discusses National (Significant) Numbers, which are the International E.164 number minus the Country Code. tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Thursday, July 11, 2013 2:00 PM To: 'Stephen Farrell'; Rosen, Brian Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter E.164 implies full phone number. >From E.164, Section 6.2: The international ITU-T E.164-number is composed of a variable number of decimal digits arranged in specific code fields. The international ITU-T E.164-number code fields are the country code (CC) and remaining fields are specific to the use being made of the international ITU-T E.164 number as shown in Figures 1 to 5. A numbering plan does not include prefixes, suffixes, and additional information required to complete a call. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: Thursday, July 11, 2013 2:53 PM To: Rosen, Brian Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter On 07/11/2013 07:29 PM, Rosen, Brian wrote: > So maybe where we say "where the identity being authenticated is a > telephone number" add "in e.164 format"? Better all right. Some people were saying "full e.164" which I guess means including country code and a +, which'd be even better, if its not already implied in e.164. _______________________________________________ stir mailing 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_02A1_01CE7E4B.D64AB3F0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx MTE5MzIyMlowIwYJKoZIhvcNAQkEMRYEFAoNuRpneQ4O3wdtRE//RgNdoUa3MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAFYyMbSNWBMM3Of/uAA9f4y0YZu8Hi0O8/4+T2sQW UjGJ7fUO8kggVo15TqTxtvw11Sy0Dhy6eD5GZeBn0YEU+oVXrb/2avbDVNov3TsqBFIn0BpNqjqn U5JEg2yo5GJCaESz1R4T2/3J7lRPvFqK2feY2r9qO/ynK3gxXiXMkJjxKwM9eCWAYOxsVGWp27lY oUALlb+RAXlBHWvlsBLPObkj7ZIb+mXwYwzNFzasxlir0OyIqXqURlpUFHkeG8YIlFCW5c1imp9R gT2wDavAMBy43crkTZwCn6vgYWBw12GLEY2vNV7m+euZxFiG4/svyXkAoXUCwx+Wa9Rc/EOk2AAA AAAAAA== ------=_NextPart_000_02A1_01CE7E4B.D64AB3F0-- From michael.hammer@yaanatech.com Thu Jul 11 12:39: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 6988321F999C for ; Thu, 11 Jul 2013 12:39:33 -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 afRU+8mYB0f7 for ; Thu, 11 Jul 2013 12:39:29 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 7086811E8114 for ; Thu, 11 Jul 2013 12:39:24 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Thu, 11 Jul 2013 12:39:24 -0700 From: Michael Hammer To: "Brian.Rosen@neustar.biz" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIBWXEGbn3ibkCpY0NkPYfuGZlgOFKAgAAEgQCAAAmcAP//k9fwgAB3QQD//41swA== Date: Thu, 11 Jul 2013 19:39:23 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC14411@EX2K10MB1.corp.yaanatech.com> References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <51DEFD44.8090100@dcrocker.net> <00C069FD01E0324C9FFCADF539701DB3BBC14378@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.65] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02A6_01CE7E4C.D0CC7E80" MIME-Version: 1.0 Cc: "rlb@ipv.sx" , "housley@vigilsec.com" , "Gonzalo.Camarillo@ericsson.com" , "stir@ietf.org" , "dcrocker@bbiw.net" , "stephen.farrell@cs.tcd.ie" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 19:39:33 -0000 ------=_NextPart_000_02A6_01CE7E4C.D0CC7E80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The solution must not noticeably degrade the end-user's usage experience, e.g. call setup times unacceptably delayed. The WG can assess what an acceptable trade-off might be. Mike -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Thursday, July 11, 2013 3:25 PM To: Michael Hammer Cc: dcrocker@bbiw.net; rlb@ipv.sx; stir@ietf.org; housley@vigilsec.com; Gonzalo.Camarillo@ericsson.com; stephen.farrell@cs.tcd.ie Subject: Re: [stir] Draft STIR Charter Send text please. I'm willing to add something, buy don't see consensus on what yet. I'd rewrite Dave's suggestion to use "consider" as opposed to "attend to", but what do you want to do? Brian On Jul 11, 2013, at 3:20 PM, Michael Hammer wrote: > It is more than just computation. It is the question of call setup > time, which is very important for telephony. > You don't want to have people hang up and dial again and again because > they think the system is not working right. > It is a quality of experience measure. We don't want the cure to be > worse than the disease. > > Mike > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of Dave Crocker > Sent: Thursday, July 11, 2013 2:45 PM > To: Rosen, Brian > Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo; > Stephen Farrell > Subject: Re: [stir] Draft STIR Charter > > On 7/11/2013 11:11 AM, Rosen, Brian wrote: >>> Somewhere this should say that the solution chosen needs to have an >>> acceptable overhead at both signer and verifer or else it also won't >>> be deployed. There may be some on here who could suggest indicative >>> timing or networking constraints (e.g. not having to do ~5 OCSP >>> transactions to possibly anywhere in the world) and if so, that'd be >>> a good thing to include IMO. >> I'll think about how to add some text for this. I think "deployable" >> is > really, really important in this effort. > > > I assume Stephen means computational overhead. There's also the > matter of administrative overhead, which has been a much higher > barrier to adoption for DKIM and DMARC. > > To say "acceptable" invites debate about what it means. > > If the charter simply says "the design will attend to computational > and administrative overhead, and exchange latency", it raises the > necessary flags while avoiding concern for criteria in the charter. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_02A6_01CE7E4C.D0CC7E80 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx MTE5MzkyMlowIwYJKoZIhvcNAQkEMRYEFKusORve4br8RjNWu5RTH7ugpzVvMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAT2Ao90tZMv4laPHFe3aI1dNzk5+KoJ093Wz2hfHJ wvVgqDMPH4jb4CdG2RVgGDlgJXGMR90b0syksSkYMjn3yHJHjc/NoMUEZ7PVQjWU1wAUdMVTISDQ 9PXNbo78rCpWxlFgRz7MkNOKmj3aQOoTEAGFSgS3RW78b1XwyfgAiUOJ27+pVLm3Y2CE7o+xwPoh haTpTG9xw144hNBdsr+uspb8P73L9EZKGs2+oF3GZDdmAQ0TgzundqRpAmNa1PJvzwzcFVE+tFQ/ YW/Ftn3JvETizNz86ib2CAfugYkUkmn82zYcqJ6FGDhYAnGwCPZfR88tNP3zDUINkc+3AV8LsAAA AAAAAA== ------=_NextPart_000_02A6_01CE7E4C.D0CC7E80-- From housley@vigilsec.com Thu Jul 11 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 6694821F9A1B for ; Thu, 11 Jul 2013 12:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 IrOy0fMtu3yT for ; Thu, 11 Jul 2013 12:41:28 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 3769121F99F9 for ; Thu, 11 Jul 2013 12:41:26 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 5BCB3F24085; Thu, 11 Jul 2013 15:41:48 -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 kMW97mVlKm3t; Thu, 11 Jul 2013 15:41:24 -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 010D0F24082; Thu, 11 Jul 2013 15:41:46 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <51DEFD44.8090100@dcrocker.net> Date: Thu, 11 Jul 2013 15:41:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6DC8CCEA-7FF9-4B27-9679-E67CA248D3C2@vigilsec.com> References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <51DEFD44.8090100@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1085) Cc: Richard Barnes , "Rosen, Brian" , Gonzalo Camarillo , "" , Stephen Farrell Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 19:41:34 -0000 Dave: >>> Somewhere this should say that the solution chosen needs to >>> have an acceptable overhead at both signer and verifer or >>> else it also won't be deployed. There may be some on here >>> who could suggest indicative timing or networking constraints >>> (e.g. not having to do ~5 OCSP transactions to possibly >>> anywhere in the world) and if so, that'd be a good thing >>> to include IMO. >> I'll think about how to add some text for this. I think "deployable" = is really, really important in this effort. >=20 > I assume Stephen means computational overhead. There's also the = matter of administrative overhead, which has been a much higher barrier = to adoption for DKIM and DMARC. I took Stephen's point to be computational, memory, bits on the wire, = and administrative. All of them will be part of the engineering trade = off. Russ From Henning.Schulzrinne@fcc.gov Thu Jul 11 12: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 E55F721F995E for ; Thu, 11 Jul 2013 12:46:00 -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=[AWL=0.622, 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 bn8foJoKbgDV for ; Thu, 11 Jul 2013 12:45:56 -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 9BE3921F97C7 for ; Thu, 11 Jul 2013 12:45:55 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "'Dwight, Timothy M (Tim)'" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIF2w2hhDzu+kKP+YqzEEYfuplgBgeAgAAEgQCAAANuAIAAAaEAgAAGyYD//73RMIAABfoQgAAHvyA= Date: Thu, 11 Jul 2013 19:45:54 +0000 References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <51DEF814.9080704@cs.tcd.ie> <66490626-323F-46DF-8D22-D1677C17FE76@neustar.biz> <51DEFF23.20002@cs.tcd.ie> <2B0F677F0B95454297753F58D4A07FA3012938CE59@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3012938CE59@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: Richard Barnes , "" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 19:46:01 -0000 Yes, that would be the more precise term. -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com]=20 Sent: Thursday, July 11, 2013 3:23 PM To: Henning Schulzrinne; 'Stephen Farrell'; Rosen, Brian Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo Subject: RE: [stir] Draft STIR Charter Henning, I think what you describe is what Rec. E.164 calls an International E.164 n= umber. It also discusses National (Significant) Numbers, which are the Int= ernational E.164 number minus the Country Code. tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hen= ning Schulzrinne Sent: Thursday, July 11, 2013 2:00 PM To: 'Stephen Farrell'; Rosen, Brian Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter E.164 implies full phone number. >From E.164, Section 6.2: The international ITU-T E.164-number is composed of a variable number of de= cimal digits arranged in specific code fields. The international ITU-T E.16= 4-number code fields are the country code (CC) and remaining fields are spe= cific to the use being made of the international ITU-T E.164 number as show= n in Figures 1 to 5. A numbering plan does not include prefixes, suffixes, and additional inform= ation required to complete a call. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Ste= phen Farrell Sent: Thursday, July 11, 2013 2:53 PM To: Rosen, Brian Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter On 07/11/2013 07:29 PM, Rosen, Brian wrote: > So maybe where we say "where the identity being authenticated is a=20 > telephone number" add "in e.164 format"? Better all right. Some people were saying "full e.164" which I guess means = including country code and a +, which'd be even better, if its not already = implied in e.164. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From jon.peterson@neustar.biz Thu Jul 11 13:22: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 0343E11E8118 for ; Thu, 11 Jul 2013 13:22:35 -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.353, 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 9kECaGG3v5lc for ; Thu, 11 Jul 2013 13:22:30 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 7871921F99F9 for ; Thu, 11 Jul 2013 13:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1373574103; x=1688932945; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=dj+R49UF+v g0QI3bvGnMFTF7unVXg8D9fMNCMlp/22U=; b=JeDIUCofTjh1n3qjftY01wvG5x CrHgaGec3Bl2jgVCUYSmFsBQ9tS9dysyHmRhHgmv/iUfx8x2yuBEi1ADnNdw== Received: from ([10.31.58.69]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.22209088; Thu, 11 Jul 2013 16:21:41 -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, 11 Jul 2013 16:22:13 -0400 From: "Peterson, Jon" To: Michael Hammer , "timothy.dwight@verizon.com" , "Henning.Schulzrinne@fcc.gov" , "stephen.farrell@cs.tcd.ie" , "Rosen, Brian" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkICx1fsldqNdEa1H4oCYTQLxplgBgeAgAAEgQCAAANuAIAAAaEAgAAGyYCAAAH6AIAABkaAgAACpAD//5iRAA== Date: Thu, 11 Jul 2013 20:22:12 +0000 Message-ID: In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC143E4@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.119] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 09aq7aZWkgBOygD0LwLdVA== Content-Type: text/plain; charset="us-ascii" Content-ID: <589DC0A7A05A0B4F9C7B5454F5C187C3@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rlb@ipv.sx" , "stir@ietf.org" , "housley@vigilsec.com" , "Gonzalo.Camarillo@ericsson.com" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 20:22:35 -0000 My understanding was that certain nationally-specific numbers, such as freephone numbers, actually don't fall under the E.164 plan, and that thus restricting this to "E.164 numbers" may rule out some numbers we probably want to provide identity for. These numbers have the quality that they aren't reachable internationally. No? Jon Peterson Neustar, Inc. On 7/11/13 12:32 PM, "Michael Hammer" wrote: >Tim, > >The national specific part is a sub-component of the complete E.164 >number. > >You wouldn't call a car complete if you took the engine out. :) > >Mike > > >-----Original Message----- >From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >Dwight, Timothy M (Tim) >Sent: Thursday, July 11, 2013 3:23 PM >To: Henning Schulzrinne; 'Stephen Farrell'; Rosen, Brian >Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >Subject: Re: [stir] Draft STIR Charter > >Henning, > >I think what you describe is what Rec. E.164 calls an International E.164 >number. It also discusses National (Significant) Numbers, which are the >International E.164 number minus the Country Code. > >tim > >-----Original Message----- >From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >Henning Schulzrinne >Sent: Thursday, July 11, 2013 2:00 PM >To: 'Stephen Farrell'; Rosen, Brian >Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >Subject: Re: [stir] Draft STIR Charter > >E.164 implies full phone number. > >From E.164, Section 6.2: > >The international ITU-T E.164-number is composed of a variable number of >decimal digits arranged in specific code fields. The international ITU-T >E.164-number code fields are the country code (CC) and remaining fields >are >specific to the use being made of the international ITU-T E.164 number as >shown in Figures 1 to 5. >A numbering plan does not include prefixes, suffixes, and additional >information required to complete a call. > >-----Original Message----- >From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >Stephen Farrell >Sent: Thursday, July 11, 2013 2:53 PM >To: Rosen, Brian >Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >Subject: Re: [stir] Draft STIR Charter > > > >On 07/11/2013 07:29 PM, Rosen, Brian wrote: >> So maybe where we say "where the identity being authenticated is a >> telephone number" add "in e.164 format"? > >Better all right. Some people were saying "full e.164" which I guess means >including country code and a +, which'd be even better, if its not already >implied in e.164. > >_______________________________________________ >stir mailing 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 Thu Jul 11 13:30: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 E7B5311E812A for ; Thu, 11 Jul 2013 13:30:23 -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 E16SzhWfbQZv for ; Thu, 11 Jul 2013 13:30:20 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id A821F21F9396 for ; Thu, 11 Jul 2013 13:30:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1373574491; x=1688932882; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=RsDejUW/B/ 6mpvqWhFQd57bpYIaLeHpLJcR7q1JEjqM=; b=cCBH+0VtPIBZF34t3DUVb1dtrT mZuSuVzdDtSgQwW5w63rehgyN0vI/66P2Ep77DUzFMFnqcyr9N0ArDUJP4ag== Received: from ([10.31.58.71]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.20736476; Thu, 11 Jul 2013 16:28: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; Thu, 11 Jul 2013 16:29:36 -0400 From: "Rosen, Brian" To: "Peterson, Jon" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkH7PavsqszcIEumRBC5KQ07J5lgBgeAgAAEgICAAANvAIAAAaEAgAAGyYCAAAH6AIAABkaAgAACpACAAA3sAIAAAhCA Date: Thu, 11 Jul 2013 20:29:35 +0000 Message-ID: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@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.192.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: QmVJuS1CMvCEcrlp39aeIQ== Content-Type: text/plain; charset="us-ascii" Content-ID: <664F0C3635498E4FADF907F240582EC0@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rlb@ipv.sx" , "housley@vigilsec.com" , "Gonzalo.Camarillo@ericsson.com" , "stir@ietf.org" , "Henning.Schulzrinne@fcc.gov" , Michael Hammer , "timothy.dwight@verizon.com" , "stephen.farrell@cs.tcd.ie" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 20:30:24 -0000 Yeah, well, let's talk about that, because you are right. It really would be a good idea to be able to get a call which had a called = party number of 9-1-1 or 1-1-2 and was verifiably from that number. We certainly want to be able to handle "toll free" numbers, which in many c= ases are not actually e.164s, even though they look like them. The problem is that while the latter is usually easy to handle, because eve= n if 18005551212 is not truly an e.164, we certainly could canonicalize the= m as if they were and everything would work, doing that with 1-1-2 is anoth= er story. Probably not worth dealing with these issues in charter language. So, Stephen, unless someone can come up with some wording that works, I'd p= refer to defer the discussion to the work group (if/when we get one), rathe= r than do it in charter language. Brian On Jul 11, 2013, at 4:22 PM, "Peterson, Jon" wrote: >=20 > My understanding was that certain nationally-specific numbers, such as > freephone numbers, actually don't fall under the E.164 plan, and that thu= s > restricting this to "E.164 numbers" may rule out some numbers we probably > want to provide identity for. These numbers have the quality that they > aren't reachable internationally. No? >=20 > Jon Peterson > Neustar, Inc. >=20 > On 7/11/13 12:32 PM, "Michael Hammer" wrot= e: >=20 >> Tim, >>=20 >> The national specific part is a sub-component of the complete E.164 >> number. >>=20 >> You wouldn't call a car complete if you took the engine out. :) >>=20 >> Mike >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >> Dwight, Timothy M (Tim) >> Sent: Thursday, July 11, 2013 3:23 PM >> To: Henning Schulzrinne; 'Stephen Farrell'; Rosen, Brian >> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >> Subject: Re: [stir] Draft STIR Charter >>=20 >> Henning, >>=20 >> I think what you describe is what Rec. E.164 calls an International E.16= 4 >> number. It also discusses National (Significant) Numbers, which are the >> International E.164 number minus the Country Code. >>=20 >> tim >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >> Henning Schulzrinne >> Sent: Thursday, July 11, 2013 2:00 PM >> To: 'Stephen Farrell'; Rosen, Brian >> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >> Subject: Re: [stir] Draft STIR Charter >>=20 >> E.164 implies full phone number. >>=20 >> From E.164, Section 6.2: >>=20 >> The international ITU-T E.164-number is composed of a variable number of >> decimal digits arranged in specific code fields. The international ITU-T >> E.164-number code fields are the country code (CC) and remaining fields >> are >> specific to the use being made of the international ITU-T E.164 number a= s >> shown in Figures 1 to 5. >> A numbering plan does not include prefixes, suffixes, and additional >> information required to complete a call. >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >> Stephen Farrell >> Sent: Thursday, July 11, 2013 2:53 PM >> To: Rosen, Brian >> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >> Subject: Re: [stir] Draft STIR Charter >>=20 >>=20 >>=20 >> On 07/11/2013 07:29 PM, Rosen, Brian wrote: >>> So maybe where we say "where the identity being authenticated is a >>> telephone number" add "in e.164 format"? >>=20 >> Better all right. Some people were saying "full e.164" which I guess mea= ns >> including country code and a +, which'd be even better, if its not alrea= dy >> implied in e.164. >>=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 Henning.Schulzrinne@fcc.gov Thu Jul 11 13:35: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 7214311E8179 for ; Thu, 11 Jul 2013 13:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.601, 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 Tf4s-ej9rEby for ; Thu, 11 Jul 2013 13:35:04 -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 2298821F9B26 for ; Thu, 11 Jul 2013 13:35:03 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Hadriel Kaplan' , Michael Hammer Thread-Topic: [stir] Using Validated Numbers (was - Re: U.S. Senate hearing on robocalls July 10, 2013) Thread-Index: AQHOfj71VntVQdPrNUSz8foOLllXxZlfzsEAgAAkdgD///vCoA== Date: Thu, 11 Jul 2013 20:35:00 +0000 References: , <007201ce799a$34539360$9cfaba20$@shockey.us> <900A1E2059ADB149B905E3C8FA0046A62C77C39220@FHDP1LUMXC7V23.us.one.verizon.com> <01ad01ce7da0$5af26f00$10d74d00$@shockey.us> <52705969-970E-431A-9A9B-B24AAF69C082@oracle.com> <51DE3DDB.2000303@dcrocker.net> <00C069FD01E0324C9FFCADF539701DB3BBC13E48@EX2K10MB1.corp.yaanatech.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" , "york@isoc.org" , "dcrocker@bbiw.net" , "sanjay.mishra@verizon.com" Subject: Re: [stir] Using Validated Numbers (was - Re: U.S. Senate hearing on robocalls July 10, 2013) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 20:35:08 -0000 If all you have is a public-private key pair *for each number* (or final us= er), the "provider of record" (i.e., the one that's officially listed in th= e NPAC) can just hand the key pair to the customer. This works out as appro= ximately the same, minus the administration part, i.e., whether the "real" = entity contacts the NPAC and gets a cert, or the entity of record does. Unt= il non-carriers can generally be handed numbers, there are sensitivities he= re. -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com]=20 Sent: Thursday, July 11, 2013 12:47 PM To: Michael Hammer Cc: Henning Schulzrinne; dcrocker@bbiw.net; stir@ietf.org; york@isoc.org; s= anjay.mishra@verizon.com Subject: Re: [stir] Using Validated Numbers (was - Re: U.S. Senate hearing = on robocalls July 10, 2013) I think he meant the NPAC. Even if the NPAC held the keys/certs, we'd still want a way to do STIR dele= gation... because afaict the NPAC in its current form doesn't truly know t= he ultimate service provider. It appears to only know the regulated "carri= er" the number is assigned to, but that's not the ultimate service provider= really. There are hundreds of providers who aren't classified as "carrier= s", and don't want to be for legal/monetary reasons. They pay a real "carr= ier" to handle the number porting, so the NPAC only has that official carri= er in its database instead of the ultimate service provider. That official= carrier could be the one to sign the caller-id coming from its customer se= rvice providers, but we probably need a way for the real originating servic= e provider to do it instead. -hadriel On Jul 11, 2013, at 10:36 AM, Michael Hammer = wrote: > Correct me if I am wrong, but I didn't think the LERG went to 10 digits. >=20 > Mike >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 > Of Henning Schulzrinne > Sent: Thursday, July 11, 2013 10:00 AM > To: 'dcrocker@bbiw.net'; stir@ietf.org > Cc: 'Dan York'; 'Mishra, Sanjay' > Subject: Re: [stir] Using Validated Numbers (was - Re: U.S. Senate=20 > hearing on robocalls July 10, 2013) >=20 > A crucial component will be that >=20 > (1) *all* calls from a certain number are validated > (2) the receiver can know that this is the case ("DANE") >=20 > (2) can be a heuristic, given (1), but obviously explicit information=20 > is better. That way, targets that are particularly susceptible to=20 > individualized spoofing, such as financial institutions, can protect=20 > themselves first, just like they did by implementing TLS early on=20 > their web sites. That would prevent a fair amount of vishing. If we=20 > can then get the large outbound call centers to "incent" their=20 > carriers, most people will then only get three kinds of calls: > (a) validated business calls > (b) known numbers from friends and family > (c) unvalidated calls that are very likely to be robocalls and can, at=20 > least, be sent to voicemail and CAPTCHA >=20 > (2) may not be an Internet-facing directory, although that could be=20 > quite helpful. For example, this information could be contained in the=20 > LERG or other information made available by the numbering administrator. >=20 > -----Original Message----- > From: Dave Crocker [mailto:dhc@dcrocker.net] > Sent: Thursday, July 11, 2013 1:09 AM > To: stir@ietf.org > Cc: 'Dan York'; 'Mishra, Sanjay'; Henning Schulzrinne > Subject: Using Validated Numbers (was - Re: [stir] U.S. Senate hearing=20 > on robocalls July 10, 2013) >=20 >=20 >> Regardless, none of the robocall-blocking tactics I've seen will do=20 >> much in the long run unless we get the caller-id's to at least be=20 >> authenticate-able. Once we know the caller-ids can't be randomly=20 >> generated or spoof legitimate sources, doing whitelist/blacklist=20 >> things will be a lot more tenable. >=20 >=20 > Dumb question, since it seems clear that most folk already have a=20 > sense of the answer: Once there are some telephone numbers getting=20 > validated, how will this get used and by what components in the system? >=20 > I'm asking for more detail that the above text has, so that it's=20 > possible to consider the specifics of what to change and how it will=20 > work, such as during initial years of only partial adoption. >=20 > Over in email-abuse land, a wide range of assumptions were made about=20 > the use of authenticated names, but the actual uses have had some surpris= es. >=20 > To the extent that there is agreement on the specific uses that are=20 > planned for validated telephone numbers, it can sometimes help to=20 > clarify engineering choices for the validation mechanism. >=20 > d/ >=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 timothy.dwight@verizon.com Thu Jul 11 13:52:15 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3749F21F9D52 for ; Thu, 11 Jul 2013 13:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 eOJiUhgUxfNW for ; Thu, 11 Jul 2013 13:52:05 -0700 (PDT) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) by ietfa.amsl.com (Postfix) with ESMTP id A988421F9EA3 for ; Thu, 11 Jul 2013 13:52:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by omzsmtpe03.verizonbusiness.com with ESMTP; 11 Jul 2013 20:52:01 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.89,647,1367971200"; d="scan'208";a="506022194" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi02.verizon.com with ESMTP; 11 Jul 2013 20:52:01 +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, 11 Jul 2013 16:52:01 -0400 To: Michael Hammer , "Henning.Schulzrinne@fcc.gov" , "stephen.farrell@cs.tcd.ie" , "Brian.Rosen@neustar.biz" Date: Thu, 11 Jul 2013 16:52:00 -0400 Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIBWXEGbn3ibkCpY0NkPYfuGZlgOFKAgAAEgQCAAANtAIAAAaEAgAAGyYCAAAH7AIAABkaA//+MAvCAABTDgA== Message-ID: <2B0F677F0B95454297753F58D4A07FA3012938CF79@FHDP1LUMXC7V31.us.one.verizon.com> References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <51DEF814.9080704@cs.tcd.ie> <66490626-323F-46DF-8D22-D1677C17FE76@neustar.biz> <51DEFF23.20002@cs.tcd.ie> <2B0F677F0B95454297753F58D4A07FA3012938CE59@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC143E4@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC143E4@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: "rlb@ipv.sx" , "stir@ietf.org" , "housley@vigilsec.com" , "Gonzalo.Camarillo@ericsson.com" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 20:52:18 -0000 The national (significant) part is what you dial any time you're calling a = number in your own country code. Which is for most of us the normal case. = Therefore the national (significant) part is the thing most closely associ= ated with "telephone number". Only if you specify "International" format, = is it clear that you meant for the country code to be included. The car analogy brings back a college course in philosophy, in which I reca= ll spending a session trying to define whether there was some essential not= ion of "chairness" possessed by all chairs. I'll happily refrain from goin= g down that path again :-). tim -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20 Sent: Thursday, July 11, 2013 2:32 PM To: Dwight, Timothy M (Tim); Henning.Schulzrinne@fcc.gov; stephen.farrell@c= s.tcd.ie; Brian.Rosen@neustar.biz Cc: rlb@ipv.sx; stir@ietf.org; housley@vigilsec.com; Gonzalo.Camarillo@eric= sson.com Subject: RE: [stir] Draft STIR Charter Tim, The national specific part is a sub-component of the complete E.164 number. You wouldn't call a car complete if you took the engine out. :) Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dwight, Timothy M (Tim) Sent: Thursday, July 11, 2013 3:23 PM To: Henning Schulzrinne; 'Stephen Farrell'; Rosen, Brian Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter Henning, I think what you describe is what Rec. E.164 calls an International E.164 number. It also discusses National (Significant) Numbers, which are the International E.164 number minus the Country Code. tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Thursday, July 11, 2013 2:00 PM To: 'Stephen Farrell'; Rosen, Brian Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter E.164 implies full phone number. >From E.164, Section 6.2: The international ITU-T E.164-number is composed of a variable number of decimal digits arranged in specific code fields. The international ITU-T E.164-number code fields are the country code (CC) and remaining fields are specific to the use being made of the international ITU-T E.164 number as shown in Figures 1 to 5. A numbering plan does not include prefixes, suffixes, and additional information required to complete a call. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: Thursday, July 11, 2013 2:53 PM To: Rosen, Brian Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter On 07/11/2013 07:29 PM, Rosen, Brian wrote: > So maybe where we say "where the identity being authenticated is a=20 > telephone number" add "in e.164 format"? Better all right. Some people were saying "full e.164" which I guess means including country code and a +, which'd be even better, if its not already implied in e.164. _______________________________________________ stir mailing 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 Thu Jul 11 13:53: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 9E7CC21F9D52 for ; Thu, 11 Jul 2013 13:53:14 -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.095, 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 mkjDbfg7nbBl for ; Thu, 11 Jul 2013 13:53:10 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id AC52A21F9E13 for ; Thu, 11 Jul 2013 13:53: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; Thu, 11 Jul 2013 13:53:05 -0700 From: Michael Hammer To: "Brian.Rosen@neustar.biz" , "jon.peterson@neustar.biz" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIBWXEGbn3ibkCpY0NkPYfuGZlgOFKAgAAEgQCAAANtAIAAAaEAgAAGyYCAAAH7AIAABkaA//+MAvCAAISOAIAAAhCA//+QouA= Date: Thu, 11 Jul 2013 20:53:04 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC145A5@EX2K10MB1.corp.yaanatech.com> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> In-Reply-To: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@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.65] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_030F_01CE7E57.1C24EE80" MIME-Version: 1.0 Cc: "rlb@ipv.sx" , "housley@vigilsec.com" , "Gonzalo.Camarillo@ericsson.com" , "stir@ietf.org" , "Henning.Schulzrinne@fcc.gov" , "timothy.dwight@verizon.com" , "stephen.farrell@cs.tcd.ie" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 20:53:14 -0000 ------=_NextPart_000_030F_01CE7E57.1C24EE80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit It could just note that the WG may consider whether non-E.164 numbers should also be authenticated, and if so, how. BTW, I would not expect the 9-1-1 or 1-1-2 to be sending me calls. After all, the 9-1-1 could be routed to a variety of actual emergency responders. I would expect that a another number might be provided that could be validated. Mike -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Thursday, July 11, 2013 4:30 PM To: Peterson, Jon Cc: Michael Hammer; timothy.dwight@verizon.com; Henning.Schulzrinne@fcc.gov; stephen.farrell@cs.tcd.ie; rlb@ipv.sx; stir@ietf.org; housley@vigilsec.com; Gonzalo.Camarillo@ericsson.com Subject: Re: [stir] Draft STIR Charter Yeah, well, let's talk about that, because you are right. It really would be a good idea to be able to get a call which had a called party number of 9-1-1 or 1-1-2 and was verifiably from that number. We certainly want to be able to handle "toll free" numbers, which in many cases are not actually e.164s, even though they look like them. The problem is that while the latter is usually easy to handle, because even if 18005551212 is not truly an e.164, we certainly could canonicalize them as if they were and everything would work, doing that with 1-1-2 is another story. Probably not worth dealing with these issues in charter language. So, Stephen, unless someone can come up with some wording that works, I'd prefer to defer the discussion to the work group (if/when we get one), rather than do it in charter language. Brian On Jul 11, 2013, at 4:22 PM, "Peterson, Jon" wrote: > > My understanding was that certain nationally-specific numbers, such as > freephone numbers, actually don't fall under the E.164 plan, and that > thus restricting this to "E.164 numbers" may rule out some numbers we > probably want to provide identity for. These numbers have the quality > that they aren't reachable internationally. No? > > Jon Peterson > Neustar, Inc. > > On 7/11/13 12:32 PM, "Michael Hammer" wrote: > >> Tim, >> >> The national specific part is a sub-component of the complete E.164 >> number. >> >> You wouldn't call a car complete if you took the engine out. :) >> >> Mike >> >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Dwight, Timothy M (Tim) >> Sent: Thursday, July 11, 2013 3:23 PM >> To: Henning Schulzrinne; 'Stephen Farrell'; Rosen, Brian >> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >> Subject: Re: [stir] Draft STIR Charter >> >> Henning, >> >> I think what you describe is what Rec. E.164 calls an International >> E.164 number. It also discusses National (Significant) Numbers, >> which are the International E.164 number minus the Country Code. >> >> tim >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Henning Schulzrinne >> Sent: Thursday, July 11, 2013 2:00 PM >> To: 'Stephen Farrell'; Rosen, Brian >> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >> Subject: Re: [stir] Draft STIR Charter >> >> E.164 implies full phone number. >> >> From E.164, Section 6.2: >> >> The international ITU-T E.164-number is composed of a variable number >> of decimal digits arranged in specific code fields. The international >> ITU-T E.164-number code fields are the country code (CC) and >> remaining fields are specific to the use being made of the >> international ITU-T E.164 number as shown in Figures 1 to 5. >> A numbering plan does not include prefixes, suffixes, and additional >> information required to complete a call. >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Stephen Farrell >> Sent: Thursday, July 11, 2013 2:53 PM >> To: Rosen, Brian >> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >> Subject: Re: [stir] Draft STIR Charter >> >> >> >> On 07/11/2013 07:29 PM, Rosen, Brian wrote: >>> So maybe where we say "where the identity being authenticated is a >>> telephone number" add "in e.164 format"? >> >> Better all right. Some people were saying "full e.164" which I guess >> means including country code and a +, which'd be even better, if its >> not already implied in e.164. >> >> _______________________________________________ >> stir mailing 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_030F_01CE7E57.1C24EE80 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx MTIwNTMwM1owIwYJKoZIhvcNAQkEMRYEFAu/DYWaYMT9TPIGZJ7wiav+SNqPMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEASmcjTgaarpl7ILRY/GNtuevk6J+iE1HD/NNCsEkN +r3UhsdVAa5/eBIbxqMn9FfTb0nOxLMhRNXNoH52thqIkKwLb9Y/FGmAPQDbS+XCRQEIV6jLpIh1 CMfZTGMrfGV2f4b6t0gHU+8/6y/p6n5VtagorrMT110nX6jr8f1EBI8orcK/1AzeVZz5OTmBnjDS P4jomWEHFdCATP1H+rBoivGxrANCDr/OcfhaIMdoz9nVf/Fl7tljkIZX3IaQEgqP+6tg3anlJHC1 /jMSUB5W+ZCSOEq2CAxqF28rhaK36m+UCfXQKP3RkSQfGvXr/H+jSHcbNAfEjwOshKSLYFa3UwAA AAAAAA== ------=_NextPart_000_030F_01CE7E57.1C24EE80-- From michael.hammer@yaanatech.com Thu Jul 11 14:02: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 D0F7C21F9BA6 for ; Thu, 11 Jul 2013 14:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 uaiPHPaz9QFj for ; Thu, 11 Jul 2013 14:02:30 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 2E05D11E817B for ; Thu, 11 Jul 2013 14:02: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; Thu, 11 Jul 2013 14:02:20 -0700 From: Michael Hammer To: "timothy.dwight@verizon.com" , "Henning.Schulzrinne@fcc.gov" , "stephen.farrell@cs.tcd.ie" , "Brian.Rosen@neustar.biz" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIBWXEGbn3ibkCpY0NkPYfuGZlgOFKAgAAEgQCAAANtAIAAAaEAgAAGyYCAAAH7AIAABkaA//+MAvCAABTDgIAAA2/A Date: Thu, 11 Jul 2013 21:02:18 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC145DB@EX2K10MB1.corp.yaanatech.com> References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <51DEF814.9080704@cs.tcd.ie> <66490626-323F-46DF-8D22-D1677C17FE76@neustar.biz> <51DEFF23.20002@cs.tcd.ie> <2B0F677F0B95454297753F58D4A07FA3012938CE59@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC143E4@EX2K10MB1.corp.yaanatech.com> <2B0F677F0B95454297753F58D4A07FA3012938CF79@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3012938CF79@FHDP1LUMXC7V31.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.65] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0314_01CE7E58.664D3200" MIME-Version: 1.0 Cc: "rlb@ipv.sx" , "stir@ietf.org" , "housley@vigilsec.com" , "Gonzalo.Camarillo@ericsson.com" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 21:02:35 -0000 ------=_NextPart_000_0314_01CE7E58.664D3200 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am happy with using as many words ad needed to be clear, so no objection to saying "international E.164 number". My concern is that as telephony has evolved we have needed to get less provincial and more global, especially with the Internet and mobility coming into play. We used to think of number within an exchange as sufficient to route, then it became 7-digit dialing, then with area code overlays, you soon needed the full 10 digits. I am just pushing that to the international level, since with mobile internet, it really helps to have the CC as well. It is then unambiguous. Go to an international meeting and ask for their "telephone number " and see what you get. No worries, Mike -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] Sent: Thursday, July 11, 2013 4:52 PM To: Michael Hammer; Henning.Schulzrinne@fcc.gov; stephen.farrell@cs.tcd.ie; Brian.Rosen@neustar.biz Cc: rlb@ipv.sx; stir@ietf.org; housley@vigilsec.com; Gonzalo.Camarillo@ericsson.com Subject: RE: [stir] Draft STIR Charter The national (significant) part is what you dial any time you're calling a number in your own country code. Which is for most of us the normal case. Therefore the national (significant) part is the thing most closely associated with "telephone number". Only if you specify "International" format, is it clear that you meant for the country code to be included. The car analogy brings back a college course in philosophy, in which I recall spending a session trying to define whether there was some essential notion of "chairness" possessed by all chairs. I'll happily refrain from going down that path again :-). tim -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Thursday, July 11, 2013 2:32 PM To: Dwight, Timothy M (Tim); Henning.Schulzrinne@fcc.gov; stephen.farrell@cs.tcd.ie; Brian.Rosen@neustar.biz Cc: rlb@ipv.sx; stir@ietf.org; housley@vigilsec.com; Gonzalo.Camarillo@ericsson.com Subject: RE: [stir] Draft STIR Charter Tim, The national specific part is a sub-component of the complete E.164 number. You wouldn't call a car complete if you took the engine out. :) Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dwight, Timothy M (Tim) Sent: Thursday, July 11, 2013 3:23 PM To: Henning Schulzrinne; 'Stephen Farrell'; Rosen, Brian Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter Henning, I think what you describe is what Rec. E.164 calls an International E.164 number. It also discusses National (Significant) Numbers, which are the International E.164 number minus the Country Code. tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Thursday, July 11, 2013 2:00 PM To: 'Stephen Farrell'; Rosen, Brian Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter E.164 implies full phone number. >From E.164, Section 6.2: The international ITU-T E.164-number is composed of a variable number of decimal digits arranged in specific code fields. The international ITU-T E.164-number code fields are the country code (CC) and remaining fields are specific to the use being made of the international ITU-T E.164 number as shown in Figures 1 to 5. A numbering plan does not include prefixes, suffixes, and additional information required to complete a call. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: Thursday, July 11, 2013 2:53 PM To: Rosen, Brian Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter On 07/11/2013 07:29 PM, Rosen, Brian wrote: > So maybe where we say "where the identity being authenticated is a > telephone number" add "in e.164 format"? Better all right. Some people were saying "full e.164" which I guess means including country code and a +, which'd be even better, if its not already implied in e.164. _______________________________________________ stir mailing 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_0314_01CE7E58.664D3200 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx MTIxMDIxN1owIwYJKoZIhvcNAQkEMRYEFMpdyXx0JMWm9827aX9JkMpZkzL+MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAJyGpW26xFX0bTdTrmyw0iCaMcOqMZw/6tnhx8NOw DtatC4NaWCyTJh5EGw/3uDxHWnn7JbQbI535VLVhHYpwWTWL93/HvVwUxl+Ai8MyaDiSpNI5+48k 20YmEq9/qDs2vU5Dy3vAxzVLdLLNEcf+m1VWBEE3Y1KhpXUiBmqNXQItCAnsUZtAHL0lFKhufi8z uAYjokQN0sw5zbsy7ErYsCxTPiUGsgVRRpYDR+7PzmXssvJlXtQqKCPsOjxsvpHhZQKkCZWwFB+r 6m2tEYd5JRuiFi3zagI7jncQMsISnVWS8KAPzWEnS7R5DvRpa6MtXGWW4HPtk/BALPlhKfva0QAA AAAAAA== ------=_NextPart_000_0314_01CE7E58.664D3200-- From brian.rosen@neustar.biz Thu Jul 11 14:03: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 0CD1211E817F for ; Thu, 11 Jul 2013 14:03:02 -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 JKbHeHmS3RwU for ; Thu, 11 Jul 2013 14:02:58 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id D22B011E8193 for ; Thu, 11 Jul 2013 14:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1373576735; x=1688931323; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=Pl0sA8jmlQ AjYXvwCLk7IEFFGdSiMxcEf7OIUMJ4Apg=; b=GzqXj2vwNt0GOYu2ztdON7tMi5 0RfgUcxI9X5Ee2W0UXxpuV54nvR/eBm4UezbGWYMy4xClUjyL40Z0Y+o+DWg== Received: from ([10.31.58.69]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.26575851; Thu, 11 Jul 2013 17:05:34 -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, 11 Jul 2013 17:02:31 -0400 From: "Rosen, Brian" To: Michael Hammer Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkH7PavsqszcIEumRBC5KQ07J5lgBgeAgAAEgICAAANvAIAAAaEAgAAGyYCAAAH6AIAABkaAgAACpACAAA3sAIAAAhCAgAAGkACAAAKkgA== Date: Thu, 11 Jul 2013 21:02:31 +0000 Message-ID: References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <00C069FD01E0324C9FFCADF539701DB3BBC145A5@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC145A5@EX2K10MB1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.192.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: FYmjsDb5alJfb+OiT/n/5Q== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Peterson, Jon" , "rlb@ipv.sx" , "housley@vigilsec.com" , "Gonzalo.Camarillo@ericsson.com" , "stir@ietf.org" , "Henning.Schulzrinne@fcc.gov" , "timothy.dwight@verizon.com" , "stephen.farrell@cs.tcd.ie" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 21:03:02 -0000 The original text just used "telephone number" and Stephen suggested we may= want to further qualify that. =20 I'm suggesting that we don't want to restrict to e.164s, and it may be that= just sticking with "telephone numbers" is best. It depends on the country, but in the U.S. you very often do get a call bac= k from the Public Safety Answering Point. If the call is from a police off= icer, it may make more sense to use another number. =20 Brian On Jul 11, 2013, at 4:53 PM, Michael Hammer wrote: > It could just note that the WG may consider whether non-E.164 numbers sho= uld > also be authenticated, and if so, how. >=20 > BTW, I would not expect the 9-1-1 or 1-1-2 to be sending me calls. > After all, the 9-1-1 could be routed to a variety of actual emergency > responders. > I would expect that a another number might be provided that could be > validated. >=20 > Mike >=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 > Sent: Thursday, July 11, 2013 4:30 PM > To: Peterson, Jon > Cc: Michael Hammer; timothy.dwight@verizon.com; Henning.Schulzrinne@fcc.g= ov; > stephen.farrell@cs.tcd.ie; rlb@ipv.sx; stir@ietf.org; housley@vigilsec.co= m; > Gonzalo.Camarillo@ericsson.com > Subject: Re: [stir] Draft STIR Charter >=20 > Yeah, well, let's talk about that, because you are right. >=20 > It really would be a good idea to be able to get a call which had a calle= d > party number of 9-1-1 or 1-1-2 and was verifiably from that number. >=20 > We certainly want to be able to handle "toll free" numbers, which in many > cases are not actually e.164s, even though they look like them. >=20 > The problem is that while the latter is usually easy to handle, because e= ven > if 18005551212 is not truly an e.164, we certainly could canonicalize the= m > as if they were and everything would work, doing that with 1-1-2 is anoth= er > story. >=20 > Probably not worth dealing with these issues in charter language. >=20 > So, Stephen, unless someone can come up with some wording that works, I'd > prefer to defer the discussion to the work group (if/when we get one), > rather than do it in charter language. >=20 > Brian >=20 > On Jul 11, 2013, at 4:22 PM, "Peterson, Jon" > wrote: >=20 >>=20 >> My understanding was that certain nationally-specific numbers, such as=20 >> freephone numbers, actually don't fall under the E.164 plan, and that=20 >> thus restricting this to "E.164 numbers" may rule out some numbers we=20 >> probably want to provide identity for. These numbers have the quality=20 >> that they aren't reachable internationally. No? >>=20 >> Jon Peterson >> Neustar, Inc. >>=20 >> On 7/11/13 12:32 PM, "Michael Hammer" > wrote: >>=20 >>> Tim, >>>=20 >>> The national specific part is a sub-component of the complete E.164=20 >>> number. >>>=20 >>> You wouldn't call a car complete if you took the engine out. :) >>>=20 >>> Mike >>>=20 >>>=20 >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >>> Of Dwight, Timothy M (Tim) >>> Sent: Thursday, July 11, 2013 3:23 PM >>> To: Henning Schulzrinne; 'Stephen Farrell'; Rosen, Brian >>> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >>> Subject: Re: [stir] Draft STIR Charter >>>=20 >>> Henning, >>>=20 >>> I think what you describe is what Rec. E.164 calls an International=20 >>> E.164 number. It also discusses National (Significant) Numbers,=20 >>> which are the International E.164 number minus the Country Code. >>>=20 >>> tim >>>=20 >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >>> Of Henning Schulzrinne >>> Sent: Thursday, July 11, 2013 2:00 PM >>> To: 'Stephen Farrell'; Rosen, Brian >>> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >>> Subject: Re: [stir] Draft STIR Charter >>>=20 >>> E.164 implies full phone number. >>>=20 >>> From E.164, Section 6.2: >>>=20 >>> The international ITU-T E.164-number is composed of a variable number=20 >>> of decimal digits arranged in specific code fields. The international=20 >>> ITU-T E.164-number code fields are the country code (CC) and=20 >>> remaining fields are specific to the use being made of the=20 >>> international ITU-T E.164 number as shown in Figures 1 to 5. >>> A numbering plan does not include prefixes, suffixes, and additional=20 >>> information required to complete a call. >>>=20 >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >>> Of Stephen Farrell >>> Sent: Thursday, July 11, 2013 2:53 PM >>> To: Rosen, Brian >>> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >>> Subject: Re: [stir] Draft STIR Charter >>>=20 >>>=20 >>>=20 >>> On 07/11/2013 07:29 PM, Rosen, Brian wrote: >>>> So maybe where we say "where the identity being authenticated is a=20 >>>> telephone number" add "in e.164 format"? >>>=20 >>> Better all right. Some people were saying "full e.164" which I guess=20 >>> means including country code and a +, which'd be even better, if its=20 >>> not already implied in e.164. >>>=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 >=20 From timothy.dwight@verizon.com Thu Jul 11 14:12: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 1568D21F9FF9 for ; Thu, 11 Jul 2013 14:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 76RRT38EOJcC for ; Thu, 11 Jul 2013 14:12:05 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8E81A21F9E67 for ; Thu, 11 Jul 2013 14:11:58 -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; 11 Jul 2013 21:11:56 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.89,647,1367971200"; d="scan'208";a="515366461" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi01.verizon.com with ESMTP; 11 Jul 2013 21:11:56 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Thu, 11 Jul 2013 17:11:56 -0400 To: "Peterson, Jon" , Michael Hammer , "Henning.Schulzrinne@fcc.gov" , "stephen.farrell@cs.tcd.ie" , "Rosen, Brian" Date: Thu, 11 Jul 2013 17:11:54 -0400 Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkICx1fsldqNdEa1H4oCYTQLxplgBgeAgAAEgQCAAANuAIAAAaEAgAAGyYCAAAH6AIAABkaAgAACpAD//5iRAIAAOwng Message-ID: <2B0F677F0B95454297753F58D4A07FA3012938CFA6@FHDP1LUMXC7V31.us.one.verizon.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC143E4@EX2K10MB1.corp.yaanatech.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: "rlb@ipv.sx" , "stir@ietf.org" , "housley@vigilsec.com" , "Gonzalo.Camarillo@ericsson.com" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 21:12:11 -0000 Well, some toll free numbers *are* reachable internationally, and for that = reason *are* considered International E.164 numbers (they're called Univers= al International Freephone Numbers or UIFNs). But that point aside, I thin= k what you're pointing out is that while we want the user part formatted as= an International E.164 number, we don't want to restrict our scope to user= parts for which there is an identical E.164 number. That allows e.g., cou= ntry-specific (or region-specific for that matter) freephone numbers to be = considered in scope. =20 tim -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz]=20 Sent: Thursday, July 11, 2013 3:22 PM To: Michael Hammer; Dwight, Timothy M (Tim); Henning.Schulzrinne@fcc.gov; s= tephen.farrell@cs.tcd.ie; Rosen, Brian Cc: rlb@ipv.sx; stir@ietf.org; housley@vigilsec.com; Gonzalo.Camarillo@eric= sson.com Subject: Re: [stir] Draft STIR Charter My understanding was that certain nationally-specific numbers, such as free= phone numbers, actually don't fall under the E.164 plan, and that thus rest= ricting this to "E.164 numbers" may rule out some numbers we probably want = to provide identity for. These numbers have the quality that they aren't re= achable internationally. No? Jon Peterson Neustar, Inc. On 7/11/13 12:32 PM, "Michael Hammer" wrote: >Tim, > >The national specific part is a sub-component of the complete E.164=20 >number. > >You wouldn't call a car complete if you took the engine out. :) > >Mike > > >-----Original Message----- >From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of=20 >Dwight, Timothy M (Tim) >Sent: Thursday, July 11, 2013 3:23 PM >To: Henning Schulzrinne; 'Stephen Farrell'; Rosen, Brian >Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >Subject: Re: [stir] Draft STIR Charter > >Henning, > >I think what you describe is what Rec. E.164 calls an International=20 >E.164 number. It also discusses National (Significant) Numbers, which=20 >are the International E.164 number minus the Country Code. > >tim > >-----Original Message----- >From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of=20 >Henning Schulzrinne >Sent: Thursday, July 11, 2013 2:00 PM >To: 'Stephen Farrell'; Rosen, Brian >Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >Subject: Re: [stir] Draft STIR Charter > >E.164 implies full phone number. > >From E.164, Section 6.2: > >The international ITU-T E.164-number is composed of a variable number=20 >of decimal digits arranged in specific code fields. The international=20 >ITU-T E.164-number code fields are the country code (CC) and remaining=20 >fields are specific to the use being made of the international ITU-T=20 >E.164 number as shown in Figures 1 to 5. >A numbering plan does not include prefixes, suffixes, and additional=20 >information required to complete a call. > >-----Original Message----- >From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of=20 >Stephen Farrell >Sent: Thursday, July 11, 2013 2:53 PM >To: Rosen, Brian >Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >Subject: Re: [stir] Draft STIR Charter > > > >On 07/11/2013 07:29 PM, Rosen, Brian wrote: >> So maybe where we say "where the identity being authenticated is a=20 >> telephone number" add "in e.164 format"? > >Better all right. Some people were saying "full e.164" which I guess=20 >means including country code and a +, which'd be even better, if its=20 >not already implied in e.164. > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From timothy.dwight@verizon.com Thu Jul 11 14:20: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 36AF021F8B35 for ; Thu, 11 Jul 2013 14:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 TVS-UtkllVmf for ; Thu, 11 Jul 2013 14:20:45 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id 36BC211E8183 for ; Thu, 11 Jul 2013 14:20:40 -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; 11 Jul 2013 21:20:34 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.89,647,1367971200"; d="scan'208";a="506973019" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi03.verizon.com with ESMTP; 11 Jul 2013 21:20:34 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Thu, 11 Jul 2013 17:20:34 -0400 To: "Rosen, Brian" , "Peterson, Jon" Date: Thu, 11 Jul 2013 17:20:32 -0400 Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkH7PavsqszcIEumRBC5KQ07J5lgBgeAgAAEgICAAANvAIAAAaEAgAAGyYCAAAH6AIAABkaAgAACpACAAA3sAIAAAhCA///Ja5A= Message-ID: <2B0F677F0B95454297753F58D4A07FA3012938CFC4@FHDP1LUMXC7V31.us.one.verizon.com> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> In-Reply-To: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@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: "rlb@ipv.sx" , "housley@vigilsec.com" , "Gonzalo.Camarillo@ericsson.com" , "stir@ietf.org" , "Henning.Schulzrinne@fcc.gov" , Michael Hammer , "stephen.farrell@cs.tcd.ie" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 21:20:51 -0000 Wouldn't it need to be the case that the number has a single owner? Otherw= ise, if its ownership depends on where you are when you reference it, it'd = be very hard to validate. For emergency services maybe we could identify a single 'owner' (e.g., NENA= for 9-1-1). But who would "own" the call-before-you-dig number (811)? You're probably right about leaving this to the WG to sort out. Tim -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 Sent: Thursday, July 11, 2013 3:30 PM To: Peterson, Jon Cc: Michael Hammer; Dwight, Timothy M (Tim); Henning.Schulzrinne@fcc.gov; s= tephen.farrell@cs.tcd.ie; rlb@ipv.sx; stir@ietf.org; housley@vigilsec.com; = Gonzalo.Camarillo@ericsson.com Subject: Re: [stir] Draft STIR Charter Yeah, well, let's talk about that, because you are right. It really would be a good idea to be able to get a call which had a called = party number of 9-1-1 or 1-1-2 and was verifiably from that number. We certainly want to be able to handle "toll free" numbers, which in many c= ases are not actually e.164s, even though they look like them. The problem is that while the latter is usually easy to handle, because eve= n if 18005551212 is not truly an e.164, we certainly could canonicalize the= m as if they were and everything would work, doing that with 1-1-2 is anoth= er story. Probably not worth dealing with these issues in charter language. So, Stephen, unless someone can come up with some wording that works, I'd p= refer to defer the discussion to the work group (if/when we get one), rathe= r than do it in charter language. Brian On Jul 11, 2013, at 4:22 PM, "Peterson, Jon" wrote: >=20 > My understanding was that certain nationally-specific numbers, such as=20 > freephone numbers, actually don't fall under the E.164 plan, and that=20 > thus restricting this to "E.164 numbers" may rule out some numbers we=20 > probably want to provide identity for. These numbers have the quality=20 > that they aren't reachable internationally. No? >=20 > Jon Peterson > Neustar, Inc. >=20 > On 7/11/13 12:32 PM, "Michael Hammer" wrot= e: >=20 >> Tim, >>=20 >> The national specific part is a sub-component of the complete E.164=20 >> number. >>=20 >> You wouldn't call a car complete if you took the engine out. :) >>=20 >> Mike >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Dwight, Timothy M (Tim) >> Sent: Thursday, July 11, 2013 3:23 PM >> To: Henning Schulzrinne; 'Stephen Farrell'; Rosen, Brian >> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >> Subject: Re: [stir] Draft STIR Charter >>=20 >> Henning, >>=20 >> I think what you describe is what Rec. E.164 calls an International=20 >> E.164 number. It also discusses National (Significant) Numbers,=20 >> which are the International E.164 number minus the Country Code. >>=20 >> tim >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Henning Schulzrinne >> Sent: Thursday, July 11, 2013 2:00 PM >> To: 'Stephen Farrell'; Rosen, Brian >> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >> Subject: Re: [stir] Draft STIR Charter >>=20 >> E.164 implies full phone number. >>=20 >> From E.164, Section 6.2: >>=20 >> The international ITU-T E.164-number is composed of a variable number=20 >> of decimal digits arranged in specific code fields. The international=20 >> ITU-T E.164-number code fields are the country code (CC) and=20 >> remaining fields are specific to the use being made of the=20 >> international ITU-T E.164 number as shown in Figures 1 to 5. >> A numbering plan does not include prefixes, suffixes, and additional=20 >> information required to complete a call. >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Stephen Farrell >> Sent: Thursday, July 11, 2013 2:53 PM >> To: Rosen, Brian >> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >> Subject: Re: [stir] Draft STIR Charter >>=20 >>=20 >>=20 >> On 07/11/2013 07:29 PM, Rosen, Brian wrote: >>> So maybe where we say "where the identity being authenticated is a=20 >>> telephone number" add "in e.164 format"? >>=20 >> Better all right. Some people were saying "full e.164" which I guess=20 >> means including country code and a +, which'd be even better, if its=20 >> not already implied in e.164. >>=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 richard@shockey.us Thu Jul 11 14:32: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 6957421F9DB8 for ; Thu, 11 Jul 2013 14:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.706 X-Spam-Level: X-Spam-Status: No, score=-101.706 tagged_above=-999 required=5 tests=[AWL=0.559, 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 t3pXNBuj02Un for ; Thu, 11 Jul 2013 14:32:26 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id CAE2A21F9298 for ; Thu, 11 Jul 2013 14:32:25 -0700 (PDT) Received: (qmail 13833 invoked by uid 0); 11 Jul 2013 21:31:59 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy9.bluehost.com with SMTP; 11 Jul 2013 21:31: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=uT9uTyqCZ9oCXW+mmk0iD6lhTY9jsGn/JSu5keAxENQ=; b=gwbQhXSexr6Hwo9ArG/9sxXgrz5sZCvFgW+Svmirc2by8Vfzi78PnqlYu8NRcG41+wwlTdyz3PxglkwI3q7zHbYjJCRicPQFhQrDq+cDHs98C6K474vTiqXEch51ILBp; Received: from [72.66.111.124] (port=54287 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UxOT1-0005et-IQ; Thu, 11 Jul 2013 15:31:59 -0600 From: "Richard Shockey" To: "'Dwight, Timothy M \(Tim\)'" , "'Hadriel Kaplan'" , "'Michael Hammer'" References: , <007201ce799a$34539360$9cfaba20$@shockey.us> <900A1E2059ADB149B905E3C8FA0046A62C77C39220@FHDP1LUMXC7V23.us.one.verizon.com> <01ad01ce7da0$5af26f00$10d74d00$@shockey.us> <52705969-970E-431A-9A9B-B24AAF69C082@oracle.com> <51DE3DDB.2000303@dcrocker.net> <00C069FD01E0324C9FFCADF539701DB3BBC13E48@EX2K10MB1.corp.yaanatech.com> <2B0F677F0B95454297753F58D4A07FA3012938CDEB@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3012938CDEB@FHDP1LUMXC7V31.us.one.verizon.com> Date: Thu, 11 Jul 2013 17:31:56 -0400 Message-ID: <016401ce7e7e$12694130$373bc390$@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: AQHodzCA9LgCAfhuWd/FCK4mTC0xcwHl+TKPAd+zOkYCZJUWewIb/khJAeRXx3cBxiujuQFk6TZcAV2G8OECLT/tIAHXhWlbAerttyqYhvZdIA== 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: dcrocker@bbiw.net, stir@ietf.org, york@isoc.org, "'Mishra, Sanjay'" , Henning.Schulzrinne@fcc.gov Subject: Re: [stir] Using Validated Numbers (was - Re: U.S. Senate hearing on robocalls July 10, 2013) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 21:32:30 -0000 +1 Well said ... -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dwight, Timothy M (Tim) Sent: Thursday, July 11, 2013 2:55 PM To: Hadriel Kaplan; Michael Hammer Cc: stir@ietf.org; Henning.Schulzrinne@fcc.gov; york@isoc.org; Mishra, Sanjay; dcrocker@bbiw.net Subject: Re: [stir] Using Validated Numbers (was - Re: U.S. Senate hearing on robocalls July 10, 2013) Whether the NPAC plays any role seems like a North America -specific, largely-commercial distraction. Certainly I would object to any effort to bias the square peg (solution) so that it fits that particular (need I say North America -specific?) round hole (NPAC). tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Thursday, July 11, 2013 11:47 AM To: Michael Hammer Cc: Mishra, Sanjay; stir@ietf.org; york@isoc.org; dcrocker@bbiw.net; Henning.Schulzrinne@fcc.gov Subject: Re: [stir] Using Validated Numbers (was - Re: U.S. Senate hearing on robocalls July 10, 2013) I think he meant the NPAC. Even if the NPAC held the keys/certs, we'd still want a way to do STIR delegation... because afaict the NPAC in its current form doesn't truly know the ultimate service provider. It appears to only know the regulated "carrier" the number is assigned to, but that's not the ultimate service provider really. There are hundreds of providers who aren't classified as "carriers", and don't want to be for legal/monetary reasons. They pay a real "carrier" to handle the number porting, so the NPAC only has that official carrier in its database instead of the ultimate service provider. That official carrier could be the one to sign the caller-id coming from its customer service providers, but we probably need a way for the real originating service provider to do it instead. -hadriel On Jul 11, 2013, at 10:36 AM, Michael Hammer wrote: > Correct me if I am wrong, but I didn't think the LERG went to 10 digits. > > Mike > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of Henning Schulzrinne > Sent: Thursday, July 11, 2013 10:00 AM > To: 'dcrocker@bbiw.net'; stir@ietf.org > Cc: 'Dan York'; 'Mishra, Sanjay' > Subject: Re: [stir] Using Validated Numbers (was - Re: U.S. Senate > hearing on robocalls July 10, 2013) > > A crucial component will be that > > (1) *all* calls from a certain number are validated > (2) the receiver can know that this is the case ("DANE") > > (2) can be a heuristic, given (1), but obviously explicit information > is better. That way, targets that are particularly susceptible to > individualized spoofing, such as financial institutions, can protect > themselves first, just like they did by implementing TLS early on > their web sites. That would prevent a fair amount of vishing. If we > can then get the large outbound call centers to "incent" their > carriers, most people will then only get three kinds of calls: > (a) validated business calls > (b) known numbers from friends and family > (c) unvalidated calls that are very likely to be robocalls and can, at > least, be sent to voicemail and CAPTCHA > > (2) may not be an Internet-facing directory, although that could be > quite helpful. For example, this information could be contained in the > LERG or other information made available by the numbering administrator. > > -----Original Message----- > From: Dave Crocker [mailto:dhc@dcrocker.net] > Sent: Thursday, July 11, 2013 1:09 AM > To: stir@ietf.org > Cc: 'Dan York'; 'Mishra, Sanjay'; Henning Schulzrinne > Subject: Using Validated Numbers (was - Re: [stir] U.S. Senate hearing > on robocalls July 10, 2013) > > >> Regardless, none of the robocall-blocking tactics I've seen will do >> much in the long run unless we get the caller-id's to at least be >> authenticate-able. Once we know the caller-ids can't be randomly >> generated or spoof legitimate sources, doing whitelist/blacklist >> things will be a lot more tenable. > > > Dumb question, since it seems clear that most folk already have a > sense of the answer: Once there are some telephone numbers getting > validated, how will this get used and by what components in the system? > > I'm asking for more detail that the above text has, so that it's > possible to consider the specifics of what to change and how it will > work, such as during initial years of only partial adoption. > > Over in email-abuse land, a wide range of assumptions were made about > the use of authenticated names, but the actual uses have had some surprises. > > To the extent that there is agreement on the specific uses that are > planned for validated telephone numbers, it can sometimes help to > clarify engineering choices for the validation mechanism. > > 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 From richard@shockey.us Thu Jul 11 14:37: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 13E3111E819A for ; Thu, 11 Jul 2013 14:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.746 X-Spam-Level: X-Spam-Status: No, score=-101.746 tagged_above=-999 required=5 tests=[AWL=0.519, 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 RJmVX+N+DYlt for ; Thu, 11 Jul 2013 14:37:38 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 97B2211E81A0 for ; Thu, 11 Jul 2013 14:37:34 -0700 (PDT) Received: (qmail 31679 invoked by uid 0); 11 Jul 2013 21:37:31 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy14.unifiedlayer.com with SMTP; 11 Jul 2013 21:37:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=uH2JtBfeUuId1rPvz6ksJ+fyCKos7qSH7jIG+9skin4=; b=l2dOqcjIZ548u2985g7yTSiqXyJYmJWmxiWvkw3uc7IXecHHGkpSGCh332FS0h9C1un8J9Sqyswkalkt9Vne+QdE1kbrmZaFD3+IA7AdhzhGhffqM2WAQWkx88JTnosP; Received: from [72.66.111.124] (port=54304 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UxOYN-0001Oq-6V; Thu, 11 Jul 2013 15:37:31 -0600 From: "Richard Shockey" To: , "'Henning Schulzrinne'" References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <51DEF814.9080704@cs.tcd.ie> <66490626-323F-46DF-8D22-D1677C17FE76@neustar.biz> <51DEFF23.20002@cs.tcd.ie> <51DF036A.206@dcrocker.net> In-Reply-To: <51DF036A.206@dcrocker.net> Date: Thu, 11 Jul 2013 17:37:21 -0400 Message-ID: <016501ce7e7e$d813fa10$883bee30$@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: AQJTMBZnYbBxIBWz9bIcVUfweDqGCwLB7tdMAxRzHfMCrGtBjgEnS0QzAaQcpp8Bqadb4wKxzl/PAcybmsoCdgbzDZe3OgVQ 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: 'Richard Barnes' , 'Russ Housley' , 'Gonzalo Camarillo' , stir@ietf.org, "'Rosen, Brian'" , 'Stephen Farrell' Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 21:37:43 -0000 +1 or something like that. The "FQDN" MUST be properly presented to the appropriate network element. The E. 164 'name' and it is an name anywhere LNP exists, should presented in its full canonical form which by common acceptance the + denotes that fact. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dave Crocker Sent: Thursday, July 11, 2013 3:12 PM To: Henning Schulzrinne Cc: Richard Barnes; Russ Housley; Gonzalo Camarillo; ; Rosen, Brian; 'Stephen Farrell' Subject: Re: [stir] Draft STIR Charter On 7/11/2013 12:00 PM, Henning Schulzrinne wrote: > E.164 implies full phone number. > >>From E.164, Section 6.2: > > The international ITU-T E.164-number is composed of a variable number > of decimal digits arranged in specific code fields. The international > ITU-T E.164-number code fields are the country code (CC) and remaining > fields are specific to the use being made of the international ITU-T E.164 number as shown in Figures 1 to 5. > A numbering plan does not include prefixes, suffixes, and additional > information required to complete a call. Sounds like a globally-unique string, on a par with FQDN. It might be worth having the charter note the mapping function that will often be required, to convert a local-form of telephone number in the From field to it's standardized E.164 form. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From richard@shockey.us Thu Jul 11 14:45: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 3402311E812F for ; Thu, 11 Jul 2013 14:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.78 X-Spam-Level: X-Spam-Status: No, score=-101.78 tagged_above=-999 required=5 tests=[AWL=0.485, 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 oLt7D+nYnWUc for ; Thu, 11 Jul 2013 14:45:42 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 6A11411E8129 for ; Thu, 11 Jul 2013 14:45:42 -0700 (PDT) Received: (qmail 31958 invoked by uid 0); 11 Jul 2013 21:45:42 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy14.unifiedlayer.com with SMTP; 11 Jul 2013 21:45:42 -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=DIewGM/EKm5SrzeepRR1j+1dChp+GNhq+3XOgSsBYQ8=; b=OjHTTPHYsb4yVk7KpxbCD/RYSDHv6a3NC6UMBk3/TGRPHq7OItJ5jLKsPYmBGsrL6eCmXA28fkdffLXCsdhhp4yjO2x30JaM+VWR1AIio6Ni+1SYB1Pzt/6B+4OtrO+G; Received: from [72.66.111.124] (port=54347 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UxOgH-0007eN-OO; Thu, 11 Jul 2013 15:45:41 -0600 From: "Richard Shockey" To: "'Michael Hammer'" , , References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <51DEFD44.8090100@dcrocker.net> <00C069FD01E0324C9FFCADF539701DB3BBC14378@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC14378@EX2K10MB1.corp.yaanatech.com> Date: Thu, 11 Jul 2013 17:45:38 -0400 Message-ID: <016601ce7e7f$fc778240$f56686c0$@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: AQJTMBZnYbBxIBWz9bIcVUfweDqGCwLB7tdMAxRzHfMCrGtBjgEnS0QzAbzjJJQDOXTLs5fhmkJw 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: rlb@ipv.sx, stir@ietf.org, housley@vigilsec.com, Gonzalo.Camarillo@ericsson.com, stephen.farrell@cs.tcd.ie Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 21:45:47 -0000 Moore's law solves most problems. I know this specially with the DNS vs SIP redirect discussion carriers have over number translation. The delta is now virtually insignificant. As I mentioned before the way the national regulators and certainly Congressional members feel they would helicopter money or investment tax credits to any carrier willing to implement the solution. But Public Hanging is still an option. :-) The guillotine is certainly an option in Europe. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Thursday, July 11, 2013 3:20 PM To: dcrocker@bbiw.net; Brian.Rosen@neustar.biz Cc: rlb@ipv.sx; stir@ietf.org; housley@vigilsec.com; Gonzalo.Camarillo@ericsson.com; stephen.farrell@cs.tcd.ie Subject: Re: [stir] Draft STIR Charter It is more than just computation. It is the question of call setup time, which is very important for telephony. You don't want to have people hang up and dial again and again because they think the system is not working right. It is a quality of experience measure. We don't want the cure to be worse than the disease. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dave Crocker Sent: Thursday, July 11, 2013 2:45 PM To: Rosen, Brian Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo; Stephen Farrell Subject: Re: [stir] Draft STIR Charter On 7/11/2013 11:11 AM, Rosen, Brian wrote: >> Somewhere this should say that the solution chosen needs to have an >> acceptable overhead at both signer and verifer or else it also won't >> be deployed. There may be some on here who could suggest indicative >> timing or networking constraints (e.g. not having to do ~5 OCSP >> transactions to possibly anywhere in the world) and if so, that'd be >> a good thing to include IMO. > I'll think about how to add some text for this. I think "deployable" > is really, really important in this effort. I assume Stephen means computational overhead. There's also the matter of administrative overhead, which has been a much higher barrier to adoption for DKIM and DMARC. To say "acceptable" invites debate about what it means. If the charter simply says "the design will attend to computational and administrative overhead, and exchange latency", it raises the necessary flags while avoiding concern for criteria in the charter. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From james.f.baskin@verizon.com Thu Jul 11 15:27: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 2798711E81B9 for ; Thu, 11 Jul 2013 15:27:27 -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 pqgwgLQsB4zZ for ; Thu, 11 Jul 2013 15:27:22 -0700 (PDT) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) by ietfa.amsl.com (Postfix) with ESMTP id E3DAC11E8129 for ; Thu, 11 Jul 2013 15:27:21 -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; 11 Jul 2013 22:27:20 +0000 From: "Baskin, James F \(Jim\)" X-IronPort-AV: E=Sophos;i="4.89,647,1367971200"; d="scan'208";a="515406179" Received: from fldp1lumxc7hb05.verizon.com (HELO FLDP1LUMXC7HB05.us.one.verizon.com) ([166.68.75.87]) by fldsmtpi01.verizon.com with ESMTP; 11 Jul 2013 22:27:20 +0000 Received: from fldp1lumxc7v51.us.one.verizon.com ([166.68.45.34]) by FLDP1LUMXC7HB05.us.one.verizon.com ([166.68.75.87]) with mapi; Thu, 11 Jul 2013 18:27:19 -0400 To: Richard Shockey , "stir@ietf.org" Date: Thu, 11 Jul 2013 18:27:18 -0400 Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQJTMBZnYbBxIBWz9bIcVUfweDqGCwLB7tdMAxRzHfMCrGtBjgEnS0QzAaQcpp8Bqadb4wKxzl/PAcybmsoCdgbzDZe3OgVQgAAH4vA= Message-ID: <8578C3F42894E242BA4076BA905AC9B926287456FE@FLDP1LUMXC7V51.us.one.verizon.com> References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <51DEF814.9080704@cs.tcd.ie> <66490626-323F-46DF-8D22-D1677C17FE76@neustar.biz> <51DEFF23.20002@cs.tcd.ie> <51DF036A.206@dcrocker.net> <016501ce7e7e$d813fa10$883bee30$@shockey.us> In-Reply-To: <016501ce7e7e$d813fa10$883bee30$@shockey.us> 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] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 22:27:27 -0000 Regarding the "+", we shouldn't forget this paragraph from E.164 [ANNEX B]: "B.7 Calling/connected line identity Calling/connected line identity (CLI/COLI) is address information that is p= assed across the network to provide supplementary services such as calling = (or connected) line identification presentation. The format of the CLI and = COLI for international calls should be the full international ITU-T E.164-n= umber, i.e., country code (CC), national destination code (NDC) and subscri= ber number (SN). No other information, such as prefixes or symbols (e.g., "= +"), should be included, although a sub-address may be associated with the = CLI/COLI. However, in a country where network-specific numbers are utilized= for identifying customers or network services, it remains a national matte= r. When implemented, the NPI (numbering plan identifier) TON (type of numbe= r) mechanism should define the numbering status of the calling/connected li= ne. The authorization to pass CLI/COLI across an international boundary is = a national matter." SEVERAL very interesting statements are contained in this paragraph. =20 1) the format of the CLI SHOULD be the full international E.164 number. 2) NO prefixes or symbols (e.g., "+") SHOULD be included. 3) various things are NATIONAL matters, including "The authorization to pas= s CLI/COLI across an international boundary." Jim Baskin Verizon -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Ric= hard Shockey Sent: Thursday, July 11, 2013 5:37 PM To: dcrocker@bbiw.net; 'Henning Schulzrinne' Cc: 'Richard Barnes'; 'Russ Housley'; 'Gonzalo Camarillo'; stir@ietf.org; '= Rosen, Brian'; 'Stephen Farrell' Subject: Re: [stir] Draft STIR Charter +1 or something like that.=20 The "FQDN" MUST be properly presented to the appropriate network element. The E. 164 'name' and it is an name anywhere LNP exists, should presented = in its full canonical form which by common acceptance the + denotes th= at fact.=20 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dav= e Crocker Sent: Thursday, July 11, 2013 3:12 PM To: Henning Schulzrinne Cc: Richard Barnes; Russ Housley; Gonzalo Camarillo; ; Rosen= , Brian; 'Stephen Farrell' Subject: Re: [stir] Draft STIR Charter On 7/11/2013 12:00 PM, Henning Schulzrinne wrote: > E.164 implies full phone number. > >>From E.164, Section 6.2: > > The international ITU-T E.164-number is composed of a variable number=20 > of decimal digits arranged in specific code fields. The international=20 > ITU-T E.164-number code fields are the country code (CC) and remaining=20 > fields are specific to the use being made of the international ITU-T=20 > E.164 number as shown in Figures 1 to 5. > A numbering plan does not include prefixes, suffixes, and additional=20 > information required to complete a call. Sounds like a globally-unique string, on a par with FQDN. It might be worth having the charter note the mapping function that will of= ten be required, to convert a local-form of telephone number in the From f= ield to it's standardized E.164 form. 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 richard@shockey.us Thu Jul 11 14:54: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 94FA911E81A0 for ; Thu, 11 Jul 2013 14:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.811 X-Spam-Level: X-Spam-Status: No, score=-101.811 tagged_above=-999 required=5 tests=[AWL=0.454, 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 Dw4D0gmQpDd0 for ; Thu, 11 Jul 2013 14:54:52 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id B965311E8129 for ; Thu, 11 Jul 2013 14:54:52 -0700 (PDT) Received: (qmail 369 invoked by uid 0); 11 Jul 2013 21:54:29 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.bluehost.com with SMTP; 11 Jul 2013 21:54:29 -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=yD/hR4y+AWlJSbJrBhIPMgDXQw2fdCIvrmZn24gISMM=; b=e2NxricyvIkL2dwcwTWmvs46oiubn1U+o/ZlJcncX9sZVmgHshLaV7CqZFr8zN4Httxu+LL51CfnztIfylcCHKJG1g8Aaf4yr1Ds3KtHwEhduhj6YkVoC1ILUBRcEEU/; Received: from [72.66.111.124] (port=54376 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UxOon-0007wJ-EG; Thu, 11 Jul 2013 15:54:29 -0600 From: "Richard Shockey" To: "'Rosen, Brian'" , "'Peterson, Jon'" References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> In-Reply-To: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> Date: Thu, 11 Jul 2013 17:54:25 -0400 Message-ID: <016e01ce7e81$36fdb280$a4f91780$@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: AQMHICSL0Ph6g4RQ+NeWd1GuIq7+jgID3l/wlt6hVpA= 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} X-Mailman-Approved-At: Thu, 11 Jul 2013 17:09:17 -0700 Cc: rlb@ipv.sx, housley@vigilsec.com, Gonzalo.Camarillo@ericsson.com, stir@ietf.org, stephen.farrell@cs.tcd.ie, 'Michael Hammer' , timothy.dwight@verizon.com, Henning.Schulzrinne@fcc.gov Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 21:54:57 -0000 3 digit codes are nationally specific like short codes for mobile operators. Really Brian you know all of this by heart. +1 8XX is in the NANP. Leave it to the NA national regulators to bring out the baseball bat or ... goalie stick for the CRTC and the rest of the NANP to deal with them. However if the EU maybe possibly want to go forward with ETNS that is then their problem. Stop speculating on what the National Regulatory Authorities may or may not do. Our job is tools. NOT policy. But here we are. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Rosen, Brian Sent: Thursday, July 11, 2013 4:30 PM To: Peterson, Jon Cc: rlb@ipv.sx; housley@vigilsec.com; Gonzalo.Camarillo@ericsson.com; stir@ietf.org; Henning.Schulzrinne@fcc.gov; Michael Hammer; timothy.dwight@verizon.com; stephen.farrell@cs.tcd.ie Subject: Re: [stir] Draft STIR Charter Yeah, well, let's talk about that, because you are right. It really would be a good idea to be able to get a call which had a called party number of 9-1-1 or 1-1-2 and was verifiably from that number. We certainly want to be able to handle "toll free" numbers, which in many cases are not actually e.164s, even though they look like them. The problem is that while the latter is usually easy to handle, because even if 18005551212 is not truly an e.164, we certainly could canonicalize them as if they were and everything would work, doing that with 1-1-2 is another story. Probably not worth dealing with these issues in charter language. So, Stephen, unless someone can come up with some wording that works, I'd prefer to defer the discussion to the work group (if/when we get one), rather than do it in charter language. Brian On Jul 11, 2013, at 4:22 PM, "Peterson, Jon" wrote: > > My understanding was that certain nationally-specific numbers, such as > freephone numbers, actually don't fall under the E.164 plan, and that > thus restricting this to "E.164 numbers" may rule out some numbers we > probably want to provide identity for. These numbers have the quality > that they aren't reachable internationally. No? > > Jon Peterson > Neustar, Inc. > > On 7/11/13 12:32 PM, "Michael Hammer" wrote: > >> Tim, >> >> The national specific part is a sub-component of the complete E.164 >> number. >> >> You wouldn't call a car complete if you took the engine out. :) >> >> Mike >> >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Dwight, Timothy M (Tim) >> Sent: Thursday, July 11, 2013 3:23 PM >> To: Henning Schulzrinne; 'Stephen Farrell'; Rosen, Brian >> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >> Subject: Re: [stir] Draft STIR Charter >> >> Henning, >> >> I think what you describe is what Rec. E.164 calls an International >> E.164 number. It also discusses National (Significant) Numbers, >> which are the International E.164 number minus the Country Code. >> >> tim >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Henning Schulzrinne >> Sent: Thursday, July 11, 2013 2:00 PM >> To: 'Stephen Farrell'; Rosen, Brian >> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >> Subject: Re: [stir] Draft STIR Charter >> >> E.164 implies full phone number. >> >> From E.164, Section 6.2: >> >> The international ITU-T E.164-number is composed of a variable number >> of decimal digits arranged in specific code fields. The international >> ITU-T E.164-number code fields are the country code (CC) and >> remaining fields are specific to the use being made of the >> international ITU-T E.164 number as shown in Figures 1 to 5. >> A numbering plan does not include prefixes, suffixes, and additional >> information required to complete a call. >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Stephen Farrell >> Sent: Thursday, July 11, 2013 2:53 PM >> To: Rosen, Brian >> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >> Subject: Re: [stir] Draft STIR Charter >> >> >> >> On 07/11/2013 07:29 PM, Rosen, Brian wrote: >>> So maybe where we say "where the identity being authenticated is a >>> telephone number" add "in e.164 format"? >> >> Better all right. Some people were saying "full e.164" which I guess >> means including country code and a +, which'd be even better, if its >> not already implied in e.164. >> >> _______________________________________________ >> stir mailing 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 Thu Jul 11 17: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 02FB321E8084 for ; Thu, 11 Jul 2013 17:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.297 X-Spam-Level: X-Spam-Status: No, score=-6.297 tagged_above=-999 required=5 tests=[AWL=-0.251, 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 m078fo-DNf9X for ; Thu, 11 Jul 2013 17:07:44 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id B711621E804D for ; Thu, 11 Jul 2013 17:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1373587831; x=1688947524; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=6WK6uMRaKk YQPC/x5BeC1CgoR2bG6SDkzSBIU7oujo8=; b=nvGlrZ4FxYoHia2xjyW2VnPbks Q/pgTmwpoujqvnmn/J7KUsG+VZ0Mpc5uen2Zos4pR9nBBkvyDJDBMGzN0BrA== Received: from ([10.31.58.71]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.26583999; Thu, 11 Jul 2013 20:10:30 -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, 11 Jul 2013 20:07:26 -0400 From: "Rosen, Brian" To: Richard Shockey Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkH7PavsqszcIEumRBC5KQ07J5lgBgeAgAAEgICAAANvAIAAAaEAgAAGyYCAAAH6AIAABkaAgAACpACAAA3sAIAAAhCAgAAXtICAACUpgA== Date: Fri, 12 Jul 2013 00:07:26 +0000 Message-ID: References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <016e01ce7e81$36fdb280$a4f91780$@shockey.us> In-Reply-To: <016e01ce7e81$36fdb280$a4f91780$@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.192.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 0iSDsXfiRI0wBDbsfhgvXw== Content-Type: text/plain; charset="us-ascii" Content-ID: <9D1C2B6A509669489AAA1263F0414379@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 11 Jul 2013 17:09:17 -0700 Cc: "Peterson, Jon" , "" , "" , "" , "" , "" , Michael Hammer , "" , "" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 00:07:48 -0000 I know what the 3 digit codes are. They aren't short codes, they are usual= ly called "service codes". Officially, in the NANP, there is a specific "N1= 1" code set. 1 8XX may be in the NANP, but they are not e.164s. Regardless of what you call them, it may make sense, in some areas, to allo= w them to be used as calling party numbers and be verified as authentic. I think that only has affect on wording in the mechanism discussions. We m= ay need to be careful when we write the text. I don't think it belongs in = the charter. Brian On Jul 11, 2013, at 5:54 PM, Richard Shockey wrote: > 3 digit codes are nationally specific like short codes for mobile operato= rs. > Really Brian you know all of this by heart.=20 >=20 > +1 8XX is in the NANP. Leave it to the NA national regulators to bring o= ut > the baseball bat or ... goalie stick for the CRTC and the rest of the NAN= P > to deal with them. However if the EU maybe possibly want to go forward w= ith > ETNS that is then their problem.=20 >=20 > Stop speculating on what the National Regulatory Authorities may or may n= ot > do. Our job is tools. NOT policy. But here we are.=20 >=20 >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Rosen, Brian > Sent: Thursday, July 11, 2013 4:30 PM > To: Peterson, Jon > Cc: rlb@ipv.sx; housley@vigilsec.com; Gonzalo.Camarillo@ericsson.com; > stir@ietf.org; Henning.Schulzrinne@fcc.gov; Michael Hammer; > timothy.dwight@verizon.com; stephen.farrell@cs.tcd.ie > Subject: Re: [stir] Draft STIR Charter >=20 > Yeah, well, let's talk about that, because you are right. >=20 > It really would be a good idea to be able to get a call which had a calle= d > party number of 9-1-1 or 1-1-2 and was verifiably from that number. >=20 > We certainly want to be able to handle "toll free" numbers, which in many > cases are not actually e.164s, even though they look like them. >=20 > The problem is that while the latter is usually easy to handle, because e= ven > if 18005551212 is not truly an e.164, we certainly could canonicalize the= m > as if they were and everything would work, doing that with 1-1-2 is anoth= er > story. >=20 > Probably not worth dealing with these issues in charter language. >=20 > So, Stephen, unless someone can come up with some wording that works, I'd > prefer to defer the discussion to the work group (if/when we get one), > rather than do it in charter language. >=20 > Brian >=20 > On Jul 11, 2013, at 4:22 PM, "Peterson, Jon" > wrote: >=20 >>=20 >> My understanding was that certain nationally-specific numbers, such as=20 >> freephone numbers, actually don't fall under the E.164 plan, and that=20 >> thus restricting this to "E.164 numbers" may rule out some numbers we=20 >> probably want to provide identity for. These numbers have the quality=20 >> that they aren't reachable internationally. No? >>=20 >> Jon Peterson >> Neustar, Inc. >>=20 >> On 7/11/13 12:32 PM, "Michael Hammer" > wrote: >>=20 >>> Tim, >>>=20 >>> The national specific part is a sub-component of the complete E.164=20 >>> number. >>>=20 >>> You wouldn't call a car complete if you took the engine out. :) >>>=20 >>> Mike >>>=20 >>>=20 >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >>> Of Dwight, Timothy M (Tim) >>> Sent: Thursday, July 11, 2013 3:23 PM >>> To: Henning Schulzrinne; 'Stephen Farrell'; Rosen, Brian >>> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >>> Subject: Re: [stir] Draft STIR Charter >>>=20 >>> Henning, >>>=20 >>> I think what you describe is what Rec. E.164 calls an International=20 >>> E.164 number. It also discusses National (Significant) Numbers,=20 >>> which are the International E.164 number minus the Country Code. >>>=20 >>> tim >>>=20 >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >>> Of Henning Schulzrinne >>> Sent: Thursday, July 11, 2013 2:00 PM >>> To: 'Stephen Farrell'; Rosen, Brian >>> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >>> Subject: Re: [stir] Draft STIR Charter >>>=20 >>> E.164 implies full phone number. >>>=20 >>> From E.164, Section 6.2: >>>=20 >>> The international ITU-T E.164-number is composed of a variable number=20 >>> of decimal digits arranged in specific code fields. The international=20 >>> ITU-T E.164-number code fields are the country code (CC) and=20 >>> remaining fields are specific to the use being made of the=20 >>> international ITU-T E.164 number as shown in Figures 1 to 5. >>> A numbering plan does not include prefixes, suffixes, and additional=20 >>> information required to complete a call. >>>=20 >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >>> Of Stephen Farrell >>> Sent: Thursday, July 11, 2013 2:53 PM >>> To: Rosen, Brian >>> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >>> Subject: Re: [stir] Draft STIR Charter >>>=20 >>>=20 >>>=20 >>> On 07/11/2013 07:29 PM, Rosen, Brian wrote: >>>> So maybe where we say "where the identity being authenticated is a=20 >>>> telephone number" add "in e.164 format"? >>>=20 >>> Better all right. Some people were saying "full e.164" which I guess=20 >>> means including country code and a +, which'd be even better, if its=20 >>> not already implied in e.164. >>>=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 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 From richard@shockey.us Thu Jul 11 17:19:19 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F9421F9B89 for ; Thu, 11 Jul 2013 17:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.837 X-Spam-Level: X-Spam-Status: No, score=-101.837 tagged_above=-999 required=5 tests=[AWL=0.428, 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 6U6lVWnqQ1Ol for ; Thu, 11 Jul 2013 17:19:14 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 66F9311E81D1 for ; Thu, 11 Jul 2013 17:19:11 -0700 (PDT) Received: (qmail 10413 invoked by uid 0); 12 Jul 2013 00:18:48 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.bluehost.com with SMTP; 12 Jul 2013 00:18: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=XiACcg3FuQdIJSSqfrMqUVlqxkDWL+/N2ykutDAr7qA=; b=nGTqwURz1rKS7wypBcBhqTlXgPg7n8PyO8sMGCjsARnbWSG/LpsLfYeMLwvYbcd6MfO4d16EJDd4uJf/WwFHv8E4dLDMF1RJPHBtAM/OAF+xfCOD9h7ctib9wz5ZtJUV; Received: from [72.66.111.124] (port=55145 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UxR4S-0007yY-0F; Thu, 11 Jul 2013 18:18:48 -0600 From: "Richard Shockey" To: "'Baskin, James F \(Jim\)'" , References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <51DEF814.9080704@cs.tcd.ie> <66490626-323F-46DF-8D22-D1677C17FE76@neustar.biz> <51DEFF23.20002@cs.tcd.ie> <51DF036A.206@dcrocker.net> <016501ce7e7e$d813fa10$883bee30$@shockey.us> <8578C3F42894E242BA4076BA905AC9B926287456FE@FLDP1LUMXC7V51.us.one.verizon.com> In-Reply-To: <8578C3F42894E242BA4076BA905AC9B926287456FE@FLDP1LUMXC7V51.us.one.verizon.com> Date: Thu, 11 Jul 2013 20:18:44 -0400 Message-ID: <017601ce7e95$5fe0adb0$1fa20910$@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: AQJTMBZnYbBxIBWz9bIcVUfweDqGCwLB7tdMAxRzHfMCrGtBjgEnS0QzAaQcpp8Bqadb4wKxzl/PAcybmsoCdgbzDQG50THoAQEB0D+XoYxl0A== 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] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 00:19:19 -0000 Jim. Thanks for your expert input here. It is most appreciated. Generally we might be looking at how SIP/IMS IPX??? Signaling in network or between consenting AS operators are the issue. IMHO the representation of the fully canonical E.164 address somewhere in the in band SIP headers using + does make sense operationally. The edge SBC or CSCF network elements could see the + as useful depending on where it is actually expressed. Where the source origin and target is expressed and then how it is signed and by what means in what system is the problem at hand. I'm a great believer that the E.164 is as close to a FQDN as we are going to see. I didn't chair IETF ENUM for as long as I did for no reason. :-) The international issues are TBD. God knows I fear for the day ITU SG 2 grabs a hold of this. Let's fix it here in the IETF and not in Geneva. Best wishes my friend... -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Baskin, James F (Jim) Sent: Thursday, July 11, 2013 6:27 PM To: Richard Shockey; stir@ietf.org Subject: Re: [stir] Draft STIR Charter Regarding the "+", we shouldn't forget this paragraph from E.164 [ANNEX B]: "B.7 Calling/connected line identity Calling/connected line identity (CLI/COLI) is address information that is passed across the network to provide supplementary services such as calling (or connected) line identification presentation. The format of the CLI and COLI for international calls should be the full international ITU-T E.164-number, i.e., country code (CC), national destination code (NDC) and subscriber number (SN). No other information, such as prefixes or symbols (e.g., "+"), should be included, although a sub-address may be associated with the CLI/COLI. However, in a country where network-specific numbers are utilized for identifying customers or network services, it remains a national matter. When implemented, the NPI (numbering plan identifier) TON (type of number) mechanism should define the numbering status of the calling/connected line. The authorization to pass CLI/COLI across an international boundary is a national matter." SEVERAL very interesting statements are contained in this paragraph. 1) the format of the CLI SHOULD be the full international E.164 number. 2) NO prefixes or symbols (e.g., "+") SHOULD be included. 3) various things are NATIONAL matters, including "The authorization to pass CLI/COLI across an international boundary." Jim Baskin Verizon -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Thursday, July 11, 2013 5:37 PM To: dcrocker@bbiw.net; 'Henning Schulzrinne' Cc: 'Richard Barnes'; 'Russ Housley'; 'Gonzalo Camarillo'; stir@ietf.org; 'Rosen, Brian'; 'Stephen Farrell' Subject: Re: [stir] Draft STIR Charter +1 or something like that. The "FQDN" MUST be properly presented to the appropriate network element. The E. 164 'name' and it is an name anywhere LNP exists, should presented in its full canonical form which by common acceptance the + denotes that fact. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dave Crocker Sent: Thursday, July 11, 2013 3:12 PM To: Henning Schulzrinne Cc: Richard Barnes; Russ Housley; Gonzalo Camarillo; ; Rosen, Brian; 'Stephen Farrell' Subject: Re: [stir] Draft STIR Charter On 7/11/2013 12:00 PM, Henning Schulzrinne wrote: > E.164 implies full phone number. > >>From E.164, Section 6.2: > > The international ITU-T E.164-number is composed of a variable number > of decimal digits arranged in specific code fields. The international > ITU-T E.164-number code fields are the country code (CC) and remaining > fields are specific to the use being made of the international ITU-T > E.164 number as shown in Figures 1 to 5. > A numbering plan does not include prefixes, suffixes, and additional > information required to complete a call. Sounds like a globally-unique string, on a par with FQDN. It might be worth having the charter note the mapping function that will often be required, to convert a local-form of telephone number in the From field to it's standardized E.164 form. 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 richard@shockey.us Thu Jul 11 17:47:23 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F38711E8218 for ; Thu, 11 Jul 2013 17:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.861 X-Spam-Level: X-Spam-Status: No, score=-101.861 tagged_above=-999 required=5 tests=[AWL=0.404, 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 cPGxXJhjimyX for ; Thu, 11 Jul 2013 17:47:18 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id F08BC11E81E1 for ; Thu, 11 Jul 2013 17:47:17 -0700 (PDT) Received: (qmail 3576 invoked by uid 0); 12 Jul 2013 00:46:55 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.bluehost.com with SMTP; 12 Jul 2013 00:46: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=6/mvJdVQeYDMM19/0BKgLHpTp3FKk8ijaqwERksy1cc=; b=GZF12iaUIxperf1MYwTpSPFqwGnUOAHRoxOi0WJN6msvm2H4X1jQPPkDF/TM42ResUWHnireuFP5tJIdbz+15f6hdlwb1ntK+Oosd6NW9KYAfZKAgMX1lUp/2fibyqC5; Received: from [72.66.111.124] (port=55227 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UxRVf-0002Zo-FW; Thu, 11 Jul 2013 18:46:55 -0600 From: "Richard Shockey" To: "'Rosen, Brian'" References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <016e01ce7e81$36fdb280$a4f91780$@shockey.us> In-Reply-To: Date: Thu, 11 Jul 2013 20:46:52 -0400 Message-ID: <018001ce7e99$4db0ede0$e912c9a0$@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: AQMHICSL0Ph6g4RQ+NeWd1GuIq7+jgID3l/wAftyPX4An9vNR5bJ9fMQ 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: rlb@ipv.sx, stir@ietf.org Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 00:47:23 -0000 I know what 3 dig codes are and the mobile shorts codes as well. Where did you think I worked for 10 years? What is the status of 8XX is of orthogonal interest to STIR but critical interest since it represents a staggering level of North American enterprise voice traffic and probably a huge level of spoofing as well. To repeat myself for the Nth squared time there is a clear delineation between national numbering policy and the solutions we may come up with. You are correct none of this belongs in the charter. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Rosen, Brian Sent: Thursday, July 11, 2013 8:07 PM To: Richard Shockey Cc: Peterson, Jon; ; ; ; ; ; Michael Hammer; ; Subject: Re: [stir] Draft STIR Charter I know what the 3 digit codes are. They aren't short codes, they are usually called "service codes". Officially, in the NANP, there is a specific "N11" code set. 1 8XX may be in the NANP, but they are not e.164s. Regardless of what you call them, it may make sense, in some areas, to allow them to be used as calling party numbers and be verified as authentic. I think that only has affect on wording in the mechanism discussions. We may need to be careful when we write the text. I don't think it belongs in the charter. Brian On Jul 11, 2013, at 5:54 PM, Richard Shockey wrote: > 3 digit codes are nationally specific like short codes for mobile operators. > Really Brian you know all of this by heart. > > +1 8XX is in the NANP. Leave it to the NA national regulators to > +bring out > the baseball bat or ... goalie stick for the CRTC and the rest of the > NANP to deal with them. However if the EU maybe possibly want to go > forward with ETNS that is then their problem. > > Stop speculating on what the National Regulatory Authorities may or > may not do. Our job is tools. NOT policy. But here we are. > > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of Rosen, Brian > Sent: Thursday, July 11, 2013 4:30 PM > To: Peterson, Jon > Cc: rlb@ipv.sx; housley@vigilsec.com; Gonzalo.Camarillo@ericsson.com; > stir@ietf.org; Henning.Schulzrinne@fcc.gov; Michael Hammer; > timothy.dwight@verizon.com; stephen.farrell@cs.tcd.ie > Subject: Re: [stir] Draft STIR Charter > > Yeah, well, let's talk about that, because you are right. > > It really would be a good idea to be able to get a call which had a > called party number of 9-1-1 or 1-1-2 and was verifiably from that number. > > We certainly want to be able to handle "toll free" numbers, which in > many cases are not actually e.164s, even though they look like them. > > The problem is that while the latter is usually easy to handle, > because even if 18005551212 is not truly an e.164, we certainly could > canonicalize them as if they were and everything would work, doing > that with 1-1-2 is another story. > > Probably not worth dealing with these issues in charter language. > > So, Stephen, unless someone can come up with some wording that works, > I'd prefer to defer the discussion to the work group (if/when we get > one), rather than do it in charter language. > > Brian > > On Jul 11, 2013, at 4:22 PM, "Peterson, Jon" > > wrote: > >> >> My understanding was that certain nationally-specific numbers, such >> as freephone numbers, actually don't fall under the E.164 plan, and >> that thus restricting this to "E.164 numbers" may rule out some >> numbers we probably want to provide identity for. These numbers have >> the quality that they aren't reachable internationally. No? >> >> Jon Peterson >> Neustar, Inc. >> >> On 7/11/13 12:32 PM, "Michael Hammer" > wrote: >> >>> Tim, >>> >>> The national specific part is a sub-component of the complete E.164 >>> number. >>> >>> You wouldn't call a car complete if you took the engine out. :) >>> >>> Mike >>> >>> >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >>> Of Dwight, Timothy M (Tim) >>> Sent: Thursday, July 11, 2013 3:23 PM >>> To: Henning Schulzrinne; 'Stephen Farrell'; Rosen, Brian >>> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >>> Subject: Re: [stir] Draft STIR Charter >>> >>> Henning, >>> >>> I think what you describe is what Rec. E.164 calls an International >>> E.164 number. It also discusses National (Significant) Numbers, >>> which are the International E.164 number minus the Country Code. >>> >>> tim >>> >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >>> Of Henning Schulzrinne >>> Sent: Thursday, July 11, 2013 2:00 PM >>> To: 'Stephen Farrell'; Rosen, Brian >>> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >>> Subject: Re: [stir] Draft STIR Charter >>> >>> E.164 implies full phone number. >>> >>> From E.164, Section 6.2: >>> >>> The international ITU-T E.164-number is composed of a variable >>> number of decimal digits arranged in specific code fields. The >>> international ITU-T E.164-number code fields are the country code >>> (CC) and remaining fields are specific to the use being made of the >>> international ITU-T E.164 number as shown in Figures 1 to 5. >>> A numbering plan does not include prefixes, suffixes, and additional >>> information required to complete a call. >>> >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >>> Of Stephen Farrell >>> Sent: Thursday, July 11, 2013 2:53 PM >>> To: Rosen, Brian >>> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >>> Subject: Re: [stir] Draft STIR Charter >>> >>> >>> >>> On 07/11/2013 07:29 PM, Rosen, Brian wrote: >>>> So maybe where we say "where the identity being authenticated is a >>>> telephone number" add "in e.164 format"? >>> >>> Better all right. Some people were saying "full e.164" which I guess >>> means including country code and a +, which'd be even better, if its >>> not already implied in e.164. >>> >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >> > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From michael.hammer@yaanatech.com Thu Jul 11 17:54:35 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1E211E8244 for ; Thu, 11 Jul 2013 17:54:35 -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 LJFFRr+klFH4 for ; Thu, 11 Jul 2013 17:54:31 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 8397711E8246 for ; Thu, 11 Jul 2013 17:54:26 -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, 11 Jul 2013 17:54:26 -0700 From: Michael Hammer To: "richard@shockey.us" , "dcrocker@bbiw.net" , "Brian.Rosen@neustar.biz" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIBWXEGbn3ibkCpY0NkPYfuGZlgOFKAgAAEgQCAAAmcAP//k9fwgACehQD//77JQA== Date: Fri, 12 Jul 2013 00:54:25 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC1481C@EX2K10MB1.corp.yaanatech.com> References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <51DEFD44.8090100@dcrocker.net> <00C069FD01E0324C9FFCADF539701DB3BBC14378@EX2K10MB1.corp.yaanatech.com> <016601ce7e7f$fc778240$f56686c0$@shockey.us> In-Reply-To: <016601ce7e7f$fc778240$f56686c0$@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.65] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0382_01CE7E78.D325FAE0" MIME-Version: 1.0 Cc: "rlb@ipv.sx" , "stir@ietf.org" , "housley@vigilsec.com" , "Gonzalo.Camarillo@ericsson.com" , "stephen.farrell@cs.tcd.ie" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 00:54:36 -0000 ------=_NextPart_000_0382_01CE7E78.D325FAE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Don't be silly. Since when did Moore's Law conquer the speed of light? As some programmers have found out with chatty RESTful protocols, there is an RTT penalty for badly designed solutions. And yes, I did see you equivocate with "most", but I couldn't resist. :) Mike -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us] Sent: Thursday, July 11, 2013 5:46 PM To: Michael Hammer; dcrocker@bbiw.net; Brian.Rosen@neustar.biz Cc: rlb@ipv.sx; stir@ietf.org; housley@vigilsec.com; Gonzalo.Camarillo@ericsson.com; stephen.farrell@cs.tcd.ie Subject: RE: [stir] Draft STIR Charter Moore's law solves most problems. I know this specially with the DNS vs SIP redirect discussion carriers have over number translation. The delta is now virtually insignificant. As I mentioned before the way the national regulators and certainly Congressional members feel they would helicopter money or investment tax credits to any carrier willing to implement the solution. But Public Hanging is still an option. :-) The guillotine is certainly an option in Europe. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Thursday, July 11, 2013 3:20 PM To: dcrocker@bbiw.net; Brian.Rosen@neustar.biz Cc: rlb@ipv.sx; stir@ietf.org; housley@vigilsec.com; Gonzalo.Camarillo@ericsson.com; stephen.farrell@cs.tcd.ie Subject: Re: [stir] Draft STIR Charter It is more than just computation. It is the question of call setup time, which is very important for telephony. You don't want to have people hang up and dial again and again because they think the system is not working right. It is a quality of experience measure. We don't want the cure to be worse than the disease. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dave Crocker Sent: Thursday, July 11, 2013 2:45 PM To: Rosen, Brian Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo; Stephen Farrell Subject: Re: [stir] Draft STIR Charter On 7/11/2013 11:11 AM, Rosen, Brian wrote: >> Somewhere this should say that the solution chosen needs to have an >> acceptable overhead at both signer and verifer or else it also won't >> be deployed. There may be some on here who could suggest indicative >> timing or networking constraints (e.g. not having to do ~5 OCSP >> transactions to possibly anywhere in the world) and if so, that'd be >> a good thing to include IMO. > I'll think about how to add some text for this. I think "deployable" > is really, really important in this effort. I assume Stephen means computational overhead. There's also the matter of administrative overhead, which has been a much higher barrier to adoption for DKIM and DMARC. To say "acceptable" invites debate about what it means. If the charter simply says "the design will attend to computational and administrative overhead, and exchange latency", it raises the necessary flags while avoiding concern for criteria in the charter. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_0382_01CE7E78.D325FAE0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx MjAwNTQyNFowIwYJKoZIhvcNAQkEMRYEFPVSKAEwmZMWXeDJ71ShbiCRsyP8MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAfzLy39kDqKtgLeeTa55XRRr6jNaOnpESIpYRGq/O hgtmH6tHPmBKVENMz+c+A6WbRexLTPn0VyRhjPWj9SvWv9jai/GTtA7mN/11sQnhlXOIziVSQLHT krk6uWBj6bIq5rxSkSuq8CsCWti3r+FQSpwo8m0p+TBMPfDyZ3QCTxGQ5ewYJEd1w1AcVo1qEZE8 Yy3dbR+0BGNBEr+hsPTTu/rLD5CewNIGZtYIE+3eIrU2/7S3EfY2BzgL4TSSRupmQubn/BSSyQ7s r6wA53568DOM2PzhzLdFvggz8DWy+jA/bC5RCkgMw9hpBW2UGWlvsRicp5It0wWQonLUAVT4kQAA AAAAAA== ------=_NextPart_000_0382_01CE7E78.D325FAE0-- From michael.hammer@yaanatech.com Thu Jul 11 17: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 EA5B411E8135 for ; Thu, 11 Jul 2013 17:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 rO-rrr7kr8nE for ; Thu, 11 Jul 2013 17:58:50 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 0805211E80D7 for ; Thu, 11 Jul 2013 17:58:50 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Thu, 11 Jul 2013 17:58:50 -0700 From: Michael Hammer To: "james.f.baskin@verizon.com" , "richard@shockey.us" , "stir@ietf.org" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIBWXEGbn3ibkCpY0NkPYfuGZlgOFKAgAAEgQCAAANtAIAAAaEAgAAGyYCAAAH7AIAAAx8AgAAotoCAAA31AP//tEzQ Date: Fri, 12 Jul 2013 00:58:48 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC1483D@EX2K10MB1.corp.yaanatech.com> References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <51DEF814.9080704@cs.tcd.ie> <66490626-323F-46DF-8D22-D1677C17FE76@neustar.biz> <51DEFF23.20002@cs.tcd.ie> <51DF036A.206@dcrocker.net> <016501ce7e7e$d813fa10$883bee30$@shockey.us> <8578C3F42894E242BA4076BA905AC9B926287456FE@FLDP1LUMXC7V51.us.one.verizon.com> In-Reply-To: <8578C3F42894E242BA4076BA905AC9B926287456FE@FLDP1LUMXC7V51.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.65] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0387_01CE7E79.705DC860" MIME-Version: 1.0 Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 00:58:54 -0000 ------=_NextPart_000_0387_01CE7E79.705DC860 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Jim, I also assume it is a national matter whether to accept calls across international boundary with or without CLI/COLI. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Baskin, James F (Jim) Sent: Thursday, July 11, 2013 6:27 PM To: Richard Shockey; stir@ietf.org Subject: Re: [stir] Draft STIR Charter Regarding the "+", we shouldn't forget this paragraph from E.164 [ANNEX B]: "B.7 Calling/connected line identity Calling/connected line identity (CLI/COLI) is address information that is passed across the network to provide supplementary services such as calling (or connected) line identification presentation. The format of the CLI and COLI for international calls should be the full international ITU-T E.164-number, i.e., country code (CC), national destination code (NDC) and subscriber number (SN). No other information, such as prefixes or symbols (e.g., "+"), should be included, although a sub-address may be associated with the CLI/COLI. However, in a country where network-specific numbers are utilized for identifying customers or network services, it remains a national matter. When implemented, the NPI (numbering plan identifier) TON (type of number) mechanism should define the numbering status of the calling/connected line. The authorization to pass CLI/COLI across an international boundary is a national matter." SEVERAL very interesting statements are contained in this paragraph. 1) the format of the CLI SHOULD be the full international E.164 number. 2) NO prefixes or symbols (e.g., "+") SHOULD be included. 3) various things are NATIONAL matters, including "The authorization to pass CLI/COLI across an international boundary." Jim Baskin Verizon -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Thursday, July 11, 2013 5:37 PM To: dcrocker@bbiw.net; 'Henning Schulzrinne' Cc: 'Richard Barnes'; 'Russ Housley'; 'Gonzalo Camarillo'; stir@ietf.org; 'Rosen, Brian'; 'Stephen Farrell' Subject: Re: [stir] Draft STIR Charter +1 or something like that. The "FQDN" MUST be properly presented to the appropriate network element. The E. 164 'name' and it is an name anywhere LNP exists, should presented in its full canonical form which by common acceptance the + denotes that fact. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dave Crocker Sent: Thursday, July 11, 2013 3:12 PM To: Henning Schulzrinne Cc: Richard Barnes; Russ Housley; Gonzalo Camarillo; ; Rosen, Brian; 'Stephen Farrell' Subject: Re: [stir] Draft STIR Charter On 7/11/2013 12:00 PM, Henning Schulzrinne wrote: > E.164 implies full phone number. > >>From E.164, Section 6.2: > > The international ITU-T E.164-number is composed of a variable number > of decimal digits arranged in specific code fields. The international > ITU-T E.164-number code fields are the country code (CC) and remaining > fields are specific to the use being made of the international ITU-T > E.164 number as shown in Figures 1 to 5. > A numbering plan does not include prefixes, suffixes, and additional > information required to complete a call. Sounds like a globally-unique string, on a par with FQDN. It might be worth having the charter note the mapping function that will often be required, to convert a local-form of telephone number in the From field to it's standardized E.164 form. 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_0387_01CE7E79.705DC860 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx MjAwNTg0OFowIwYJKoZIhvcNAQkEMRYEFAM7qWRR/8dSV45WiTfixKZBVPm/MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAfZ1hQ8Wuyp6WtgHLtnTI7tjQUetUpiA5Iaqew5u+ T3nZIqA0Mk1RlHX0AybL4PGSYRJLwIshawgyAAc2KuQ3Z3EBMNMvCEk6SCwjvWyXJlhqqQ2PYSfR YlIn6VaASOMUU1LIQZi4vKBg8O+ZR2RSAIOoNbLDCzGwL0xJq4ekMufrdCMJstRRLcX7KOEWf4lf 7VXosygXzD3jHdVwvXwELm/P5+It7zxMEzVyQ+X37zdXpX4AREGQOrGapsmDAT5Xdk25GxSnRWd/ 8gOtATzkquTxFF7Bi58rNiMoVcZHbYG2LDWmC20wrxsry+Fq8k+7JQDgwJ2tz/625Vzq29lIaAAA AAAAAA== ------=_NextPart_000_0387_01CE7E79.705DC860-- From md3135@att.com Thu Jul 11 18:05: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 BAA8311E826A for ; Thu, 11 Jul 2013 18:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.421 X-Spam-Level: X-Spam-Status: No, score=-5.421 tagged_above=-999 required=5 tests=[AWL=1.179, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuR1urIDdQ49 for ; Thu, 11 Jul 2013 18:05: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 DEBF811E826E for ; Thu, 11 Jul 2013 18:05:39 -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 3665fd15.0.4742059.00-480.13182632.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 12 Jul 2013 01:05:40 +0000 (UTC) X-MXL-Hash: 51df56644db9f602-dd89673e0269ac20a7ad1854f1a79cc09e018c05 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 r6C15dn2014913; Thu, 11 Jul 2013 21:05: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 r6C15Yfk014858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jul 2013 21:05:36 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 12 Jul 2013 01:05:22 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, 11 Jul 2013 21:05:47 -0400 From: "DOLLY, MARTIN C" To: Michael Hammer , "james.f.baskin@verizon.com" , "richard@shockey.us" , "stir@ietf.org" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIBF49pdfh4OE+hrHXvRgYKJ5lgOFKAgAAEgQCAAANtAIAAAaEAgAAGyYCAAAH7AIAAAx8AgAAotoCAAA31AP//tEzQgAACjrA= Date: Fri, 12 Jul 2013 01:05:47 +0000 Message-ID: References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <51DEF814.9080704@cs.tcd.ie> <66490626-323F-46DF-8D22-D1677C17FE76@neustar.biz> <51DEFF23.20002@cs.tcd.ie> <51DF036A.206@dcrocker.net> <016501ce7e7e$d813fa10$883bee30$@shockey.us> <8578C3F42894E242BA4076BA905AC9B926287456FE@FLDP1LUMXC7V51.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC1483D@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC1483D@EX2K10MB1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.83.218] 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=Hb+juF48 c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=C8OkCH11DYkA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=egEOtIQ-O] X-AnalysisOut: [6YA:10 a=48vgC7mUAAAA:8 a=ZsyXEVtvAAAA:8 a=k7Ga1wGzAAAA:8 ] X-AnalysisOut: [a=asxmXL5Cr6MGI3A2UQ8A:9 a=CjuIK1q_8ugA:10 a=x3I_HB9Tk8MA:] X-AnalysisOut: [10 a=lZB815dzVvQA:10 a=TRFw3Wk1wdAA:10 a=vRAbILRZcFsA:10 a] X-AnalysisOut: [=fcAx7uNQz4EA:10 a=BiPgG6CY_29VurwJ:21 a=dSIWd7fgXWcGAIEx:] X-AnalysisOut: [21] Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 01:05:45 -0000 Business agreement -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Mic= hael Hammer Sent: Thursday, July 11, 2013 8:59 PM To: james.f.baskin@verizon.com; richard@shockey.us; stir@ietf.org Subject: Re: [stir] Draft STIR Charter Hi Jim, I also assume it is a national matter whether to accept calls across international boundary with or without CLI/COLI. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Baskin, James F (Jim) Sent: Thursday, July 11, 2013 6:27 PM To: Richard Shockey; stir@ietf.org Subject: Re: [stir] Draft STIR Charter Regarding the "+", we shouldn't forget this paragraph from E.164 [ANNEX B]: "B.7 Calling/connected line identity Calling/connected line identity (CLI/COLI) is address information that is passed across the network to provide supplementary services such as calling (or connected) line identification presentation. The format of the CLI and COLI for international calls should be the full international ITU-T E.164-number, i.e., country code (CC), national destination code (NDC) and subscriber number (SN). No other information, such as prefixes or symbols (e.g., "+"), should be included, although a sub-address may be associated with the CLI/COLI. However, in a country where network-specific numbers are utilized for identifying customers or network services, it remains a national matter. When implemented, the NPI (numbering plan identifier) TON (type of number) mechanism should define the numbering status of the calling/connected line. The authorization to pass CLI/COLI across an international boundary is a national matter." SEVERAL very interesting statements are contained in this paragraph. =20 1) the format of the CLI SHOULD be the full international E.164 number. 2) NO prefixes or symbols (e.g., "+") SHOULD be included. 3) various things are NATIONAL matters, including "The authorization to pas= s CLI/COLI across an international boundary." Jim Baskin Verizon -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Thursday, July 11, 2013 5:37 PM To: dcrocker@bbiw.net; 'Henning Schulzrinne' Cc: 'Richard Barnes'; 'Russ Housley'; 'Gonzalo Camarillo'; stir@ietf.org; 'Rosen, Brian'; 'Stephen Farrell' Subject: Re: [stir] Draft STIR Charter +1 or something like that.=20 The "FQDN" MUST be properly presented to the appropriate network element. The E. 164 'name' and it is an name anywhere LNP exists, should presented in its full canonical form which by common acceptance the + denotes that fact.=20 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dav= e Crocker Sent: Thursday, July 11, 2013 3:12 PM To: Henning Schulzrinne Cc: Richard Barnes; Russ Housley; Gonzalo Camarillo; ; Rosen= , Brian; 'Stephen Farrell' Subject: Re: [stir] Draft STIR Charter On 7/11/2013 12:00 PM, Henning Schulzrinne wrote: > E.164 implies full phone number. > >>From E.164, Section 6.2: > > The international ITU-T E.164-number is composed of a variable number=20 > of decimal digits arranged in specific code fields. The international=20 > ITU-T E.164-number code fields are the country code (CC) and remaining=20 > fields are specific to the use being made of the international ITU-T > E.164 number as shown in Figures 1 to 5. > A numbering plan does not include prefixes, suffixes, and additional=20 > information required to complete a call. Sounds like a globally-unique string, on a par with FQDN. It might be worth having the charter note the mapping function that will often be required, to convert a local-form of telephone number in the From field to it's standardized E.164 form. 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 dhc@dcrocker.net Thu Jul 11 18:59: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 26D9421E8084 for ; Thu, 11 Jul 2013 18:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGjizdq7v2ra for ; Thu, 11 Jul 2013 18:59:40 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3C86421E8063 for ; Thu, 11 Jul 2013 18:59: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 r6C1xQkn023409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Jul 2013 18:59:29 -0700 Message-ID: <51DF62E3.8000703@dcrocker.net> Date: Thu, 11 Jul 2013 18:58:59 -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: Richard Shockey References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <51DEFD44.8090100@dcrocker.net> <00C069FD01E0324C9FFCADF539701DB3BBC14378@EX2K10MB1.corp.yaanatech.com> <016601ce7e7f$fc778240$f56686c0$@shockey.us> In-Reply-To: <016601ce7e7f$fc778240$f56686c0$@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, 11 Jul 2013 18:59:32 -0700 (PDT) Cc: rlb@ipv.sx, housley@vigilsec.com, Gonzalo.Camarillo@ericsson.com, stir@ietf.org, Brian.Rosen@neustar.biz, 'Michael Hammer' , stephen.farrell@cs.tcd.ie Subject: Re: [stir] Draft STIR 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: Fri, 12 Jul 2013 01:59:45 -0000 On 7/11/2013 2:45 PM, Richard Shockey wrote: > Moore's law solves most problems. Not in networking. This has already been noted, but I thought reducing to a pithy retort could aid folks' memories as the group goes forward. Moore seems to have solved the computational overhead problem some years ago, and never will solve transmission latency problems. By the way, it also does not solve timezone differences. (That's not an issue for this wg, but I thought I'd toss it in for free.O d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hadriel.kaplan@oracle.com Thu Jul 11 19:23: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 A944111E80D1 for ; Thu, 11 Jul 2013 19:23:30 -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 Klord5D2k+Re for ; Thu, 11 Jul 2013 19:23:25 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 83C0321F9A2E for ; Thu, 11 Jul 2013 19:23:24 -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 r6C2NHbm014483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 12 Jul 2013 02:23:18 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 r6C2NFQ9024850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jul 2013 02:23:16 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 r6C2NFYm005004; Fri, 12 Jul 2013 02:23:15 GMT Received: from [192.168.2.80] (/184.74.74.115) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Jul 2013 19:23: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: <2B0F677F0B95454297753F58D4A07FA3012938CDEB@FHDP1LUMXC7V31.us.one.verizon.com> Date: Thu, 11 Jul 2013 22:23:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <007201ce799a$34539360$9cfaba20$@shockey.us> <900A1E2059ADB149B905E3C8FA0046A62C77C39220@FHDP1LUMXC7V23.us.one.verizon.com> <01ad01ce7da0$5af26f00$10d74d00$@shockey.us> <52705969-970E-431A-9A9B-B24AAF69C082@oracle.com> <51DE3DDB.2000303@dcrocker.net> <00C069FD01E0324C9FFCADF539701DB3BBC13E48@EX2K10MB1.corp.yaanatech.com> <2B0F677F0B95454297753F58D4A07FA3012938CDEB@FHDP1LUMXC7V31.us.one.verizon.com> To: "Dwight, Timothy M \(Tim\)" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "york@isoc.org" , "Mishra, Sanjay" , "stir@ietf.org" , "dcrocker@bbiw.net" , Michael Hammer , "Henning.Schulzrinne@fcc.gov" Subject: Re: [stir] Using Validated Numbers (was - Re: U.S. Senate hearing on robocalls July 10, 2013) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 02:23:30 -0000 On Jul 11, 2013, at 2:54 PM, "Dwight, Timothy M \(Tim\)" = wrote: > Whether the NPAC plays any role seems like a North America -specific, = largely-commercial distraction. Certainly I would object to any effort = to bias the square peg (solution) so that it fits that particular (need = I say North America -specific?) round hole (NPAC). =20 > tim Yup, I was just expanding on Henning's example which indicated the LERG, = and Michael pointed out the LERG doesn't identify the end numbers. -hadriel >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Hadriel Kaplan > Sent: Thursday, July 11, 2013 11:47 AM > To: Michael Hammer > Cc: Mishra, Sanjay; stir@ietf.org; york@isoc.org; dcrocker@bbiw.net; = Henning.Schulzrinne@fcc.gov > Subject: Re: [stir] Using Validated Numbers (was - Re: U.S. Senate = hearing on robocalls July 10, 2013) >=20 >=20 > I think he meant the NPAC. >=20 > Even if the NPAC held the keys/certs, we'd still want a way to do STIR = delegation... because afaict the NPAC in its current form doesn't truly = know the ultimate service provider. It appears to only know the = regulated "carrier" the number is assigned to, but that's not the = ultimate service provider really. There are hundreds of providers who = aren't classified as "carriers", and don't want to be for legal/monetary = reasons. They pay a real "carrier" to handle the number porting, so the = NPAC only has that official carrier in its database instead of the = ultimate service provider. That official carrier could be the one to = sign the caller-id coming from its customer service providers, but we = probably need a way for the real originating service provider to do it = instead. >=20 > -hadriel >=20 >=20 > On Jul 11, 2013, at 10:36 AM, Michael Hammer = wrote: >=20 >> Correct me if I am wrong, but I didn't think the LERG went to 10 = digits. >>=20 >> Mike >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20= >> Of Henning Schulzrinne >> Sent: Thursday, July 11, 2013 10:00 AM >> To: 'dcrocker@bbiw.net'; stir@ietf.org >> Cc: 'Dan York'; 'Mishra, Sanjay' >> Subject: Re: [stir] Using Validated Numbers (was - Re: U.S. Senate=20 >> hearing on robocalls July 10, 2013) >>=20 >> A crucial component will be that >>=20 >> (1) *all* calls from a certain number are validated >> (2) the receiver can know that this is the case ("DANE") >>=20 >> (2) can be a heuristic, given (1), but obviously explicit information=20= >> is better. That way, targets that are particularly susceptible to=20 >> individualized spoofing, such as financial institutions, can protect=20= >> themselves first, just like they did by implementing TLS early on=20 >> their web sites. That would prevent a fair amount of vishing. If we=20= >> can then get the large outbound call centers to "incent" their=20 >> carriers, most people will then only get three kinds of calls: >> (a) validated business calls >> (b) known numbers from friends and family >> (c) unvalidated calls that are very likely to be robocalls and can, = at=20 >> least, be sent to voicemail and CAPTCHA >>=20 >> (2) may not be an Internet-facing directory, although that could be=20= >> quite helpful. For example, this information could be contained in = the=20 >> LERG or other information made available by the numbering = administrator. >>=20 >> -----Original Message----- >> From: Dave Crocker [mailto:dhc@dcrocker.net] >> Sent: Thursday, July 11, 2013 1:09 AM >> To: stir@ietf.org >> Cc: 'Dan York'; 'Mishra, Sanjay'; Henning Schulzrinne >> Subject: Using Validated Numbers (was - Re: [stir] U.S. Senate = hearing=20 >> on robocalls July 10, 2013) >>=20 >>=20 >>> Regardless, none of the robocall-blocking tactics I've seen will do=20= >>> much in the long run unless we get the caller-id's to at least be=20 >>> authenticate-able. Once we know the caller-ids can't be randomly=20 >>> generated or spoof legitimate sources, doing whitelist/blacklist=20 >>> things will be a lot more tenable. >>=20 >>=20 >> Dumb question, since it seems clear that most folk already have a=20 >> sense of the answer: Once there are some telephone numbers getting=20= >> validated, how will this get used and by what components in the = system? >>=20 >> I'm asking for more detail that the above text has, so that it's=20 >> possible to consider the specifics of what to change and how it will=20= >> work, such as during initial years of only partial adoption. >>=20 >> Over in email-abuse land, a wide range of assumptions were made about=20= >> the use of authenticated names, but the actual uses have had some = surprises. >>=20 >> To the extent that there is agreement on the specific uses that are=20= >> planned for validated telephone numbers, it can sometimes help to=20 >> clarify engineering choices for the validation mechanism. >>=20 >> d/ >>=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 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Thu Jul 11 19:38:12 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7748411E80E3 for ; Thu, 11 Jul 2013 19:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMnhSZ7UXLkL for ; Thu, 11 Jul 2013 19:38:07 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 020D911E80A5 for ; Thu, 11 Jul 2013 19:38: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 r6C2c2p6013566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 12 Jul 2013 02:38:03 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 r6C2c0rC024888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jul 2013 02:38:01 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 r6C2c0Eo023150; Fri, 12 Jul 2013 02:38:00 GMT Received: from [192.168.2.80] (/184.74.74.115) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Jul 2013 19:38: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: Thu, 11 Jul 2013 22:37:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> To: Russ Housley X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: Richard Barnes , stir@ietf.org, Gonzalo Camarillo , Brian Rosen Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 02:38:12 -0000 On Jul 11, 2013, at 10:21 AM, Russ Housley wrote: > Initially, the working group will specify an in-band mechanism to = authenticate the originator of a SIP session where the identity being = authenticated is a telephone number and the session is established with = SIP end to end. The working group will consider choices for protecting = the identity information and the credentials used, but will likely be = similar to the methods described in RFC 4474, which employs a signature = over a set of information in the SIP headers using a credential assigned = to the identity. In order to be authoritative, credentials used with = this mechanism will be derived from existing telephone number assignment = and delegation models. That is, when a telephone number or range of = telephone numbers is delegated to an entity, a credential will accompany = such delegation. =20 This is a bit of a nitpick, but the solution does not have to accompany = a delegation with credentials. It could, for example, instead accompany = a delegation with access rights to the same or another database to = upload a public-key for the delegated number. Or it could even divorce = the process of number delegation from STIR altogether - for example we = could rely on existing number-lookup databases providing a SPID of the = delegated-to carrier, and use a separate web-pki model for certificate = signing of SPIDs (instead of directly relating the signing to indicate = authority of numbers). > The mechanism must allow parties who are not delegated a telephone = number, but are preauthorized by the entity who is delegated the number, = to place calls using the identity. Expansion of the > authentication mechanism to identities using the user@domain form = should be considered in the initial design. After completing the SIP = end to end solution, the working group will consider session = establishment where there are one or more non-SIP hops, most likely = using an out-of-band authentication mechanism. However, the in-band and = out-of-band mechanisms should share as much in common as possible, = especially the credentials. >=20 > The working group will coordinate with the Security Area on credential = management. >=20 > The working group will coordinate with other working groups in the RAI = Area regarding signaling through existing deployments, including = INSIPID. I think you mean "STRAW", not INSIPID. Or maybe you mean both STRAW and = INSIPID. It is not at all clear we can or should use the INSIPID WG's = output, for example. [snip] > The working group will deliver the following: >=20 > - A problem statement detailing the deployment environment and > situation that motivate work on secure telephone identity >=20 > - A mechanism document describing the SIP end-to-end with telephone > number-based identities=20 >=20 > - A document describing the credentials required to support secure > telephone identity >=20 > - A fallback mechanism to allow out-of-band identity establishment > during call setup In other text of this charter it only says we will likely use an = out-of-band solution. But here it has a deliverable and below it has a = milestone for an out-of-band mechanism. Was this intentional or just = legacy wording from previous charter versions? > Milestones >=20 > Sep 2013 Submit problem statement for Informational > Nov 2013 Submit RFC4474bis for Proposed Standard > Feb 2014 Submit credential specification for Proposed Standard > Jun 2014 Submit fallback for Proposed Standard >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Thu Jul 11 21:39: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 CA98211E8203 for ; Thu, 11 Jul 2013 21:39:20 -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 Z5ZmsATsc32n for ; Thu, 11 Jul 2013 21:39:15 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6F79911E81F7 for ; Thu, 11 Jul 2013 21:39:15 -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 r6C4dEqA008480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 12 Jul 2013 04:39:15 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 r6C4dDAA001802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Jul 2013 04:39:14 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 r6C4dDYC018385 for ; Fri, 12 Jul 2013 04:39:13 GMT Received: from [192.168.2.80] (/184.74.74.115) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Jul 2013 21:39:13 -0700 From: Hadriel Kaplan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jul 2013 00:39:11 -0400 References: <20130712043221.11767.74779.idtracker@ietfa.amsl.com> To: "stir@ietf.org" Message-Id: <1F4B4D44-BD3E-4995-876A-147832C925F9@oracle.com> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Subject: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 04:39:20 -0000 Howdy, I've been meaning to submit a couple drafts for STIR - one for how a DNS = model could work, and one for how the stuff can get through SIP and = other protocols in-band. Since some of the recent discussion has touched on some of the issues, = and the deadline for new drafts is fast approaching, I've submitted the = latter draft just now: http://tools.ietf.org/html/draft-kaplan-stir-ikes-out-00 Sorry about the length, and yes it's still drafty/straw-man-ish. It's = also repetitive in sections, and needs a re-write, but the general = concept should be understandable. Comments/flames appreciated. -hadriel Begin forwarded message: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : An Identity Key-based and Effective Signature = for Origin-Unknown Types > Author(s) : Hadriel Kaplan > Filename : draft-kaplan-stir-ikes-out-00.txt > Pages : 28 > Date : 2013-07-11 >=20 > Abstract: > This document describes a mechanism and format for signing source > identity information of communication requests, in a manner capable > of crossing multiple communication protocol types - even if the > origin's protocol type is unknown. This is useful for providing > E.164 and other forms of Caller-ID reputability for various > communication protocols, such as SIP, XMPP, WebRTC, H.323, and > SS7/ISUP. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-kaplan-stir-ikes-out >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-kaplan-stir-ikes-out-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From hala.mowafy@ericsson.com Thu Jul 11 22:20: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 BA7D311E8203 for ; Thu, 11 Jul 2013 22:20:10 -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 8m-DYKc8Im2B for ; Thu, 11 Jul 2013 22:20:05 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 106F911E80F8 for ; Thu, 11 Jul 2013 22:20:04 -0700 (PDT) X-AuditID: c618062d-b7fc36d0000032ea-7d-51df920468d9 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id AD.8D.13034.4029FD15; Fri, 12 Jul 2013 07:20:04 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Fri, 12 Jul 2013 01:20:03 -0400 From: Hala Mowafy To: Stephen Farrell , Russ Housley Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIGc5Pe89T9eky9pxNQ9LRzuJlgBgeAgABss8A= Date: Fri, 12 Jul 2013 05:20:03 +0000 Message-ID: <728F35AE98AEDB4A96FF3A32A85A60BB11367DF9@eusaamb105.ericsson.se> References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> In-Reply-To: <51DEF16D.2070909@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyuXRPgi7LpPuBBl+7ZSymnbzMbPHqxU12 i6l9thbT915jt1i+dhuTA6vH2u6rbB5Llvxk8pi8cRaLx46G58weq+58YQ1gjeKySUnNySxL LdK3S+DK2Pf7BGPBQq+KU1+fsjYwnrbpYuTkkBAwkdgzsYcZwhaTuHBvPVsXIxeHkMBRRomp W1ewQzjLGSXu39kMVsUmoCMx5+9HMFtEIEyi9cITdhCbWSBToufFdbC4sICaxPXbu5kgatQl Hj/5A2VbSUxZ2c7SxcjBwSKgKtH9JRgkzCvgK3FswykWiF0nGCW+fWoBm8MpoCmx//5dFhCb Eei676fWMEHsEpe49WQ+E8TVAhJL9pyH+kBU4uXjf6wQtrLE9zmPWCDqdSQW7P7EBmFrSyxb +JoZYrGgxMmZT1gmMIrNQjJ2FpKWWUhaZiFpWcDIsoqRo7Q4tSw33chgEyMwwo5JsOnuYNzz 0vIQozQHi5I47yq9M4FCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGMNP9k5JNvgo8pnNiul9 drXB6yl5isXXzFlO7gwRt7T9fjnf9e6clJacrv/7DRxvMxUHFP48vfgJj4SO49/tS26wSxgu /bdmuWCYyOIbzc9vsjmHf3XRMnae8N7xnZcze4j/1Rcz+acl/ez447F3bqVtqNh225dqF+aK 7pWedW+WawfH7rLdBUosxRmJhlrMRcWJAMf8zgh+AgAA Cc: Richard Barnes , "stir@ietf.org" , Brian Rosen Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 05:20:10 -0000 Stephen, If I understand your question correctly AND you're emulating the same ringi= ng patterns that customers are used to in the PSTN, the called party would = expect to see the caller ID before the second ring. So, in effect, you hav= e 2 sec ON (first ring) - 4 sec OFF (silence) to get that caller ID verifie= d and delivered before the second ring (6 sec total). That's in North Amer= ica. In the UK and other parts of the world the ringing cadence varies but= I believe it is shorter (~ 3 seconds total). So, all authorization transactions PLUS any other session setup time with t= he phone, etc., have to fit in those timeframes, even though you don't need= those ring times for a SIP call - per se; you're just preserving the custo= mer experience. My question to the OCSP experts is: what is an average OCSP query response= time if we just stay within one country? are we talking milliseconds or s= econds? Hala -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Ste= phen Farrell Sent: Thursday, July 11, 2013 1:55 PM To: Russ Housley Cc: Richard Barnes; stir@ietf.org; Gonzalo Camarillo; Brian Rosen Subject: Re: [stir] Draft STIR Charter Hi Russ, I think this looks pretty good. A few wordsmithing changes and a question b= elow but I have one addition to suggest: Somewhere this should say that the solution chosen needs to have an accepta= ble overhead at both signer and verifer or else it also won't be deployed. = There may be some on here who could suggest indicative timing or networking= constraints (e.g. not having to do ~5 OCSP transactions to possibly anywhe= re in the world) and if so, that'd be a good thing to include IMO. On 07/11/2013 03:21 PM, Russ Housley wrote: > Dear STIR Mail List Participants: >=20 > Brian and I have tried to pull together charter text based on the=20 > discussion to date. >=20 > The closer we can get to consensus on the list before the BOF, the=20 > more likely that we can get a WG shortly after Berlin. To this end,=20 > please review and comment on the attached text. Brian and I will hold=20 > the pen for updates to the text. >=20 > Russ >=20 > =3D =3D =3D =3D =3D >=20 > Name: Secure Telephone Identity Revisited (stir) Area: RAI >=20 > Chairs: TBD Area Advisor: Richard Barnes >=20 > Mailing list: stir@ietf.org To Subscribe: > https://www.ietf.org/mailman/listinfo/stir >=20 > Over the last decade, a growing set of problems have resulted from the=20 > lack of security mechanisms for attesting the origins of real-time=20 > communications. As with email, the claimed source identity of a SIP=20 > request is not verified, and this permits unauthorized use of source=20 > identities as part of deceptive and coercive activities, such as=20 > robocalling (bulk unsolicited commercial communications), vishing=20 > (voicemail hacking, and impersonating banks) and swatting=20 > (impersonating callers to emergency services to stimulate unwarranted=20 > large scale law enforcement deployments). This working group will=20 > define a deployable mechanism to validate the identity of the calling=20 > party that can be verified by entities in the path of a call. >=20 > SIP is one of the main VoIP technologies used by parties that want to=20 > present an incorrect origination. A number of previous efforts have=20 > tried to secure the origins of SIP communications, including RFC 3325,=20 > RFC 4474, and the VIPR working group. To date, however, true=20 > validation of the source of SIP calls has not seen any appreciable=20 > deployment. Several factors contributed to this lack of success, > including: failure of the problem to be seen as critical at the time;=20 > lack of any real means of asserting authority over telephone numbers;=20 > misalignment of the mechanisms proposed by RFC 4474 with the complex=20 > deployment environment that has emerged for SIP; lack of end-to-end=20 > SIP session establishment; and inherent operational problems with a=20 > transitive trust model. >=20 > Initially, the working group will specify an in-band mechanism to=20 > authenticate the originator of a SIP session where the identity being=20 > authenticated is a telephone number and the session is established=20 > with SIP end to end. The working group will consider choices for=20 > protecting the identity information and the credentials used, but will=20 > likely be similar to the methods described in RFC 4474, which employs=20 > a signature over a set of information in the SIP headers using a=20 > credential assigned to the identity. I suggest replacing the above with "will likely be based on a digital signature mechanism that is cryptographi= cally similar to the one described in RFC 4474 and where the signature cont= inues to be represented in SIP headers." Saying "methods" and 4474 is a bit vague and could be read to mean "s/mime-= based" or "cms based" or "x.509 based" whereas what I think we want is just= to say its a signature. Similarly "assigned to the identity" is very ambiguous and probably better = just omitted for now. > In order to be > authoritative, credentials used with this mechanism will be derived=20 > from existing telephone number assignment and delegation models. No specific change suggested but are we using credential here to mean the p= rivate key or a (set of) TN(s) associated with a public key? I think it oug= ht be the latter. > That is, when a telephone number or range of telephone numbers is=20 > delegated to an entity, a credential will accompany such delegation. That's problematic with either definition of credential. I think it'd be ok= to say: That is, when a telephone number or range of telephone numbers is delegated to an entity, relevant credentials will be generated (or modified) to reflect such delegation. > The mechanism must allow parties who are not delegated a telephone=20 > number, but are preauthorized by the entity who is delegated the=20 > number, to place calls using the identity. No specific change suggested, but I've always wondered if this requirement = is real. I'd argue enough good would be done without try to stretch for thi= s. But I defer to those who know more about the application. > Expansion of the > authentication mechanism to identities using the user@domain form=20 > should be considered in the initial design. To be honest, I didn't read that thread (one too many:-) but I'm surprised = that this is to be part of the initial design. But "considered" is sort of = weasel-wordy so I'm not sure what's really meant - what is "considered" mea= nt to mean here? Cheers, S. > After completing the SIP > end to end solution, the working group will consider session=20 > establishment where there are one or more non-SIP hops, most likely=20 > using an out-of-band authentication mechanism. However, the in-band=20 > and out-of-band mechanisms should share as much in common as possible,=20 > especially the credentials. >=20 > The working group will coordinate with the Security Area on credential=20 > management. >=20 > The working group will coordinate with other working groups in the RAI=20 > Area regarding signaling through existing deployments, including=20 > INSIPID. >=20 > Authenticated identity is closely linked to privacy, and one=20 > frequently comes at the cost of the other. This working group is not=20 > chartered to mandate the presence of identity in SIP requests, and to=20 > the extent feasible it will find privacy-friendly solutions that leak=20 > minimal information about calls to third parties. >=20 > Input to working group discussions shall include: >=20 > Private Extensions to the Session Initiation Protocol (SIP) for=20 > Asserted Identity within Trusted Networks RFC 3325 >=20 > Enhancements for Authenticated Identity Management in the Session=20 > 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=20 > 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 > The working group will deliver the following: >=20 > - A problem statement detailing the deployment environment and=20 > situation that motivate work on secure telephone identity >=20 > - A mechanism document describing the SIP end-to-end with telephone=20 > number-based identities >=20 > - A document describing the credentials required to support secure=20 > telephone identity >=20 > - A fallback mechanism to allow out-of-band identity establishment=20 > during call setup >=20 > Milestones >=20 > Sep 2013 Submit problem statement for Informational Nov 2013 > Submit RFC4474bis for Proposed Standard Feb 2014 Submit credential > specification for Proposed Standard Jun 2014 Submit fallback for > Proposed Standard >=20 > _______________________________________________ stir mailing list=20 > 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 stephen.farrell@cs.tcd.ie Fri Jul 12 03:33: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 E618C21F9DA9 for ; Fri, 12 Jul 2013 03:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 UnIS5EOUIUJv for ; Fri, 12 Jul 2013 03:33:21 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5F521F9D91 for ; Fri, 12 Jul 2013 03:33:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 42CADBEB2; Fri, 12 Jul 2013 11:32:56 +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 AoqDKO08pC+I; Fri, 12 Jul 2013 11:32:56 +0100 (IST) Received: from [IPv6:2001:770:10:203:946e:342:bdd8:1eb4] (unknown [IPv6:2001:770:10:203:946e:342:bdd8:1eb4]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C1A83BE7B; Fri, 12 Jul 2013 11:32:54 +0100 (IST) Message-ID: <51DFDB57.1040809@cs.tcd.ie> Date: Fri, 12 Jul 2013 11:32:55 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Rosen, Brian" References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> In-Reply-To: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Peterson, Jon" , "rlb@ipv.sx" , "housley@vigilsec.com" , "Gonzalo.Camarillo@ericsson.com" , "stir@ietf.org" , Michael Hammer , "timothy.dwight@verizon.com" , "Henning.Schulzrinne@fcc.gov" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 10:33:26 -0000 On 07/11/2013 09:29 PM, Rosen, Brian wrote: > Yeah, well, let's talk about that, because you are right. > > It really would be a good idea to be able to get a call which had a > called party number of 9-1-1 or 1-1-2 and was verifiably from that > number. > > We certainly want to be able to handle "toll free" numbers, which in > many cases are not actually e.164s, even though they look like them. > > The problem is that while the latter is usually easy to handle, > because even if 18005551212 is not truly an e.164, we certainly could > canonicalize them as if they were and everything would work, doing > that with 1-1-2 is another story. > > Probably not worth dealing with these issues in charter language. > > So, Stephen, unless someone can come up with some wording that works, > I'd prefer to defer the discussion to the work group (if/when we get > one), rather than do it in charter language. Given the amount of discussion this caused (sorry for that:-), I agree. S. > > Brian > > On Jul 11, 2013, at 4:22 PM, "Peterson, Jon" > wrote: > >> >> My understanding was that certain nationally-specific numbers, such >> as freephone numbers, actually don't fall under the E.164 plan, and >> that thus restricting this to "E.164 numbers" may rule out some >> numbers we probably want to provide identity for. These numbers >> have the quality that they aren't reachable internationally. No? >> >> Jon Peterson Neustar, Inc. >> >> On 7/11/13 12:32 PM, "Michael Hammer" >> wrote: >> >>> Tim, >>> >>> The national specific part is a sub-component of the complete >>> E.164 number. >>> >>> You wouldn't call a car complete if you took the engine out. :) >>> >>> Mike >>> >>> >>> -----Original Message----- From: stir-bounces@ietf.org >>> [mailto:stir-bounces@ietf.org] On Behalf Of Dwight, Timothy M >>> (Tim) Sent: Thursday, July 11, 2013 3:23 PM To: Henning >>> Schulzrinne; 'Stephen Farrell'; Rosen, Brian Cc: Richard Barnes; >>> ; Russ Housley; Gonzalo Camarillo Subject: Re: >>> [stir] Draft STIR Charter >>> >>> Henning, >>> >>> I think what you describe is what Rec. E.164 calls an >>> International E.164 number. It also discusses National >>> (Significant) Numbers, which are the International E.164 number >>> minus the Country Code. >>> >>> tim >>> >>> -----Original Message----- From: stir-bounces@ietf.org >>> [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne >>> Sent: Thursday, July 11, 2013 2:00 PM To: 'Stephen Farrell'; >>> Rosen, Brian Cc: Richard Barnes; ; Russ Housley; >>> Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter >>> >>> E.164 implies full phone number. >>> >>> From E.164, Section 6.2: >>> >>> The international ITU-T E.164-number is composed of a variable >>> number of decimal digits arranged in specific code fields. The >>> international ITU-T E.164-number code fields are the country code >>> (CC) and remaining fields are specific to the use being made of >>> the international ITU-T E.164 number as shown in Figures 1 to 5. >>> A numbering plan does not include prefixes, suffixes, and >>> additional information required to complete a call. >>> >>> -----Original Message----- From: stir-bounces@ietf.org >>> [mailto:stir-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: >>> Thursday, July 11, 2013 2:53 PM To: Rosen, Brian Cc: Richard >>> Barnes; ; Russ Housley; Gonzalo Camarillo Subject: >>> Re: [stir] Draft STIR Charter >>> >>> >>> >>> On 07/11/2013 07:29 PM, Rosen, Brian wrote: >>>> So maybe where we say "where the identity being authenticated >>>> is a telephone number" add "in e.164 format"? >>> >>> Better all right. Some people were saying "full e.164" which I >>> guess means including country code and a +, which'd be even >>> better, if its not already implied in e.164. >>> >>> _______________________________________________ stir mailing >>> 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 Fri Jul 12 03: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 6DD8E21F9D66 for ; Fri, 12 Jul 2013 03:38:22 -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.063, 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 Awp9NR6fDmmB for ; Fri, 12 Jul 2013 03:38:17 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id DB63121F9D49 for ; Fri, 12 Jul 2013 03:38:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 452CABEC0; Fri, 12 Jul 2013 11:37:55 +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 bgNmmxuZyguo; Fri, 12 Jul 2013 11:37:55 +0100 (IST) Received: from [IPv6:2001:770:10:203:946e:342:bdd8:1eb4] (unknown [IPv6:2001:770:10:203:946e:342:bdd8:1eb4]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1B939BEBF; Fri, 12 Jul 2013 11:37:55 +0100 (IST) Message-ID: <51DFDC83.6060005@cs.tcd.ie> Date: Fri, 12 Jul 2013 11:37:55 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Russ Housley References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Richard Barnes , stir@ietf.org, Gonzalo Camarillo , Brian Rosen Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 10:38:25 -0000 Hi Russ, On 07/11/2013 08:31 PM, Russ Housley wrote: > Stephen: > >> I think this looks pretty good. A few wordsmithing changes and a >> question below but I have one addition to suggest: >> >> Somewhere this should say that the solution chosen needs to have an >> acceptable overhead at both signer and verifer or else it also >> won't be deployed. There may be some on here who could suggest >> indicative timing or networking constraints (e.g. not having to do >> ~5 OCSP transactions to possibly anywhere in the world) and if so, >> that'd be a good thing to include IMO. > > Does this single sentence capture your point? > > To make deployment of this solution more likely, consideration must > be given to the overhead for the call source and all verifiers. That's fine. > > >> >> On 07/11/2013 03:21 PM, Russ Housley wrote: >>> Dear STIR Mail List Participants: >>> >>> Brian and I have tried to pull together charter text based on >>> the discussion to date. >>> >>> The closer we can get to consensus on the list before the BOF, >>> the more likely that we can get a WG shortly after Berlin. To >>> this end, please review and comment on the attached text. Brian >>> and I will hold the pen for updates to the text. >>> >>> Russ >>> >>> = = = = = >>> >>> Name: Secure Telephone Identity Revisited (stir) Area: RAI >>> >>> Chairs: TBD Area Advisor: Richard Barnes >>> >>> Mailing list: stir@ietf.org To Subscribe: >>> https://www.ietf.org/mailman/listinfo/stir >>> >>> 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. As with email, the claimed source >>> identity of a SIP request is not verified, and this permits >>> unauthorized use of source identities as part of deceptive and >>> coercive activities, such as robocalling (bulk unsolicited >>> commercial communications), vishing (voicemail hacking, and >>> impersonating banks) and swatting (impersonating callers to >>> emergency services to stimulate unwarranted large scale law >>> enforcement deployments). This working group will define a >>> deployable mechanism to validate the identity of the calling >>> party that can be verified by entities in the path of a call. >>> >>> SIP is one of the main VoIP technologies used by parties that >>> want to present an incorrect origination. A number of previous >>> efforts have tried to secure the origins of SIP communications, >>> including RFC 3325, RFC 4474, and the VIPR working group. To >>> date, however, true validation of the source of SIP calls has not >>> seen any appreciable deployment. Several factors contributed to >>> this lack of success, including: failure of the problem to be >>> seen as critical at the time; lack of any real means of asserting >>> authority over telephone numbers; misalignment of the mechanisms >>> proposed by RFC 4474 with the complex deployment environment that >>> has emerged for SIP; lack of end-to-end SIP session >>> establishment; and inherent operational problems with a >>> transitive trust model. >>> >>> Initially, the working group will specify an in-band mechanism >>> to authenticate the originator of a SIP session where the >>> identity being authenticated is a telephone number and the >>> session is established with SIP end to end. The working group >>> will consider choices for protecting the identity information and >>> the credentials used, but will likely be similar to the methods >>> described in RFC 4474, which employs a signature over a set of >>> information in the SIP headers using a credential assigned to the >>> identity. >> >> I suggest replacing the above with >> >> "will likely be based on a digital signature mechanism that is >> cryptographically similar to the one described in RFC 4474 and >> where the signature continues to be represented in SIP headers." >> >> Saying "methods" and 4474 is a bit vague and could be read to mean >> "s/mime-based" or "cms based" or "x.509 based" whereas what I think >> we want is just to say its a signature. >> >> Similarly "assigned to the identity" is very ambiguous and probably >> better just omitted for now. > > Some means of associating the identity with the public key is > needed. > > How about: > > The working group will consider choices for protecting the identity > information and the credentials used, but will likely be based on a > digital signature mechanism that covers a set of information in the > SIP headers, and verification will employ a credential that contains > the public key and is associated with the identity. Lovely. > >> >> >>> In order to be authoritative, credentials used with this >>> mechanism will be derived from existing telephone number >>> assignment and delegation models. >> >> No specific change suggested but are we using credential here to >> mean the private key or a (set of) TN(s) associated with a public >> key? I think it ought be the latter. > > Does the above also resolve this question? Yep. >>> That is, when a telephone number or range of telephone numbers >>> is delegated to an entity, a credential will accompany such >>> delegation. >> >> That's problematic with either definition of credential. I think >> it'd be ok to say: >> >> That is, when a telephone number or range of telephone numbers is >> delegated to an entity, relevant credentials will be generated (or >> modified) to reflect such delegation. > > This seems fine to me. Lovelier. > >> >>> The mechanism must allow parties who are not delegated a >>> telephone number, but are preauthorized by the entity who is >>> delegated the number, to place calls using the identity. >> >> No specific change suggested, but I've always wondered if this >> requirement is real. I'd argue enough good would be done without >> try to stretch for this. But I defer to those who know more about >> the application. >> >>> Expansion of the authentication mechanism to identities using the >>> user@domain form should be considered in the initial design. >> >> To be honest, I didn't read that thread (one too many:-) but I'm >> surprised that this is to be part of the initial design. But >> "considered" is sort of weasel-wordy so I'm not sure what's really >> meant - what is "considered" meant to mean here? > > If we come up with a clean way to handle both identity forms > (telephone numbers and user@domain), then this would be really useful > for everyone. But, we are chartered for telephone numbers... Fair enough. I think if you make that explicit the wg might avoid some ratholes. How about if it said: Expansion of the authentication mechanism to identifiers using the user@domain form should be considered in the initial design but the main focus of the working group is to develop a solution for telephone numbers. Feel free to use that or not, as you prefer. Cheers, S. > > Russ > > _______________________________________________ stir mailing list > stir@ietf.org https://www.ietf.org/mailman/listinfo/stir > From stephen.farrell@cs.tcd.ie Fri Jul 12 03:52: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 D827521F9B08 for ; Fri, 12 Jul 2013 03:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 LHYtsQ3mFMwz for ; Fri, 12 Jul 2013 03:51: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 9080B21F9B0D for ; Fri, 12 Jul 2013 03:51:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D38E7BEC0; Fri, 12 Jul 2013 11:51: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 lV4Oah8CbeG1; Fri, 12 Jul 2013 11:51:37 +0100 (IST) Received: from [IPv6:2001:770:10:203:946e:342:bdd8:1eb4] (unknown [IPv6:2001:770:10:203:946e:342:bdd8:1eb4]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 66D57BEB2; Fri, 12 Jul 2013 11:51:37 +0100 (IST) Message-ID: <51DFDFBA.5090002@cs.tcd.ie> Date: Fri, 12 Jul 2013 11:51:38 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hala Mowafy References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <728F35AE98AEDB4A96FF3A32A85A60BB11367DF9@eusaamb105.ericsson.se> In-Reply-To: <728F35AE98AEDB4A96FF3A32A85A60BB11367DF9@eusaamb105.ericsson.se> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Richard Barnes , "stir@ietf.org" , Russ Housley , Brian Rosen Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 10:52:04 -0000 On 07/12/2013 06:20 AM, Hala Mowafy wrote: > Stephen, If I understand your question correctly AND you're emulating > the same ringing patterns that customers are used to in the PSTN, the > called party would expect to see the caller ID before the second > ring. So, in effect, you have 2 sec ON (first ring) - 4 sec OFF > (silence) to get that caller ID verified and delivered before the > second ring (6 sec total). That's in North America. In the UK and > other parts of the world the ringing cadence varies but I believe it > is shorter (~ 3 seconds total). So, all authorization transactions > PLUS any other session setup time with the phone, etc., have to fit > in those timeframes, even though you don't need those ring times for > a SIP call - per se; you're just preserving the customer experience. > > My question to the OCSP experts is: what is an average OCSP query > response time if we just stay within one country? are we talking > milliseconds or seconds? There're some netcraft numbers. [1,2] Browsers are perhaps more sensitive to delays (or maybe not) but they've found this to be an issue, to the point where a solution that includes pre-cooked OCSP responses in the TLS handshake (stapling) was developed. [3,4] So OCSP works but if you build a complex PKI for the delegations it might become problematic, esp. if there's much chance of some of the OCSP responders being flakey or far away since you have to get an OCSP response for each certificate in each certificate chain in the general case. S. [1] http://news.netcraft.com/archives/2013/04/22/ocsp-server-performance-in-march-2013.html [2] http://uptime.netcraft.com/perf/reports/performance/OCSP?orderby=epercent&tn=march_2013 [3] https://tools.ietf.org/html/rfc6961 [4] https://en.wikipedia.org/wiki/OCSP_Stapling > > Hala > > -----Original Message----- From: stir-bounces@ietf.org > [mailto:stir-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: > Thursday, July 11, 2013 1:55 PM To: Russ Housley Cc: Richard Barnes; > stir@ietf.org; Gonzalo Camarillo; Brian Rosen Subject: Re: [stir] > Draft STIR Charter > > > Hi Russ, > > I think this looks pretty good. A few wordsmithing changes and a > question below but I have one addition to suggest: > > Somewhere this should say that the solution chosen needs to have an > acceptable overhead at both signer and verifer or else it also won't > be deployed. There may be some on here who could suggest indicative > timing or networking constraints (e.g. not having to do ~5 OCSP > transactions to possibly anywhere in the world) and if so, that'd be > a good thing to include IMO. > > On 07/11/2013 03:21 PM, Russ Housley wrote: >> Dear STIR Mail List Participants: >> >> Brian and I have tried to pull together charter text based on the >> discussion to date. >> >> The closer we can get to consensus on the list before the BOF, the >> more likely that we can get a WG shortly after Berlin. To this >> end, please review and comment on the attached text. Brian and I >> will hold the pen for updates to the text. >> >> Russ >> >> = = = = = >> >> Name: Secure Telephone Identity Revisited (stir) Area: RAI >> >> Chairs: TBD Area Advisor: Richard Barnes >> >> Mailing list: stir@ietf.org To Subscribe: >> https://www.ietf.org/mailman/listinfo/stir >> >> 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. As with email, the claimed source >> identity of a SIP request is not verified, and this permits >> unauthorized use of source identities as part of deceptive and >> coercive activities, such as robocalling (bulk unsolicited >> commercial communications), vishing (voicemail hacking, and >> impersonating banks) and swatting (impersonating callers to >> emergency services to stimulate unwarranted large scale law >> enforcement deployments). This working group will define a >> deployable mechanism to validate the identity of the calling party >> that can be verified by entities in the path of a call. >> >> SIP is one of the main VoIP technologies used by parties that want >> to present an incorrect origination. A number of previous efforts >> have tried to secure the origins of SIP communications, including >> RFC 3325, RFC 4474, and the VIPR working group. To date, however, >> true validation of the source of SIP calls has not seen any >> appreciable deployment. Several factors contributed to this lack >> of success, including: failure of the problem to be seen as >> critical at the time; lack of any real means of asserting authority >> over telephone numbers; misalignment of the mechanisms proposed by >> RFC 4474 with the complex deployment environment that has emerged >> for SIP; lack of end-to-end SIP session establishment; and inherent >> operational problems with a transitive trust model. >> >> Initially, the working group will specify an in-band mechanism to >> authenticate the originator of a SIP session where the identity >> being authenticated is a telephone number and the session is >> established with SIP end to end. The working group will consider >> choices for protecting the identity information and the credentials >> used, but will likely be similar to the methods described in RFC >> 4474, which employs a signature over a set of information in the >> SIP headers using a credential assigned to the identity. > > I suggest replacing the above with > > "will likely be based on a digital signature mechanism that is > cryptographically similar to the one described in RFC 4474 and where > the signature continues to be represented in SIP headers." > > Saying "methods" and 4474 is a bit vague and could be read to mean > "s/mime-based" or "cms based" or "x.509 based" whereas what I think > we want is just to say its a signature. > > Similarly "assigned to the identity" is very ambiguous and probably > better just omitted for now. > > >> In order to be authoritative, credentials used with this mechanism >> will be derived from existing telephone number assignment and >> delegation models. > > No specific change suggested but are we using credential here to mean > the private key or a (set of) TN(s) associated with a public key? I > think it ought be the latter. > >> That is, when a telephone number or range of telephone numbers is >> delegated to an entity, a credential will accompany such >> delegation. > > That's problematic with either definition of credential. I think it'd > be ok to say: > > That is, when a telephone number or range of telephone numbers is > delegated to an entity, relevant credentials will be generated (or > modified) to reflect such delegation. > >> The mechanism must allow parties who are not delegated a telephone >> number, but are preauthorized by the entity who is delegated the >> number, to place calls using the identity. > > No specific change suggested, but I've always wondered if this > requirement is real. I'd argue enough good would be done without try > to stretch for this. But I defer to those who know more about the > application. > >> Expansion of the authentication mechanism to identities using the >> user@domain form should be considered in the initial design. > > To be honest, I didn't read that thread (one too many:-) but I'm > surprised that this is to be part of the initial design. But > "considered" is sort of weasel-wordy so I'm not sure what's really > meant - what is "considered" meant to mean here? > > Cheers, S. > >> After completing the SIP end to end solution, the working group >> will consider session establishment where there are one or more >> non-SIP hops, most likely using an out-of-band authentication >> mechanism. However, the in-band and out-of-band mechanisms should >> share as much in common as possible, especially the credentials. >> >> The working group will coordinate with the Security Area on >> credential management. >> >> The working group will coordinate with other working groups in the >> RAI Area regarding signaling through existing deployments, >> including INSIPID. >> >> Authenticated identity is closely linked to privacy, and one >> frequently 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. >> >> 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 >> >> The working group will deliver the following: >> >> - A problem statement detailing the deployment environment and >> situation that motivate work on secure telephone identity >> >> - A mechanism document describing the SIP end-to-end with telephone >> number-based identities >> >> - A document describing the credentials required to support secure >> telephone identity >> >> - A fallback mechanism to allow out-of-band identity establishment >> during call setup >> >> Milestones >> >> Sep 2013 Submit problem statement for Informational Nov 2013 >> Submit RFC4474bis for Proposed Standard Feb 2014 Submit >> credential specification for Proposed Standard Jun 2014 Submit >> fallback for Proposed Standard >> >> _______________________________________________ stir mailing list >> stir@ietf.org https://www.ietf.org/mailman/listinfo/stir >> >> > _______________________________________________ stir mailing list > stir@ietf.org https://www.ietf.org/mailman/listinfo/stir > From Henning.Schulzrinne@fcc.gov Fri Jul 12 06:00:00 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F2421F8C8E for ; Fri, 12 Jul 2013 06:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.017 X-Spam-Level: X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[AWL=0.582, 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 cNO0heqKiV8r for ; Fri, 12 Jul 2013 05:59:56 -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 AA66021F9E87 for ; Fri, 12 Jul 2013 05:59:54 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Hala Mowafy Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIF2w2hhDzu+kKP+YqzEEYfuplgBgeAgAC/b4CAADnpHw== Date: Fri, 12 Jul 2013 12:59:52 +0000 References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie>, <728F35AE98AEDB4A96FF3A32A85A60BB11367DF9@eusaamb105.ericsson.se> In-Reply-To: <728F35AE98AEDB4A96FF3A32A85A60BB11367DF9@eusaamb105.ericsson.se> 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: Richard Barnes , "stir@ietf.org" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 13:00:00 -0000 If you want to reject unwanted unvalidated calls, rather than just label th= e caller ID as valid, the validation needs to occur before the INVITE (or m= oral SS7/ISDN/MF equivalent) reaches the callee, i.e., it is part of the po= st-dial delay, the delay between dialing the last number and the start of r= inging. I had previously, on this list, referenced a UK guideline for accep= table PDD, which varies widely. We are used to fairly long PDD for cell pho= nes (5-10 seconds), as there are several database lookups for those calls, = among other delays. For landline, PDD has typically been much shorter. The = main problem with long PDD is call abandonment, particularly if there is si= lence on the calling side, so that the caller believes erroneously that som= ething is not working. (Faking ringback has its own set of issues.)=0A= =0A= As also discussed already, caching can greatly reduce any RTT-induced delay= s, given that most numbers would not change their public keys all that ofte= n. (For example, a carrier could cache all entries, and then use publish-su= bscribe event notification from the numbering authority to be informed of a= ny porting or key revocation changes.)=0A= =0A= With roughly 800 million US numbers, and 1 kB for each cert, you can fit al= l of these on a $100 disk, with a worst-case assumption that each number ha= s its own cert, rather than number ranges.=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Hala Mowaf= y [hala.mowafy@ericsson.com]=0A= Sent: Friday, July 12, 2013 1:20 AM=0A= To: Stephen Farrell; Russ Housley=0A= Cc: Richard Barnes; stir@ietf.org; Brian Rosen=0A= Subject: Re: [stir] Draft STIR Charter=0A= =0A= Stephen,=0A= If I understand your question correctly AND you're emulating the same ringi= ng patterns that customers are used to in the PSTN, the called party would = expect to see the caller ID before the second ring. So, in effect, you hav= e 2 sec ON (first ring) - 4 sec OFF (silence) to get that caller ID verifie= d and delivered before the second ring (6 sec total). That's in North Amer= ica. In the UK and other parts of the world the ringing cadence varies but= I believe it is shorter (~ 3 seconds total).=0A= So, all authorization transactions PLUS any other session setup time with t= he phone, etc., have to fit in those timeframes, even though you don't need= those ring times for a SIP call - per se; you're just preserving the custo= mer experience.=0A= =0A= My question to the OCSP experts is: what is an average OCSP query response= time if we just stay within one country? are we talking milliseconds or s= econds?=0A= Hala=0A= =0A= -----Original Message-----=0A= From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Ste= phen Farrell=0A= Sent: Thursday, July 11, 2013 1:55 PM=0A= To: Russ Housley=0A= Cc: Richard Barnes; stir@ietf.org; Gonzalo Camarillo; Brian Rosen=0A= Subject: Re: [stir] Draft STIR Charter=0A= =0A= =0A= Hi Russ,=0A= =0A= I think this looks pretty good. A few wordsmithing changes and a question b= elow but I have one addition to suggest:=0A= =0A= Somewhere this should say that the solution chosen needs to have an accepta= ble overhead at both signer and verifer or else it also won't be deployed. = There may be some on here who could suggest indicative timing or networking= constraints (e.g. not having to do ~5 OCSP transactions to possibly anywhe= re in the world) and if so, that'd be a good thing to include IMO.=0A= =0A= On 07/11/2013 03:21 PM, Russ Housley wrote:=0A= > Dear STIR Mail List Participants:=0A= >=0A= > Brian and I have tried to pull together charter text based on the=0A= > discussion to date.=0A= >=0A= > The closer we can get to consensus on the list before the BOF, the=0A= > more likely that we can get a WG shortly after Berlin. To this end,=0A= > please review and comment on the attached text. Brian and I will hold=0A= > the pen for updates to the text.=0A= >=0A= > Russ=0A= >=0A= > =3D =3D =3D =3D =3D=0A= >=0A= > Name: Secure Telephone Identity Revisited (stir) Area: RAI=0A= >=0A= > Chairs: TBD Area Advisor: Richard Barnes=0A= >=0A= > Mailing list: stir@ietf.org To Subscribe:=0A= > https://www.ietf.org/mailman/listinfo/stir=0A= >=0A= > Over the last decade, a growing set of problems have resulted from the=0A= > lack of security mechanisms for attesting the origins of real-time=0A= > communications. As with email, the claimed source identity of a SIP=0A= > request is not verified, and this permits unauthorized use of source=0A= > identities as part of deceptive and coercive activities, such as=0A= > robocalling (bulk unsolicited commercial communications), vishing=0A= > (voicemail hacking, and impersonating banks) and swatting=0A= > (impersonating callers to emergency services to stimulate unwarranted=0A= > large scale law enforcement deployments). This working group will=0A= > define a deployable mechanism to validate the identity of the calling=0A= > party that can be verified by entities in the path of a call.=0A= >=0A= > SIP is one of the main VoIP technologies used by parties that want to=0A= > present an incorrect origination. A number of previous efforts have=0A= > tried to secure the origins of SIP communications, including RFC 3325,=0A= > RFC 4474, and the VIPR working group. To date, however, true=0A= > validation of the source of SIP calls has not seen any appreciable=0A= > deployment. Several factors contributed to this lack of success,=0A= > including: failure of the problem to be seen as critical at the time;=0A= > lack of any real means of asserting authority over telephone numbers;=0A= > misalignment of the mechanisms proposed by RFC 4474 with the complex=0A= > deployment environment that has emerged for SIP; lack of end-to-end=0A= > SIP session establishment; and inherent operational problems with a=0A= > transitive trust model.=0A= >=0A= > Initially, the working group will specify an in-band mechanism to=0A= > authenticate the originator of a SIP session where the identity being=0A= > authenticated is a telephone number and the session is established=0A= > with SIP end to end. The working group will consider choices for=0A= > protecting the identity information and the credentials used, but will=0A= > likely be similar to the methods described in RFC 4474, which employs=0A= > a signature over a set of information in the SIP headers using a=0A= > credential assigned to the identity.=0A= =0A= I suggest replacing the above with=0A= =0A= "will likely be based on a digital signature mechanism that is cryptographi= cally similar to the one described in RFC 4474 and where the signature cont= inues to be represented in SIP headers."=0A= =0A= Saying "methods" and 4474 is a bit vague and could be read to mean "s/mime-= based" or "cms based" or "x.509 based" whereas what I think we want is just= to say its a signature.=0A= =0A= Similarly "assigned to the identity" is very ambiguous and probably better = just omitted for now.=0A= =0A= =0A= > In order to be=0A= > authoritative, credentials used with this mechanism will be derived=0A= > from existing telephone number assignment and delegation models.=0A= =0A= No specific change suggested but are we using credential here to mean the p= rivate key or a (set of) TN(s) associated with a public key? I think it oug= ht be the latter.=0A= =0A= > That is, when a telephone number or range of telephone numbers is=0A= > delegated to an entity, a credential will accompany such delegation.=0A= =0A= That's problematic with either definition of credential. I think it'd be ok= to say:=0A= =0A= That is, when a telephone number or range of telephone numbers is=0A= delegated to an entity, relevant credentials will be generated (or=0A= modified) to reflect such delegation.=0A= =0A= > The mechanism must allow parties who are not delegated a telephone=0A= > number, but are preauthorized by the entity who is delegated the=0A= > number, to place calls using the identity.=0A= =0A= No specific change suggested, but I've always wondered if this requirement = is real. I'd argue enough good would be done without try to stretch for thi= s. But I defer to those who know more about the application.=0A= =0A= > Expansion of the=0A= > authentication mechanism to identities using the user@domain form=0A= > should be considered in the initial design.=0A= =0A= To be honest, I didn't read that thread (one too many:-) but I'm surprised = that this is to be part of the initial design. But "considered" is sort of = weasel-wordy so I'm not sure what's really meant - what is "considered" mea= nt to mean here?=0A= =0A= Cheers,=0A= S.=0A= =0A= > After completing the SIP=0A= > end to end solution, the working group will consider session=0A= > establishment where there are one or more non-SIP hops, most likely=0A= > using an out-of-band authentication mechanism. However, the in-band=0A= > and out-of-band mechanisms should share as much in common as possible,=0A= > especially the credentials.=0A= >=0A= > The working group will coordinate with the Security Area on credential=0A= > management.=0A= >=0A= > The working group will coordinate with other working groups in the RAI=0A= > Area regarding signaling through existing deployments, including=0A= > INSIPID.=0A= >=0A= > Authenticated identity is closely linked to privacy, and one=0A= > frequently comes at the cost of the other. This working group is not=0A= > chartered to mandate the presence of identity in SIP requests, and to=0A= > the extent feasible it will find privacy-friendly solutions that leak=0A= > minimal information about calls to third parties.=0A= >=0A= > Input to working group discussions shall include:=0A= >=0A= > Private Extensions to the Session Initiation Protocol (SIP) for=0A= > Asserted Identity within Trusted Networks RFC 3325=0A= >=0A= > Enhancements for Authenticated Identity Management in the Session=0A= > Initiation Protocol (SIP) RFC 4474=0A= >=0A= > Secure Call Origin Identification=0A= > http://tools.ietf.org/html/draft-cooper-iab-secure-origin-00=0A= >=0A= > Secure Origin Identification: Problem Statement, Requirements, and=0A= > Roadmap=0A= > http://tools.ietf.org/html/draft-peterson-secure-origin-ps-00=0A= >=0A= > Authenticated Identity Management in the Session Initiation Protocol=0A= > (SIP)=0A= > http://tools.ietf.org/html/draft-jennings-dispatch-rfc4474bis-00=0A= >=0A= > The working group will deliver the following:=0A= >=0A= > - A problem statement detailing the deployment environment and=0A= > situation that motivate work on secure telephone identity=0A= >=0A= > - A mechanism document describing the SIP end-to-end with telephone=0A= > number-based identities=0A= >=0A= > - A document describing the credentials required to support secure=0A= > telephone identity=0A= >=0A= > - A fallback mechanism to allow out-of-band identity establishment=0A= > during call setup=0A= >=0A= > Milestones=0A= >=0A= > Sep 2013 Submit problem statement for Informational Nov 2013=0A= > Submit RFC4474bis for Proposed Standard Feb 2014 Submit credential=0A= > specification for Proposed Standard Jun 2014 Submit fallback for=0A= > Proposed Standard=0A= >=0A= > _______________________________________________ stir mailing list=0A= > stir@ietf.org https://www.ietf.org/mailman/listinfo/stir=0A= >=0A= >=0A= _______________________________________________=0A= stir mailing list=0A= stir@ietf.org=0A= https://www.ietf.org/mailman/listinfo/stir=0A= _______________________________________________=0A= stir mailing list=0A= stir@ietf.org=0A= https://www.ietf.org/mailman/listinfo/stir=0A= From philippe.fouquart@orange.com Fri Jul 12 07:13: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 0EC3921E8051 for ; Fri, 12 Jul 2013 07:13:46 -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.325, 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 fKz2v4iwmSZh for ; Fri, 12 Jul 2013 07:13:41 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 783DD21F9A48 for ; Fri, 12 Jul 2013 07:13:32 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 73D67264753; Fri, 12 Jul 2013 16:13:28 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id A0C0327C053; Fri, 12 Jul 2013 16:13:27 +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, 12 Jul 2013 16:13:27 +0200 From: To: "Rosen, Brian" , "Peterson, Jon" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIC/Xfx9OM2CUaqk2gsBTAQDJlfoXKAgAAEgQCAAANtAIAAAaIAgAAGyICAAAH7AIAABkaAgAACpACAAA3sAIAAAhCAgAFGPhA= Date: Fri, 12 Jul 2013 14:13:26 +0000 Message-ID: <3599_1373638407_51E00F07_3599_1118_1_B5939C6860701C49AA39C5DA5189448B0B4135@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> In-Reply-To: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@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.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.1.45418 X-Mailman-Approved-At: Fri, 12 Jul 2013 07:16:43 -0700 Cc: "rlb@ipv.sx" , "housley@vigilsec.com" , "Gonzalo.Camarillo@ericsson.com" , "stir@ietf.org" , "stephen.farrell@cs.tcd.ie" , Michael Hammer , "timothy.dwight@verizon.com" , "Henning.Schulzrinne@fcc.gov" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 14:13:46 -0000 Regarding tool free and the like, I would agree to defer this to a WG discu= ssion. I think we're now confusing reachability (which a relative concept e= ven in the so called _P_STN) and uniqueness. There are lots of E.164 number= s that are not globally reachable.=20=20 Whether this applies only to geographic country codes or to any E.164 count= ry codes is an interesting question. All I've read so far most applies to g= eographic country codes,... well, groups of countries in fact, mmmh... +1 a= ctually :) Re. national only numbers, I'd prefer dealing with this at a later stage. (= I'm not even sure it calls for a significantly different solution, other th= an the URI format, that is)=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 Ros= en, Brian Sent: Thursday, July 11, 2013 10:30 PM To: Peterson, Jon Cc: rlb@ipv.sx; housley@vigilsec.com; Gonzalo.Camarillo@ericsson.com; stir@= ietf.org; Henning.Schulzrinne@fcc.gov; Michael Hammer; timothy.dwight@veriz= on.com; stephen.farrell@cs.tcd.ie Subject: Re: [stir] Draft STIR Charter Yeah, well, let's talk about that, because you are right. It really would be a good idea to be able to get a call which had a called = party number of 9-1-1 or 1-1-2 and was verifiably from that number. We certainly want to be able to handle "toll free" numbers, which in many c= ases are not actually e.164s, even though they look like them. The problem is that while the latter is usually easy to handle, because eve= n if 18005551212 is not truly an e.164, we certainly could canonicalize the= m as if they were and everything would work, doing that with 1-1-2 is anoth= er story. Probably not worth dealing with these issues in charter language. So, Stephen, unless someone can come up with some wording that works, I'd p= refer to defer the discussion to the work group (if/when we get one), rathe= r than do it in charter language. Brian On Jul 11, 2013, at 4:22 PM, "Peterson, Jon" wrote: >=20 > My understanding was that certain nationally-specific numbers, such as > freephone numbers, actually don't fall under the E.164 plan, and that thus > restricting this to "E.164 numbers" may rule out some numbers we probably > want to provide identity for. These numbers have the quality that they > aren't reachable internationally. No? >=20 > Jon Peterson > Neustar, Inc. >=20 > On 7/11/13 12:32 PM, "Michael Hammer" wrot= e: >=20 >> Tim, >>=20 >> The national specific part is a sub-component of the complete E.164 >> number. >>=20 >> You wouldn't call a car complete if you took the engine out. :) >>=20 >> Mike >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >> Dwight, Timothy M (Tim) >> Sent: Thursday, July 11, 2013 3:23 PM >> To: Henning Schulzrinne; 'Stephen Farrell'; Rosen, Brian >> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >> Subject: Re: [stir] Draft STIR Charter >>=20 >> Henning, >>=20 >> I think what you describe is what Rec. E.164 calls an International E.164 >> number. It also discusses National (Significant) Numbers, which are the >> International E.164 number minus the Country Code. >>=20 >> tim >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >> Henning Schulzrinne >> Sent: Thursday, July 11, 2013 2:00 PM >> To: 'Stephen Farrell'; Rosen, Brian >> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >> Subject: Re: [stir] Draft STIR Charter >>=20 >> E.164 implies full phone number. >>=20 >> From E.164, Section 6.2: >>=20 >> The international ITU-T E.164-number is composed of a variable number of >> decimal digits arranged in specific code fields. The international ITU-T >> E.164-number code fields are the country code (CC) and remaining fields >> are >> specific to the use being made of the international ITU-T E.164 number as >> shown in Figures 1 to 5. >> A numbering plan does not include prefixes, suffixes, and additional >> information required to complete a call. >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >> Stephen Farrell >> Sent: Thursday, July 11, 2013 2:53 PM >> To: Rosen, Brian >> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >> Subject: Re: [stir] Draft STIR Charter >>=20 >>=20 >>=20 >> On 07/11/2013 07:29 PM, Rosen, Brian wrote: >>> So maybe where we say "where the identity being authenticated is a >>> telephone number" add "in e.164 format"? >>=20 >> Better all right. Some people were saying "full e.164" which I guess mea= ns >> including country code and a +, which'd be even better, if its not alrea= dy >> implied in e.164. >>=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 _______________________________________________ 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 brian.rosen@neustar.biz Fri Jul 12 07:18: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 4333621F99FE for ; Fri, 12 Jul 2013 07:18:15 -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.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyRPPOjwYi2b for ; Fri, 12 Jul 2013 07:18:11 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 1149621F9C60 for ; Fri, 12 Jul 2013 07:18:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1373638860; x=1688992524; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=6wDCU7G+Ax IGUxRsFx5xJ78BJHIWslQ3cZBpbqMcE+M=; b=gpw6HiJV4um0fsikWsXSd1nEZt 7z38menp5PxyK/TBupSuXtG+wCEIA+tTS5Mlo57cRaSSEO9Pn9RDvvpo9SAg== Received: from ([10.31.58.70]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.26618650; Fri, 12 Jul 2013 10:20: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, 12 Jul 2013 10:18:00 -0400 From: "Rosen, Brian" To: "" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkH7PavsqszcIEumRBC5KQ07J5lgBgeAgAAEgICAAANvAIAAAaEAgAAGyYCAAAH6AIAABkaAgAACpACAAA3sAIAAAhCAgAEpPQCAAAFFgA== Date: Fri, 12 Jul 2013 14:18:00 +0000 Message-ID: <9B2F33E0-E9DA-497C-8878-A251C2555D00@neustar.biz> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <3599_1373638407_51E00F07_3599_1118_1_B5939C6860701C49AA39C5DA5189448B0B4135@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <3599_1373638407_51E00F07_3599_1118_1_B5939C6860701C49AA39C5DA5189448B0B4135@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.192.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 7FufGATssitHiCpTNEiT6Q== Content-Type: text/plain; charset="us-ascii" Content-ID: <86F98F1180AB5149917EF8A517A95586@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 12 Jul 2013 07:18:37 -0700 Cc: "Peterson, Jon" , "rlb@ipv.sx" , "housley@vigilsec.com" , "Gonzalo.Camarillo@ericsson.com" , "stir@ietf.org" , "Henning.Schulzrinne@fcc.gov" , Michael Hammer , "timothy.dwight@verizon.com" , "stephen.farrell@cs.tcd.ie" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 14:18:15 -0000 Can we conclude this discussion by leaving the text alone, so it refers to = vague "telephone numbers" and not even try to define them further? Brian On Jul 12, 2013, at 10:13 AM, wrote: > Regarding tool free and the like, I would agree to defer this to a WG dis= cussion. I think we're now confusing reachability (which a relative concept= even in the so called _P_STN) and uniqueness. There are lots of E.164 numb= ers that are not globally reachable. =20 >=20 > Whether this applies only to geographic country codes or to any E.164 cou= ntry codes is an interesting question. All I've read so far most applies to= geographic country codes,... well, groups of countries in fact, mmmh... +1= actually :) >=20 > Re. national only numbers, I'd prefer dealing with this at a later stage.= (I'm not even sure it calls for a significantly different solution, other = than the URI format, that is) =20 >=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: Thursday, July 11, 2013 10:30 PM > To: Peterson, Jon > Cc: rlb@ipv.sx; housley@vigilsec.com; Gonzalo.Camarillo@ericsson.com; sti= r@ietf.org; Henning.Schulzrinne@fcc.gov; Michael Hammer; timothy.dwight@ver= izon.com; stephen.farrell@cs.tcd.ie > Subject: Re: [stir] Draft STIR Charter >=20 > Yeah, well, let's talk about that, because you are right. >=20 > It really would be a good idea to be able to get a call which had a calle= d party number of 9-1-1 or 1-1-2 and was verifiably from that number. >=20 > We certainly want to be able to handle "toll free" numbers, which in many= cases are not actually e.164s, even though they look like them. >=20 > The problem is that while the latter is usually easy to handle, because e= ven if 18005551212 is not truly an e.164, we certainly could canonicalize t= hem as if they were and everything would work, doing that with 1-1-2 is ano= ther story. >=20 > Probably not worth dealing with these issues in charter language. >=20 > So, Stephen, unless someone can come up with some wording that works, I'd= prefer to defer the discussion to the work group (if/when we get one), rat= her than do it in charter language. >=20 > Brian >=20 > On Jul 11, 2013, at 4:22 PM, "Peterson, Jon" > wrote: >=20 >>=20 >> My understanding was that certain nationally-specific numbers, such as >> freephone numbers, actually don't fall under the E.164 plan, and that th= us >> restricting this to "E.164 numbers" may rule out some numbers we probabl= y >> want to provide identity for. These numbers have the quality that they >> aren't reachable internationally. No? >>=20 >> Jon Peterson >> Neustar, Inc. >>=20 >> On 7/11/13 12:32 PM, "Michael Hammer" wro= te: >>=20 >>> Tim, >>>=20 >>> The national specific part is a sub-component of the complete E.164 >>> number. >>>=20 >>> You wouldn't call a car complete if you took the engine out. :) >>>=20 >>> Mike >>>=20 >>>=20 >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >>> Dwight, Timothy M (Tim) >>> Sent: Thursday, July 11, 2013 3:23 PM >>> To: Henning Schulzrinne; 'Stephen Farrell'; Rosen, Brian >>> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >>> Subject: Re: [stir] Draft STIR Charter >>>=20 >>> Henning, >>>=20 >>> I think what you describe is what Rec. E.164 calls an International E.1= 64 >>> number. It also discusses National (Significant) Numbers, which are th= e >>> International E.164 number minus the Country Code. >>>=20 >>> tim >>>=20 >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >>> Henning Schulzrinne >>> Sent: Thursday, July 11, 2013 2:00 PM >>> To: 'Stephen Farrell'; Rosen, Brian >>> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >>> Subject: Re: [stir] Draft STIR Charter >>>=20 >>> E.164 implies full phone number. >>>=20 >>> From E.164, Section 6.2: >>>=20 >>> The international ITU-T E.164-number is composed of a variable number o= f >>> decimal digits arranged in specific code fields. The international ITU-= T >>> E.164-number code fields are the country code (CC) and remaining fields >>> are >>> specific to the use being made of the international ITU-T E.164 number = as >>> shown in Figures 1 to 5. >>> A numbering plan does not include prefixes, suffixes, and additional >>> information required to complete a call. >>>=20 >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >>> Stephen Farrell >>> Sent: Thursday, July 11, 2013 2:53 PM >>> To: Rosen, Brian >>> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >>> Subject: Re: [stir] Draft STIR Charter >>>=20 >>>=20 >>>=20 >>> On 07/11/2013 07:29 PM, Rosen, Brian wrote: >>>> So maybe where we say "where the identity being authenticated is a >>>> telephone number" add "in e.164 format"? >>>=20 >>> Better all right. Some people were saying "full e.164" which I guess me= ans >>> including country code and a +, which'd be even better, if its not alre= ady >>> implied in e.164. >>>=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 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From brian.rosen@neustar.biz Fri Jul 12 07:25: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 34ED311E8127 for ; Fri, 12 Jul 2013 07:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.28 X-Spam-Level: X-Spam-Status: No, score=-6.28 tagged_above=-999 required=5 tests=[AWL=-0.234, 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 d29XP6FFppte for ; Fri, 12 Jul 2013 07:25:22 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 50BCA11E811A for ; Fri, 12 Jul 2013 07:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1373639296; x=1688992524; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=1uFaWP9Qwz iOFIlZPETZpQc4UUdWGqrTgVPfiPeLtQw=; b=dwHGJ7BeOgElS5aNvARpkw+6sn /5Bv/VC/zh0M3aizenPAD0WuTLiy4iA5y5v1Bv6NKQkFXFQ1adrIvI6Lfmwg== Received: from ([10.31.58.70]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.26619237; Fri, 12 Jul 2013 10:28: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; Fri, 12 Jul 2013 10:25:16 -0400 From: "Rosen, Brian" To: Hadriel Kaplan Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkH7PavsqszcIEumRBC5KQ07J5lgmC6AgADFnQA= Date: Fri, 12 Jul 2013 14:25:16 +0000 Message-ID: <12FF2857-14B4-4C7E-A1FD-BE89EFC01189@neustar.biz> References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@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.192.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: ERVv6IQZgiPNFx27xXrTkA== Content-Type: text/plain; charset="us-ascii" Content-ID: <2A096C3433B5224DAEFB96ED25209636@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Richard Barnes , "stir@ietf.org" , Russ Housley , Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 14:25:36 -0000 On Jul 11, 2013, at 10:37 PM, Hadriel Kaplan wr= ote: >=20 > On Jul 11, 2013, at 10:21 AM, Russ Housley wrote: >=20 >> Initially, the working group will specify an in-band mechanism to authen= ticate the originator of a SIP session where the identity being authenticat= ed is a telephone number and the session is established with SIP end to end= . The working group will consider choices for protecting the identity info= rmation and the credentials used, but will likely be similar to the methods= described in RFC 4474, which employs a signature over a set of information= in the SIP headers using a credential assigned to the identity. In order = to be authoritative, credentials used with this mechanism will be derived f= rom existing telephone number assignment and delegation models. That is, w= hen a telephone number or range of telephone numbers is delegated to an ent= ity, a credential will accompany such delegation. =20 >=20 > This is a bit of a nitpick, but the solution does not have to accompany a= delegation with credentials. It could, for example, instead accompany a d= elegation with access rights to the same or another database to upload a pu= blic-key for the delegated number. Or it could even divorce the process of= number delegation from STIR altogether - for example we could rely on exis= ting number-lookup databases providing a SPID of the delegated-to carrier, = and use a separate web-pki model for certificate signing of SPIDs (instead = of directly relating the signing to indicate authority of numbers). Okay, but please send text. "Accompany" was meant to not imply all of thos= e. We deliberately stayed away from mentioning how any one got the credent= ial, what kind of databases existed, etc, just that there was a credential = that mirrored the delegation which was used to sign and verify. >=20 >=20 >> The mechanism must allow parties who are not delegated a telephone numbe= r, but are preauthorized by the entity who is delegated the number, to plac= e calls using the identity. Expansion of the >> authentication mechanism to identities using the user@domain form should= be considered in the initial design. After completing the SIP end to end = solution, the working group will consider session establishment where there= are one or more non-SIP hops, most likely using an out-of-band authenticat= ion mechanism. However, the in-band and out-of-band mechanisms should shar= e as much in common as possible, especially the credentials. >>=20 >> The working group will coordinate with the Security Area on credential m= anagement. >>=20 >> The working group will coordinate with other working groups in the RAI A= rea regarding signaling through existing deployments, including INSIPID. >=20 > I think you mean "STRAW", not INSIPID. Or maybe you mean both STRAW and = INSIPID. It is not at all clear we can or should use the INSIPID WG's outp= ut, for example. I was thinking INSIPID because I thought we agreed early on that the INSIPI= D ID was what we wanted for a call id to prevent replay. I don't have a p= roblem with STRAW and INSIPID if you think STRAW coordination would be bene= ficial. >=20 >=20 > [snip] >> The working group will deliver the following: >>=20 >> - A problem statement detailing the deployment environment and >> situation that motivate work on secure telephone identity >>=20 >> - A mechanism document describing the SIP end-to-end with telephone >> number-based identities=20 >>=20 >> - A document describing the credentials required to support secure >> telephone identity >>=20 >> - A fallback mechanism to allow out-of-band identity establishment >> during call setup >=20 > In other text of this charter it only says we will likely use an out-of-b= and solution. But here it has a deliverable and below it has a milestone f= or an out-of-band mechanism. Was this intentional or just legacy wording f= rom previous charter versions? Legacy cut/paste problem, we will reword. From dhc@dcrocker.net Fri Jul 12 07:33: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 41FCC21E8053 for ; Fri, 12 Jul 2013 07:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: 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-SMUTKh462X for ; Fri, 12 Jul 2013 07:33:23 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 55CAC21E808A for ; Fri, 12 Jul 2013 07:33: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 r6CEX8o2001651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 Jul 2013 07:33:11 -0700 Message-ID: <51E01389.7090509@dcrocker.net> Date: Fri, 12 Jul 2013 07:32:41 -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: Stephen Farrell References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> In-Reply-To: <51DFDB57.1040809@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]); Fri, 12 Jul 2013 07:33:11 -0700 (PDT) Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] Draft STIR 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: Fri, 12 Jul 2013 14:33:23 -0000 On 7/12/2013 3:32 AM, Stephen Farrell wrote: >> So, Stephen, unless someone can come up with some wording that works, >> >I'd prefer to defer the discussion to the work group (if/when we get >> >one), rather than do it in charter language. > Given the amount of discussion this caused (sorry for that:-), I > agree. In fact the amount of discussion suggests that this is enough of an issue to be worth calling out the issue explicitly in the charter. Perhaps adding something like: The mechanism will use a canonical form of telephone number, based on the contents of the SIP From field. The working group will specify the details of the form, as well as any mapping that might be needed between the From field and the canonical form. -- Dave Crocker Brandenburg InternetWorking bbiw.net From brian.rosen@neustar.biz Fri Jul 12 07:39: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 DE73011E810C for ; Fri, 12 Jul 2013 07:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPH0rLsV-RFZ for ; Fri, 12 Jul 2013 07:39:40 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id D8BB111E80FE for ; Fri, 12 Jul 2013 07:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1373639935; x=1688999801; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=ftU4EqDCHu ZuT4T0lvbt1WlEOXlXpKoQkMI05+FSAUE=; b=WALn2pQ0JsLuNav6KquGb7JCWf e5za6DdcdSGkEmvcVQwY6S7JpVBie53Gso9kusTKXswNvg/0/9xvEHMmmXkw== Received: from ([10.31.58.69]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.22249212; Fri, 12 Jul 2013 10:38:53 -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, 12 Jul 2013 10:39:25 -0400 From: "Rosen, Brian" To: "" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkH7PavsqszcIEumRBC5KQ07J5lgBgeAgAAEgICAAANvAIAAAaEAgAAGyYCAAAH6AIAABkaAgAACpACAAA3sAIAAAhCAgADroICAAEL+gIAAAd4A Date: Fri, 12 Jul 2013 14:39:24 +0000 Message-ID: <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> In-Reply-To: <51E01389.7090509@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.192.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: Z+ReEhI1ISNcKEuWjR4ZWw== Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6C6BB31DE317804FAAD5AEA15760A36E@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Stephen Farrell Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 14:39:44 -0000 I don't have a problem with that concept. There is the difficulty that we may have to deal with PAI instead of From i= n some cases. We may even need to send the number in some other new header= , although I hope we don't have to. We haven't settled that issue yet. =20 The mechanism will likely also use the destination TN, which has the same i= ssue. =20 I edited the text to remove references to specific headers. We could have= "The mechanism will use a canonical form of telephone number, based on the= contents of the SIP header fields. The working group will specify the deta= ils of the form, as well as any mapping that might be needed between the he= ader fields and the canonical form." On Jul 12, 2013, at 10:32 AM, Dave Crocker wrote: > On 7/12/2013 3:32 AM, Stephen Farrell wrote: >>> So, Stephen, unless someone can come up with some wording that works, >>> >I'd prefer to defer the discussion to the work group (if/when we get >>> >one), rather than do it in charter language. >> Given the amount of discussion this caused (sorry for that:-), I >> agree. >=20 >=20 > In fact the amount of discussion suggests that this is enough of an issue= to be worth calling out the issue explicitly in the charter. >=20 > Perhaps adding something like: >=20 > The mechanism will use a canonical form of telephone number, based on t= he contents of the SIP From field. The working group will specify the detai= ls of the form, as well as any mapping that might be needed between the Fro= m field and the canonical form. >=20 >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net From philippe.fouquart@orange.com Fri Jul 12 07: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 0256221F99A6 for ; Fri, 12 Jul 2013 07:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.260, 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 awA+F3ptQoZe for ; Fri, 12 Jul 2013 07:28: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 4862321F9929 for ; Fri, 12 Jul 2013 07:28:47 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 9EC902DCBEB; Fri, 12 Jul 2013 16:28:46 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 4738527C05B; Fri, 12 Jul 2013 16:28:46 +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, 12 Jul 2013 16:28:45 +0200 From: To: "Rosen, Brian" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIC/Xfx9OM2CUaqk2gsBTAQDJlfoXKAgAAEgQCAAANtAIAAAaIAgAAGyICAAAH7AIAABkaAgAACpACAAA3sAIAAAhCAgAFGPhD//+RFAIAAIfGg Date: Fri, 12 Jul 2013 14:28:44 +0000 Message-ID: <3599_1373639326_51E0129E_3599_2310_1_B5939C6860701C49AA39C5DA5189448B0B4167@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <3599_1373638407_51E00F07_3599_1118_1_B5939C6860701C49AA39C5DA5189448B0B4135@PEXCVZYM12.corporate.adroot.infra.ftgroup> <9B2F33E0-E9DA-497C-8878-A251C2555D00@neustar.biz> In-Reply-To: <9B2F33E0-E9DA-497C-8878-A251C2555D00@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.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.12.134831 X-Mailman-Approved-At: Fri, 12 Jul 2013 07:41:02 -0700 Cc: "Peterson, Jon" , "rlb@ipv.sx" , "housley@vigilsec.com" , "Gonzalo.Camarillo@ericsson.com" , "stir@ietf.org" , "Henning.Schulzrinne@fcc.gov" , Michael Hammer , "timothy.dwight@verizon.com" , "stephen.farrell@cs.tcd.ie" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 14:28:52 -0000 AFAIAC, what matters is a) uniqueness and/therefore b) the fact that it is = published as an "E.164 number" by entity that manages the CC so the appropr= iate term should be "international E.164 number" as defined by the recommen= dation for reasons pointed out by others. Whether one number is reachable o= r only partially reachable doesn't really matter that much.=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: Friday, July 12, 2013 4:18 PM To: FOUQUART Philippe OLNC/OLN Cc: Peterson, Jon; rlb@ipv.sx; housley@vigilsec.com; Gonzalo.Camarillo@eric= sson.com; stir@ietf.org; stephen.farrell@cs.tcd.ie; Michael Hammer; timothy= .dwight@verizon.com; Henning.Schulzrinne@fcc.gov Subject: Re: [stir] Draft STIR Charter Can we conclude this discussion by leaving the text alone, so it refers to = vague "telephone numbers" and not even try to define them further? Brian On Jul 12, 2013, at 10:13 AM, wrote: > Regarding tool free and the like, I would agree to defer this to a WG dis= cussion. I think we're now confusing reachability (which a relative concept= even in the so called _P_STN) and uniqueness. There are lots of E.164 numb= ers that are not globally reachable.=20=20 >=20 > Whether this applies only to geographic country codes or to any E.164 cou= ntry codes is an interesting question. All I've read so far most applies to= geographic country codes,... well, groups of countries in fact, mmmh... +1= actually :) >=20 > Re. national only numbers, I'd prefer dealing with this at a later stage.= (I'm not even sure it calls for a significantly different solution, other = than the URI format, that is)=20=20 >=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: Thursday, July 11, 2013 10:30 PM > To: Peterson, Jon > Cc: rlb@ipv.sx; housley@vigilsec.com; Gonzalo.Camarillo@ericsson.com; sti= r@ietf.org; Henning.Schulzrinne@fcc.gov; Michael Hammer; timothy.dwight@ver= izon.com; stephen.farrell@cs.tcd.ie > Subject: Re: [stir] Draft STIR Charter >=20 > Yeah, well, let's talk about that, because you are right. >=20 > It really would be a good idea to be able to get a call which had a calle= d party number of 9-1-1 or 1-1-2 and was verifiably from that number. >=20 > We certainly want to be able to handle "toll free" numbers, which in many= cases are not actually e.164s, even though they look like them. >=20 > The problem is that while the latter is usually easy to handle, because e= ven if 18005551212 is not truly an e.164, we certainly could canonicalize t= hem as if they were and everything would work, doing that with 1-1-2 is ano= ther story. >=20 > Probably not worth dealing with these issues in charter language. >=20 > So, Stephen, unless someone can come up with some wording that works, I'd= prefer to defer the discussion to the work group (if/when we get one), rat= her than do it in charter language. >=20 > Brian >=20 > On Jul 11, 2013, at 4:22 PM, "Peterson, Jon" > wrote: >=20 >>=20 >> My understanding was that certain nationally-specific numbers, such as >> freephone numbers, actually don't fall under the E.164 plan, and that th= us >> restricting this to "E.164 numbers" may rule out some numbers we probably >> want to provide identity for. These numbers have the quality that they >> aren't reachable internationally. No? >>=20 >> Jon Peterson >> Neustar, Inc. >>=20 >> On 7/11/13 12:32 PM, "Michael Hammer" wro= te: >>=20 >>> Tim, >>>=20 >>> The national specific part is a sub-component of the complete E.164 >>> number. >>>=20 >>> You wouldn't call a car complete if you took the engine out. :) >>>=20 >>> Mike >>>=20 >>>=20 >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >>> Dwight, Timothy M (Tim) >>> Sent: Thursday, July 11, 2013 3:23 PM >>> To: Henning Schulzrinne; 'Stephen Farrell'; Rosen, Brian >>> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >>> Subject: Re: [stir] Draft STIR Charter >>>=20 >>> Henning, >>>=20 >>> I think what you describe is what Rec. E.164 calls an International E.1= 64 >>> number. It also discusses National (Significant) Numbers, which are the >>> International E.164 number minus the Country Code. >>>=20 >>> tim >>>=20 >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >>> Henning Schulzrinne >>> Sent: Thursday, July 11, 2013 2:00 PM >>> To: 'Stephen Farrell'; Rosen, Brian >>> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >>> Subject: Re: [stir] Draft STIR Charter >>>=20 >>> E.164 implies full phone number. >>>=20 >>> From E.164, Section 6.2: >>>=20 >>> The international ITU-T E.164-number is composed of a variable number of >>> decimal digits arranged in specific code fields. The international ITU-T >>> E.164-number code fields are the country code (CC) and remaining fields >>> are >>> specific to the use being made of the international ITU-T E.164 number = as >>> shown in Figures 1 to 5. >>> A numbering plan does not include prefixes, suffixes, and additional >>> information required to complete a call. >>>=20 >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >>> Stephen Farrell >>> Sent: Thursday, July 11, 2013 2:53 PM >>> To: Rosen, Brian >>> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >>> Subject: Re: [stir] Draft STIR Charter >>>=20 >>>=20 >>>=20 >>> On 07/11/2013 07:29 PM, Rosen, Brian wrote: >>>> So maybe where we say "where the identity being authenticated is a >>>> telephone number" add "in e.164 format"? >>>=20 >>> Better all right. Some people were saying "full e.164" which I guess me= ans >>> including country code and a +, which'd be even better, if its not alre= ady >>> implied in e.164. >>>=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 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > 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 brian.rosen@neustar.biz Fri Jul 12 07:35: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 C7BBF21F9D18 for ; Fri, 12 Jul 2013 07:35:03 -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 tH9ic7K8RIYy for ; Fri, 12 Jul 2013 07:34:59 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 93FD821E804D for ; Fri, 12 Jul 2013 07:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1373639656; x=1688995992; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=eIJZjwCjGm yuz3RfStxsaec9ES4TISpbtuFW0Q9tFhM=; b=fGyvIBTu7imrOhBjXmp8+rTskk jjIWZyJ/JL42B1G6P5PAcdmGv9gFMp4R38WCQy4lPdKw+p4tKehjG0UDm1aA== Received: from ([10.31.58.69]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.22248996; Fri, 12 Jul 2013 10:34: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; Fri, 12 Jul 2013 10:34:41 -0400 From: "Rosen, Brian" To: " " Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkH7PavsqszcIEumRBC5KQ07J5lgBgeAgAAEgICAAANvAIAAAaEAgAAGyYCAAAH6AIAABkaAgAACpACAAA3sAIAAAhCAgAEpPQCAAAFFgIAAAwEAgAABqQA= Date: Fri, 12 Jul 2013 14:34:40 +0000 Message-ID: References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <3599_1373638407_51E00F07_3599_1118_1_B5939C6860701C49AA39C5DA5189448B0B4135@PEXCVZYM12.corporate.adroot.infra.ftgroup> <9B2F33E0-E9DA-497C-8878-A251C2555D00@neustar.biz> <3599_1373639326_51E0129E_3599_2310_1_B5939C6860701C49AA39C5DA5189448B0B4167@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <3599_1373639326_51E0129E_3599_2310_1_B5939C6860701C49AA39C5DA5189448B0B4167@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.192.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 8HkTqMEgRYj+NwFH20xWpg== Content-Type: text/plain; charset="us-ascii" Content-ID: <482AA3F40CB16243A98CCDE5D8649C75@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 12 Jul 2013 07:41:02 -0700 Cc: "Peterson, Jon" , "rlb@ipv.sx" , "housley@vigilsec.com" , "Gonzalo.Camarillo@ericsson.com" , "stir@ietf.org" , "Henning.Schulzrinne@fcc.gov" , Michael Hammer , "timothy.dwight@verizon.com" , "stephen.farrell@cs.tcd.ie" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 14:35:03 -0000 Philippe The problem with using international E.164 number wording in the charter is= that we would like to be able to verify numbers that are not International= E.164 numbers. One example we use is national toll free numbers, which in= some cases are not international E.164 numbers. The other example I used = is a service number like 1-1-2. Those may be valid, desirable called party= numbers which we would like to be able to send and verify using the mechan= isms to be defined in this work. We would therefore like less restrictive = wording that would permit us to cover these cases. When we write standards= documents, we will have to use more words, more defined terms and cover mu= ltiple cases explicitly. I don't think that complexity would help in the c= harter language, so I am suggesting we keep the current "telephone number" = text. Brian On Jul 12, 2013, at 10:28 AM, wrote: > AFAIAC, what matters is a) uniqueness and/therefore b) the fact that it i= s published as an "E.164 number" by entity that manages the CC so the appro= priate term should be "international E.164 number" as defined by the recomm= endation for reasons pointed out by others. Whether one number is reachable= or only partially reachable doesn't really matter that much.=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: Friday, July 12, 2013 4:18 PM > To: FOUQUART Philippe OLNC/OLN > Cc: Peterson, Jon; rlb@ipv.sx; housley@vigilsec.com; Gonzalo.Camarillo@er= icsson.com; stir@ietf.org; stephen.farrell@cs.tcd.ie; Michael Hammer; timot= hy.dwight@verizon.com; Henning.Schulzrinne@fcc.gov > Subject: Re: [stir] Draft STIR Charter >=20 > Can we conclude this discussion by leaving the text alone, so it refers t= o vague "telephone numbers" and not even try to define them further? >=20 > Brian >=20 > On Jul 12, 2013, at 10:13 AM, wrote: >=20 >> Regarding tool free and the like, I would agree to defer this to a WG di= scussion. I think we're now confusing reachability (which a relative concep= t even in the so called _P_STN) and uniqueness. There are lots of E.164 num= bers that are not globally reachable. =20 >>=20 >> Whether this applies only to geographic country codes or to any E.164 co= untry codes is an interesting question. All I've read so far most applies t= o geographic country codes,... well, groups of countries in fact, mmmh... += 1 actually :) >>=20 >> Re. national only numbers, I'd prefer dealing with this at a later stage= . (I'm not even sure it calls for a significantly different solution, other= than the URI format, that is) =20 >>=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: Thursday, July 11, 2013 10:30 PM >> To: Peterson, Jon >> Cc: rlb@ipv.sx; housley@vigilsec.com; Gonzalo.Camarillo@ericsson.com; st= ir@ietf.org; Henning.Schulzrinne@fcc.gov; Michael Hammer; timothy.dwight@ve= rizon.com; stephen.farrell@cs.tcd.ie >> Subject: Re: [stir] Draft STIR Charter >>=20 >> Yeah, well, let's talk about that, because you are right. >>=20 >> It really would be a good idea to be able to get a call which had a call= ed party number of 9-1-1 or 1-1-2 and was verifiably from that number. >>=20 >> We certainly want to be able to handle "toll free" numbers, which in man= y cases are not actually e.164s, even though they look like them. >>=20 >> The problem is that while the latter is usually easy to handle, because = even if 18005551212 is not truly an e.164, we certainly could canonicalize = them as if they were and everything would work, doing that with 1-1-2 is an= other story. >>=20 >> Probably not worth dealing with these issues in charter language. >>=20 >> So, Stephen, unless someone can come up with some wording that works, I'= d prefer to defer the discussion to the work group (if/when we get one), ra= ther than do it in charter language. >>=20 >> Brian >>=20 >> On Jul 11, 2013, at 4:22 PM, "Peterson, Jon" >> wrote: >>=20 >>>=20 >>> My understanding was that certain nationally-specific numbers, such as >>> freephone numbers, actually don't fall under the E.164 plan, and that t= hus >>> restricting this to "E.164 numbers" may rule out some numbers we probab= ly >>> want to provide identity for. These numbers have the quality that they >>> aren't reachable internationally. No? >>>=20 >>> Jon Peterson >>> Neustar, Inc. >>>=20 >>> On 7/11/13 12:32 PM, "Michael Hammer" wr= ote: >>>=20 >>>> Tim, >>>>=20 >>>> The national specific part is a sub-component of the complete E.164 >>>> number. >>>>=20 >>>> You wouldn't call a car complete if you took the engine out. :) >>>>=20 >>>> Mike >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf O= f >>>> Dwight, Timothy M (Tim) >>>> Sent: Thursday, July 11, 2013 3:23 PM >>>> To: Henning Schulzrinne; 'Stephen Farrell'; Rosen, Brian >>>> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >>>> Subject: Re: [stir] Draft STIR Charter >>>>=20 >>>> Henning, >>>>=20 >>>> I think what you describe is what Rec. E.164 calls an International E.= 164 >>>> number. It also discusses National (Significant) Numbers, which are t= he >>>> International E.164 number minus the Country Code. >>>>=20 >>>> tim >>>>=20 >>>> -----Original Message----- >>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf O= f >>>> Henning Schulzrinne >>>> Sent: Thursday, July 11, 2013 2:00 PM >>>> To: 'Stephen Farrell'; Rosen, Brian >>>> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >>>> Subject: Re: [stir] Draft STIR Charter >>>>=20 >>>> E.164 implies full phone number. >>>>=20 >>>> From E.164, Section 6.2: >>>>=20 >>>> The international ITU-T E.164-number is composed of a variable number = of >>>> decimal digits arranged in specific code fields. The international ITU= -T >>>> E.164-number code fields are the country code (CC) and remaining field= s >>>> are >>>> specific to the use being made of the international ITU-T E.164 number= as >>>> shown in Figures 1 to 5. >>>> A numbering plan does not include prefixes, suffixes, and additional >>>> information required to complete a call. >>>>=20 >>>> -----Original Message----- >>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf O= f >>>> Stephen Farrell >>>> Sent: Thursday, July 11, 2013 2:53 PM >>>> To: Rosen, Brian >>>> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >>>> Subject: Re: [stir] Draft STIR Charter >>>>=20 >>>>=20 >>>>=20 >>>> On 07/11/2013 07:29 PM, Rosen, Brian wrote: >>>>> So maybe where we say "where the identity being authenticated is a >>>>> telephone number" add "in e.164 format"? >>>>=20 >>>> Better all right. Some people were saying "full e.164" which I guess m= eans >>>> including country code and a +, which'd be even better, if its not alr= eady >>>> implied in e.164. >>>>=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 >>=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 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, >> 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, Orange is not liable for messages that have be= en 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, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 From philippe.fouquart@orange.com Fri Jul 12 07:43: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 2584F21F9BF7 for ; Fri, 12 Jul 2013 07:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, 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 G+WAsmR5fInf for ; Fri, 12 Jul 2013 07:43:30 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 6910521F9BFF for ; Fri, 12 Jul 2013 07:43:29 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 80038324B0D; Fri, 12 Jul 2013 16:43:28 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 5B1E1238056; Fri, 12 Jul 2013 16:43:25 +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, 12 Jul 2013 16:43:24 +0200 From: To: "Rosen, Brian" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIC/Xfx9OM2CUaqk2gsBTAQDJlgBgeAgAAEgICAAANvAIAAAaEAgAAGyYCAAAH6AIAABkaAgAACpACAAA3sAIAAAhCAgAEpPQCAAAFFgIAAAwEAgAABqQD//71tkA== Date: Fri, 12 Jul 2013 14:43:24 +0000 Message-ID: <23576_1373640205_51E0160D_23576_39_1_B5939C6860701C49AA39C5DA5189448B0B419D@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <3599_1373638407_51E00F07_3599_1118_1_B5939C6860701C49AA39C5DA5189448B0B4135@PEXCVZYM12.corporate.adroot.infra.ftgroup> <9B2F33E0-E9DA-497C-8878-A251C2555D00@neustar.biz> <3599_1373639326_51E0129E_3599_2310_1_B5939C6860701C49AA39C5DA5189448B0B4167@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.2] 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: "rlb@ipv.sx" , "stir@ietf.org" , "housley@vigilsec.com" , "Gonzalo.Camarillo@ericsson.com" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 14:43:34 -0000 Brian, My apologies, I thought the intent was not to cover short codes and the lik= e in the charter and address that at a later stage possible with some recha= rtering. If people prefer some flexibility in the first place, I'm fine wit= h using that generic term (as I said I might be wrong but I don't think the= solution would be much different other than the format in which the number= is conveyed)=20 Regards,=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: Friday, July 12, 2013 4:35 PM To: FOUQUART Philippe OLNC/OLN Cc: Peterson, Jon; rlb@ipv.sx; housley@vigilsec.com; Gonzalo.Camarillo@eric= sson.com; stir@ietf.org; stephen.farrell@cs.tcd.ie; Michael Hammer; timothy= .dwight@verizon.com; Henning.Schulzrinne@fcc.gov Subject: Re: [stir] Draft STIR Charter Philippe The problem with using international E.164 number wording in the charter is= that we would like to be able to verify numbers that are not International= E.164 numbers. One example we use is national toll free numbers, which in= some cases are not international E.164 numbers. The other example I used = is a service number like 1-1-2. Those may be valid, desirable called party= numbers which we would like to be able to send and verify using the mechan= isms to be defined in this work. We would therefore like less restrictive = wording that would permit us to cover these cases. When we write standards= documents, we will have to use more words, more defined terms and cover mu= ltiple cases explicitly. I don't think that complexity would help in the c= harter language, so I am suggesting we keep the current "telephone number" = text. Brian On Jul 12, 2013, at 10:28 AM, wrote: > AFAIAC, what matters is a) uniqueness and/therefore b) the fact that it i= s published as an "E.164 number" by entity that manages the CC so the appro= priate term should be "international E.164 number" as defined by the recomm= endation for reasons pointed out by others. Whether one number is reachable= or only partially reachable doesn't really matter that much.=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: Friday, July 12, 2013 4:18 PM > To: FOUQUART Philippe OLNC/OLN > Cc: Peterson, Jon; rlb@ipv.sx; housley@vigilsec.com; Gonzalo.Camarillo@er= icsson.com; stir@ietf.org; stephen.farrell@cs.tcd.ie; Michael Hammer; timot= hy.dwight@verizon.com; Henning.Schulzrinne@fcc.gov > Subject: Re: [stir] Draft STIR Charter >=20 > Can we conclude this discussion by leaving the text alone, so it refers t= o vague "telephone numbers" and not even try to define them further? >=20 > Brian >=20 > On Jul 12, 2013, at 10:13 AM, wrote: >=20 >> Regarding tool free and the like, I would agree to defer this to a WG di= scussion. I think we're now confusing reachability (which a relative concep= t even in the so called _P_STN) and uniqueness. There are lots of E.164 num= bers that are not globally reachable.=20=20 >>=20 >> Whether this applies only to geographic country codes or to any E.164 co= untry codes is an interesting question. All I've read so far most applies t= o geographic country codes,... well, groups of countries in fact, mmmh... += 1 actually :) >>=20 >> Re. national only numbers, I'd prefer dealing with this at a later stage= . (I'm not even sure it calls for a significantly different solution, other= than the URI format, that is)=20=20 >>=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: Thursday, July 11, 2013 10:30 PM >> To: Peterson, Jon >> Cc: rlb@ipv.sx; housley@vigilsec.com; Gonzalo.Camarillo@ericsson.com; st= ir@ietf.org; Henning.Schulzrinne@fcc.gov; Michael Hammer; timothy.dwight@ve= rizon.com; stephen.farrell@cs.tcd.ie >> Subject: Re: [stir] Draft STIR Charter >>=20 >> Yeah, well, let's talk about that, because you are right. >>=20 >> It really would be a good idea to be able to get a call which had a call= ed party number of 9-1-1 or 1-1-2 and was verifiably from that number. >>=20 >> We certainly want to be able to handle "toll free" numbers, which in man= y cases are not actually e.164s, even though they look like them. >>=20 >> The problem is that while the latter is usually easy to handle, because = even if 18005551212 is not truly an e.164, we certainly could canonicalize = them as if they were and everything would work, doing that with 1-1-2 is an= other story. >>=20 >> Probably not worth dealing with these issues in charter language. >>=20 >> So, Stephen, unless someone can come up with some wording that works, I'= d prefer to defer the discussion to the work group (if/when we get one), ra= ther than do it in charter language. >>=20 >> Brian >>=20 >> On Jul 11, 2013, at 4:22 PM, "Peterson, Jon" >> wrote: >>=20 >>>=20 >>> My understanding was that certain nationally-specific numbers, such as >>> freephone numbers, actually don't fall under the E.164 plan, and that t= hus >>> restricting this to "E.164 numbers" may rule out some numbers we probab= ly >>> want to provide identity for. These numbers have the quality that they >>> aren't reachable internationally. No? >>>=20 >>> Jon Peterson >>> Neustar, Inc. >>>=20 >>> On 7/11/13 12:32 PM, "Michael Hammer" wr= ote: >>>=20 >>>> Tim, >>>>=20 >>>> The national specific part is a sub-component of the complete E.164 >>>> number. >>>>=20 >>>> You wouldn't call a car complete if you took the engine out. :) >>>>=20 >>>> Mike >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >>>> Dwight, Timothy M (Tim) >>>> Sent: Thursday, July 11, 2013 3:23 PM >>>> To: Henning Schulzrinne; 'Stephen Farrell'; Rosen, Brian >>>> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >>>> Subject: Re: [stir] Draft STIR Charter >>>>=20 >>>> Henning, >>>>=20 >>>> I think what you describe is what Rec. E.164 calls an International E.= 164 >>>> number. It also discusses National (Significant) Numbers, which are t= he >>>> International E.164 number minus the Country Code. >>>>=20 >>>> tim >>>>=20 >>>> -----Original Message----- >>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >>>> Henning Schulzrinne >>>> Sent: Thursday, July 11, 2013 2:00 PM >>>> To: 'Stephen Farrell'; Rosen, Brian >>>> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >>>> Subject: Re: [stir] Draft STIR Charter >>>>=20 >>>> E.164 implies full phone number. >>>>=20 >>>> From E.164, Section 6.2: >>>>=20 >>>> The international ITU-T E.164-number is composed of a variable number = of >>>> decimal digits arranged in specific code fields. The international ITU= -T >>>> E.164-number code fields are the country code (CC) and remaining fields >>>> are >>>> specific to the use being made of the international ITU-T E.164 number= as >>>> shown in Figures 1 to 5. >>>> A numbering plan does not include prefixes, suffixes, and additional >>>> information required to complete a call. >>>>=20 >>>> -----Original Message----- >>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >>>> Stephen Farrell >>>> Sent: Thursday, July 11, 2013 2:53 PM >>>> To: Rosen, Brian >>>> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >>>> Subject: Re: [stir] Draft STIR Charter >>>>=20 >>>>=20 >>>>=20 >>>> On 07/11/2013 07:29 PM, Rosen, Brian wrote: >>>>> So maybe where we say "where the identity being authenticated is a >>>>> telephone number" add "in e.164 format"? >>>>=20 >>>> Better all right. Some people were saying "full e.164" which I guess m= eans >>>> including country code and a +, which'd be even better, if its not alr= eady >>>> implied in e.164. >>>>=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 >>=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 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, >> 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, Orange is not liable for messages that have be= en 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, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From dhc@dcrocker.net Fri Jul 12 07:47: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 0038711E80FE for ; Fri, 12 Jul 2013 07:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcRjDkW4JNZj for ; Fri, 12 Jul 2013 07:47:31 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0871021E805E for ; Fri, 12 Jul 2013 07:47:31 -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 r6CElPFi001915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 Jul 2013 07:47:28 -0700 Message-ID: <51E016E1.3070600@dcrocker.net> Date: Fri, 12 Jul 2013 07:46:57 -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: "Rosen, Brian" References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> In-Reply-To: <30295148-F294-468C-A12A-1DD4ADEAC197@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, 12 Jul 2013 07:47:28 -0700 (PDT) Cc: "stir@ietf.org" , Stephen Farrell Subject: Re: [stir] Draft STIR 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: Fri, 12 Jul 2013 14:47:36 -0000 On 7/12/2013 7:39 AM, Rosen, Brian wrote: > I edited the text to remove references to specific headers. We could have "The mechanism will use a canonical form of telephone number, based on the contents of the SIP header fields. The working group will specify the details of the form, as well as any mapping that might be needed between the header fields and the canonical form." As charter text, that works for me. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From philippe.fouquart@orange.com Fri Jul 12 08:06: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 B29B221F9476 for ; Fri, 12 Jul 2013 08:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.186, 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 pMW9E8BGaESg for ; Fri, 12 Jul 2013 08:06: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 E44FD21F9D21 for ; Fri, 12 Jul 2013 08:06:44 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id E62652DC373; Fri, 12 Jul 2013 17:06:42 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id C0BE14C063; Fri, 12 Jul 2013 17:06:42 +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, 12 Jul 2013 17:06:42 +0200 From: To: "Dwight, Timothy M (Tim)" Thread-Topic: Terminolgy (was: RE: [stir] Draft STIR Charter) Thread-Index: AQHOfxFqMRcw/nYooUmwCCxNc1rypA== Date: Fri, 12 Jul 2013 15:06:41 +0000 Message-ID: <22484_1373641602_51E01B82_22484_1178_1_B5939C6860701C49AA39C5DA5189448B0B41BE@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <51DEF814.9080704@cs.tcd.ie> <66490626-323F-46DF-8D22-D1677C17FE76@neustar.biz> <51DEFF23.20002@cs.tcd.ie> <2B0F677F0B95454297753F58D4A07FA3012938CE59@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC143E4@EX2K10MB1.corp.yaanatech.com> <2B0F677F0B95454297753F58D4A07FA3012938CF79@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3012938CF79@FHDP1LUMXC7V31.us.one.verizon.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.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.28.101520 Cc: "rlb@ipv.sx" , "stir@ietf.org" , "housley@vigilsec.com" , "Gonzalo.Camarillo@ericsson.com" Subject: [stir] Terminolgy (was: RE: Draft STIR Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 15:06:50 -0000 Tim,=20 I think I see what you mean, but that's not what you wrote :): actually, th= e (N)SN is not what you _dial_ for national calls for most dialling plans o= n the planet because a large number of them use a "National (trunk) prefix"= , eg the 'recommended' 0). As you pointed out the N(S)N is just the [full] = international E.164 number without the CC.=20 Generally speaking, for such terms, people can just look up http://www.itu.= int/rec/T-REC-E.164-201011-I.=20=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 Dwi= ght, Timothy M (Tim) Sent: Thursday, July 11, 2013 10:52 PM To: Michael Hammer; Henning.Schulzrinne@fcc.gov; stephen.farrell@cs.tcd.ie;= Brian.Rosen@neustar.biz Cc: rlb@ipv.sx; stir@ietf.org; housley@vigilsec.com; Gonzalo.Camarillo@eric= sson.com Subject: Re: [stir] Draft STIR Charter The national (significant) part is what you dial any time you're calling a = number in your own country code. Which is for most of us the normal case. = Therefore the national (significant) part is the thing most closely associ= ated with "telephone number". Only if you specify "International" format, = is it clear that you meant for the country code to be included. The car analogy brings back a college course in philosophy, in which I reca= ll spending a session trying to define whether there was some essential not= ion of "chairness" possessed by all chairs. I'll happily refrain from goin= g down that path again :-). tim -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20 Sent: Thursday, July 11, 2013 2:32 PM To: Dwight, Timothy M (Tim); Henning.Schulzrinne@fcc.gov; stephen.farrell@c= s.tcd.ie; Brian.Rosen@neustar.biz Cc: rlb@ipv.sx; stir@ietf.org; housley@vigilsec.com; Gonzalo.Camarillo@eric= sson.com Subject: RE: [stir] Draft STIR Charter Tim, The national specific part is a sub-component of the complete E.164 number. You wouldn't call a car complete if you took the engine out. :) Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dwight, Timothy M (Tim) Sent: Thursday, July 11, 2013 3:23 PM To: Henning Schulzrinne; 'Stephen Farrell'; Rosen, Brian Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter Henning, I think what you describe is what Rec. E.164 calls an International E.164 number. It also discusses National (Significant) Numbers, which are the International E.164 number minus the Country Code. tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Thursday, July 11, 2013 2:00 PM To: 'Stephen Farrell'; Rosen, Brian Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter E.164 implies full phone number. >From E.164, Section 6.2: The international ITU-T E.164-number is composed of a variable number of decimal digits arranged in specific code fields. The international ITU-T E.164-number code fields are the country code (CC) and remaining fields are specific to the use being made of the international ITU-T E.164 number as shown in Figures 1 to 5. A numbering plan does not include prefixes, suffixes, and additional information required to complete a call. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: Thursday, July 11, 2013 2:53 PM To: Rosen, Brian Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter On 07/11/2013 07:29 PM, Rosen, Brian wrote: > So maybe where we say "where the identity being authenticated is a=20 > telephone number" add "in e.164 format"? Better all right. Some people were saying "full e.164" which I guess means including country code and a +, which'd be even better, if its not already implied in e.164. _______________________________________________ stir mailing 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 ___________________________________________________________________________= ______________________________________________ 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 pkyzivat@alum.mit.edu Fri Jul 12 08:28: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 4057021F9BB9 for ; Fri, 12 Jul 2013 08:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.154 X-Spam-Level: X-Spam-Status: No, score=-0.154 tagged_above=-999 required=5 tests=[AWL=0.283, 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 IA51RTg7Fwkr for ; Fri, 12 Jul 2013 08:28:09 -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 4C40C11E8126 for ; Fri, 12 Jul 2013 08:27:59 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta01.westchester.pa.mail.comcast.net with comcast id zP4W1l0031ZXKqc51TTylL; Fri, 12 Jul 2013 15:27:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id zTTy1l00E3ZTu2S3hTTyyW; Fri, 12 Jul 2013 15:27:58 +0000 Message-ID: <51E0207C.2000203@alum.mit.edu> Date: Fri, 12 Jul 2013 11:27:56 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: stir@ietf.org References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <12FF2857-14B4-4C7E-A1FD-BE89EFC01189@neustar.biz> In-Reply-To: <12FF2857-14B4-4C7E-A1FD-BE89EFC01189@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=1373642878; bh=PpZwv+2Rdk0F/7fCASQ2ULAQTqdqUW7hiqCydWWZd2E=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=m3u5ppgzN531Yp7r7jRovu08jOxVH6cXYYl4KQNF1hcNJI+V9g8lUae34KXviFovD TVc11xa94CQ1ZkALSeHywdIWQw0l3RR7aTjoQX/N8jBxOuiB2EgJgIuxDiBgciYxoK QrU4LaVu6c54Kpg25hHQti2wcJv7TpuCwi/QnDDji1Vy8deL7Rw9HyPhPJHdBo9Xtb JCJfNKByZEBQGDeatkckeJ+5VnBaXt8CSYV35/p7kkCMHA6sF8695JA2CeJN4rVp4E nOQ2tthCQQrkxTlKV7AL/cRr2h3h35NbQ19SFO9ydPxXuXg0QORZtfyj3LdOa501+H J0eO6nqRXAmbQ== Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 15:28:20 -0000 On 7/12/13 10:25 AM, Rosen, Brian wrote: > >> I think you mean "STRAW", not INSIPID. Or maybe you mean both STRAW and INSIPID. It is not at all clear we can or should use the INSIPID WG's output, for example. > I was thinking INSIPID because I thought we agreed early on that the INSIPID ID was what we wanted for a call id to prevent replay. I don't have a problem with STRAW and INSIPID if you think STRAW coordination would be beneficial. As its shaping up, the INSIPID ID isn't known if full to the caller until a response is received. So it will be a problem to use that ID (in full) to generate a signature in the initial request. But maybe the caller's half of the id would be sufficient for the purpose. But it doesn't hurt to have such a loose reference to INSIPID. Thanks, Paul From hadriel.kaplan@oracle.com Fri Jul 12 08:44: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 8387021F9AD6 for ; Fri, 12 Jul 2013 08:44:43 -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.596, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avodWRUqfH74 for ; Fri, 12 Jul 2013 08:44:38 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 048B421F9307 for ; Fri, 12 Jul 2013 08:44:37 -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 r6CFiZjN021182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 12 Jul 2013 15:44:36 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 r6CFiYtr023369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jul 2013 15:44:35 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 r6CFiY2p001431; Fri, 12 Jul 2013 15:44:34 GMT Received: from [10.235.136.197] (/174.254.177.218) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 12 Jul 2013 08:44:34 -0700 References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <12FF2857-14B4-4C7E-A1FD-BE89EFC01189@neustar.biz> <51E0207C.2000203@alum.mit.edu> Mime-Version: 1.0 (1.0) In-Reply-To: <51E0207C.2000203@alum.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B329) From: "hadriel.kaplan@oracle.com" Date: Fri, 12 Jul 2013 11:44:32 -0400 To: Paul Kyzivat X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "stir@ietf.org" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 15:44:43 -0000 As its shaping up, I have my doubts the INSIPID ID will be unchanged end-to-= end. I don't think we should rely on it for STIR whatsoever. We need to ha= ve as few dependencies as possible if we really want this thing to be deploy= ed sooner rather than later. -hadriel Sent from my iPhone On Jul 12, 2013, at 11:27 AM, Paul Kyzivat wrote: > On 7/12/13 10:25 AM, Rosen, Brian wrote: >>=20 >>> I think you mean "STRAW", not INSIPID. Or maybe you mean both STRAW and= INSIPID. It is not at all clear we can or should use the INSIPID WG's outp= ut, for example. >> I was thinking INSIPID because I thought we agreed early on that the INSI= PID ID was what we wanted for a call id to prevent replay. I don't have a p= roblem with STRAW and INSIPID if you think STRAW coordination would be benef= icial. >=20 > As its shaping up, the INSIPID ID isn't known if full to the caller until a= response is received. So it will be a problem to use that ID (in full) to g= enerate a signature in the initial request. >=20 > But maybe the caller's half of the id would be sufficient for the purpose.= >=20 > But it doesn't hurt to have such a loose reference to INSIPID. >=20 > Thanks, > Paul >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From timothy.dwight@verizon.com Fri Jul 12 08:47: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 5CE3921F9DD6 for ; Fri, 12 Jul 2013 08:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Id5HUcU9c+R2 for ; Fri, 12 Jul 2013 08:47:40 -0700 (PDT) Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) by ietfa.amsl.com (Postfix) with ESMTP id 43A0521F9DCB for ; Fri, 12 Jul 2013 08:47:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by omzsmtpe02.verizonbusiness.com with ESMTP; 12 Jul 2013 15:47:38 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.89,653,1367971200"; d="scan'208";a="507510876" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi03.verizon.com with ESMTP; 12 Jul 2013 15:47:38 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Fri, 12 Jul 2013 11:47:38 -0400 To: "Rosen, Brian" , "" Date: Fri, 12 Jul 2013 11:47:36 -0400 Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkH7PavsqszcIEumRBC5KQ07J5lgBgeAgAAEgICAAANvAIAAAaEAgAAGyYCAAAH6AIAABkaAgAACpACAAA3sAIAAAhCAgADroICAAEL+gIAAAd4A///OKxA= Message-ID: <2B0F677F0B95454297753F58D4A07FA3012938D2D9@FHDP1LUMXC7V31.us.one.verizon.com> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> In-Reply-To: <30295148-F294-468C-A12A-1DD4ADEAC197@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" , Stephen Farrell Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 15:47:45 -0000 Let's at least not make it a "charter change" to implement this mechanism t= o validate PAI. Because that's a likely deployment scenario. tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Ros= en, Brian Sent: Friday, July 12, 2013 9:39 AM To: Cc: stir@ietf.org; Stephen Farrell Subject: Re: [stir] Draft STIR Charter I don't have a problem with that concept. There is the difficulty that we may have to deal with PAI instead of From i= n some cases. We may even need to send the number in some other new header= , although I hope we don't have to. We haven't settled that issue yet. =20 The mechanism will likely also use the destination TN, which has the same i= ssue. =20 I edited the text to remove references to specific headers. We could have= "The mechanism will use a canonical form of telephone number, based on the= contents of the SIP header fields. The working group will specify the deta= ils of the form, as well as any mapping that might be needed between the he= ader fields and the canonical form." On Jul 12, 2013, at 10:32 AM, Dave Crocker wrote: > On 7/12/2013 3:32 AM, Stephen Farrell wrote: >>> So, Stephen, unless someone can come up with some wording that=20 >>> works, >>> >I'd prefer to defer the discussion to the work group (if/when we=20 >>> >get one), rather than do it in charter language. >> Given the amount of discussion this caused (sorry for that:-), I=20 >> agree. >=20 >=20 > In fact the amount of discussion suggests that this is enough of an issue= to be worth calling out the issue explicitly in the charter. >=20 > Perhaps adding something like: >=20 > The mechanism will use a canonical form of telephone number, based on t= he contents of the SIP From field. The working group will specify the detai= ls of the form, as well as any mapping that might be needed between the Fro= m field and the canonical form. >=20 >=20 > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From timothy.dwight@verizon.com Fri Jul 12 08:48: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 242AE21F9E2C for ; Fri, 12 Jul 2013 08:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 SY5k2bJNfsIU for ; Fri, 12 Jul 2013 08:48:38 -0700 (PDT) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) by ietfa.amsl.com (Postfix) with ESMTP id E966C21F9DD6 for ; Fri, 12 Jul 2013 08:48:37 -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; 12 Jul 2013 15:48:37 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.89,653,1367971200"; d="scan'208";a="507512416" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi03.verizon.com with ESMTP; 12 Jul 2013 15:48:36 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Fri, 12 Jul 2013 11:48:34 -0400 To: "dcrocker@bbiw.net" , "Rosen, Brian" Date: Fri, 12 Jul 2013 11:48:33 -0400 Thread-Topic: [stir] Draft STIR Charter Thread-Index: Ac5/DsdtUJy2GqbHRV2F5B2MH1AntQACHh+g Message-ID: <2B0F677F0B95454297753F58D4A07FA3012938D2DF@FHDP1LUMXC7V31.us.one.verizon.com> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <51E016E1.3070600@dcrocker.net> In-Reply-To: <51E016E1.3070600@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Stephen Farrell Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 15:48:43 -0000 +1 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dav= e Crocker Sent: Friday, July 12, 2013 9:47 AM To: Rosen, Brian Cc: stir@ietf.org; Stephen Farrell Subject: Re: [stir] Draft STIR Charter On 7/12/2013 7:39 AM, Rosen, Brian wrote: > I edited the text to remove references to specific headers. We could ha= ve "The mechanism will use a canonical form of telephone number, based on t= he contents of the SIP header fields. The working group will specify the de= tails of the form, as well as any mapping that might be needed between the = header fields and the canonical form." As charter text, that works for me. 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 Jul 12 08:49: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 CEA7521F9E54 for ; Fri, 12 Jul 2013 08:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiZ-rcBaHqoS for ; Fri, 12 Jul 2013 08:49:28 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id DD71D21F9E2C for ; Fri, 12 Jul 2013 08:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1373644113; x=1688999801; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=5mdDDwnBnt taVLFKZRg2yrTDYsYkopLVSJdQWgq5+SY=; b=Oz8hW34EHRmBITxcU14WSIs8Ns xEHchHcP81ZAgsHkIIgkk6UprBKqiu/H1tFlCvq9AVE0rsp0j/ixk4+nYt7Q== Received: from ([10.31.58.71]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.22253662; Fri, 12 Jul 2013 11:48: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; Fri, 12 Jul 2013 11:49:05 -0400 From: "Rosen, Brian" To: "Dwight, Timothy M (Tim)" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkH7PavsqszcIEumRBC5KQ07J5lgBgeAgAAEgICAAANvAIAAAaEAgAAGyYCAAAH6AIAABkaAgAACpACAAA3sAIAAAhCAgADroICAAEL+gIAAAd4A///OKxCAAEUvAA== Date: Fri, 12 Jul 2013 15:49:04 +0000 Message-ID: <87BE8D6A-E5F9-4025-8C3C-0A725565B13C@neustar.biz> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <2B0F677F0B95454297753F58D4A07FA3012938D2D9@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3012938D2D9@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.192.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: ZekmSaADrQR9gGdzJRD9vA== Content-Type: text/plain; charset="us-ascii" Content-ID: <6864B6C2D482CD4A8E6B9E2986739C3F@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "" , Stephen Farrell Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 15:49:31 -0000 Yes, that's why we used the term "SIP header" rather than mention any speci= fic header. Brian On Jul 12, 2013, at 11:47 AM, "Dwight, Timothy M \(Tim\)" wrote: > Let's at least not make it a "charter change" to implement this mechanism= to validate PAI. Because that's a likely deployment scenario. >=20 > tim >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of R= osen, Brian > Sent: Friday, July 12, 2013 9:39 AM > To: > Cc: stir@ietf.org; Stephen Farrell > Subject: Re: [stir] Draft STIR Charter >=20 > I don't have a problem with that concept. >=20 > There is the difficulty that we may have to deal with PAI instead of From= in some cases. We may even need to send the number in some other new head= er, although I hope we don't have to. We haven't settled that issue yet. = =20 >=20 > The mechanism will likely also use the destination TN, which has the same= issue. =20 >=20 > I edited the text to remove references to specific headers. We could ha= ve "The mechanism will use a canonical form of telephone number, based on t= he contents of the SIP header fields. The working group will specify the de= tails of the form, as well as any mapping that might be needed between the = header fields and the canonical form." >=20 >=20 > On Jul 12, 2013, at 10:32 AM, Dave Crocker > wrote: >=20 >> On 7/12/2013 3:32 AM, Stephen Farrell wrote: >>>> So, Stephen, unless someone can come up with some wording that=20 >>>> works, >>>>> I'd prefer to defer the discussion to the work group (if/when we=20 >>>>> get one), rather than do it in charter language. >>> Given the amount of discussion this caused (sorry for that:-), I=20 >>> agree. >>=20 >>=20 >> In fact the amount of discussion suggests that this is enough of an issu= e to be worth calling out the issue explicitly in the charter. >>=20 >> Perhaps adding something like: >>=20 >> The mechanism will use a canonical form of telephone number, based on t= he contents of the SIP From field. The working group will specify the detai= ls of the form, as well as any mapping that might be needed between the Fro= m field and the canonical form. >>=20 >>=20 >> -- >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From timothy.dwight@verizon.com Fri Jul 12 08:50: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 3F8AF21F9DCB for ; Fri, 12 Jul 2013 08:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 iuJ5yqDvWSjD for ; Fri, 12 Jul 2013 08:50:39 -0700 (PDT) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) by ietfa.amsl.com (Postfix) with ESMTP id 1D11021F9E1D for ; Fri, 12 Jul 2013 08:50:38 -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; 12 Jul 2013 15:50:37 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.89,653,1367971200"; d="scan'208";a="507515806" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi03.verizon.com with ESMTP; 12 Jul 2013 15:50:37 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Fri, 12 Jul 2013 11:50:36 -0400 To: "philippe.fouquart@orange.com" Date: Fri, 12 Jul 2013 11:50:35 -0400 Thread-Topic: Terminolgy (was: RE: [stir] Draft STIR Charter) Thread-Index: AQHOfxFqMRcw/nYooUmwCCxNc1rypJlhMK/Q Message-ID: <2B0F677F0B95454297753F58D4A07FA3012938D2E5@FHDP1LUMXC7V31.us.one.verizon.com> References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <51DEF16D.2070909@cs.tcd.ie> <51DEF814.9080704@cs.tcd.ie> <66490626-323F-46DF-8D22-D1677C17FE76@neustar.biz> <51DEFF23.20002@cs.tcd.ie> <2B0F677F0B95454297753F58D4A07FA3012938CE59@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC143E4@EX2K10MB1.corp.yaanatech.com> <2B0F677F0B95454297753F58D4A07FA3012938CF79@FHDP1LUMXC7V31.us.one.verizon.com> <22484_1373641602_51E01B82_22484_1178_1_B5939C6860701C49AA39C5DA5189448B0B41BE@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <22484_1373641602_51E01B82_22484_1178_1_B5939C6860701C49AA39C5DA5189448B0B41BE@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: "rlb@ipv.sx" , "stir@ietf.org" , "housley@vigilsec.com" , "Gonzalo.Camarillo@ericsson.com" Subject: Re: [stir] Terminolgy (was: RE: Draft STIR Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 15:50:44 -0000 Ah, now you're asking me to acknowledge that there's a world outside North = America... which we Americans are predisposed not to do... Thanks for the clarification :-) Tim -----Original Message----- From: philippe.fouquart@orange.com [mailto:philippe.fouquart@orange.com]=20 Sent: Friday, July 12, 2013 10:07 AM To: Dwight, Timothy M (Tim) Cc: rlb@ipv.sx; stir@ietf.org; housley@vigilsec.com; Gonzalo.Camarillo@eric= sson.com Subject: Terminolgy (was: RE: [stir] Draft STIR Charter) Tim,=20 I think I see what you mean, but that's not what you wrote :): actually, th= e (N)SN is not what you _dial_ for national calls for most dialling plans o= n the planet because a large number of them use a "National (trunk) prefix"= , eg the 'recommended' 0). As you pointed out the N(S)N is just the [full] = international E.164 number without the CC.=20 Generally speaking, for such terms, people can just look up http://www.itu.= int/rec/T-REC-E.164-201011-I. =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 Dwi= ght, Timothy M (Tim) Sent: Thursday, July 11, 2013 10:52 PM To: Michael Hammer; Henning.Schulzrinne@fcc.gov; stephen.farrell@cs.tcd.ie;= Brian.Rosen@neustar.biz Cc: rlb@ipv.sx; stir@ietf.org; housley@vigilsec.com; Gonzalo.Camarillo@eric= sson.com Subject: Re: [stir] Draft STIR Charter The national (significant) part is what you dial any time you're calling a = number in your own country code. Which is for most of us the normal case. = Therefore the national (significant) part is the thing most closely associ= ated with "telephone number". Only if you specify "International" format, = is it clear that you meant for the country code to be included. The car analogy brings back a college course in philosophy, in which I reca= ll spending a session trying to define whether there was some essential not= ion of "chairness" possessed by all chairs. I'll happily refrain from goin= g down that path again :-). tim -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Thursday, July 11, 2013 2:32 PM To: Dwight, Timothy M (Tim); Henning.Schulzrinne@fcc.gov; stephen.farrell@c= s.tcd.ie; Brian.Rosen@neustar.biz Cc: rlb@ipv.sx; stir@ietf.org; housley@vigilsec.com; Gonzalo.Camarillo@eric= sson.com Subject: RE: [stir] Draft STIR Charter Tim, The national specific part is a sub-component of the complete E.164 number. You wouldn't call a car complete if you took the engine out. :) Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dwi= ght, Timothy M (Tim) Sent: Thursday, July 11, 2013 3:23 PM To: Henning Schulzrinne; 'Stephen Farrell'; Rosen, Brian Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter Henning, I think what you describe is what Rec. E.164 calls an International E.164 n= umber. It also discusses National (Significant) Numbers, which are the Int= ernational E.164 number minus the Country Code. tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hen= ning Schulzrinne Sent: Thursday, July 11, 2013 2:00 PM To: 'Stephen Farrell'; Rosen, Brian Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter E.164 implies full phone number. >From E.164, Section 6.2: The international ITU-T E.164-number is composed of a variable number of de= cimal digits arranged in specific code fields. The international ITU-T E.16= 4-number code fields are the country code (CC) and remaining fields are spe= cific to the use being made of the international ITU-T E.164 number as show= n in Figures 1 to 5. A numbering plan does not include prefixes, suffixes, and additional inform= ation required to complete a call. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Ste= phen Farrell Sent: Thursday, July 11, 2013 2:53 PM To: Rosen, Brian Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter On 07/11/2013 07:29 PM, Rosen, Brian wrote: > So maybe where we say "where the identity being authenticated is a=20 > telephone number" add "in e.164 format"? Better all right. Some people were saying "full e.164" which I guess means = including country code and a +, which'd be even better, if its not already = implied in e.164. _______________________________________________ stir mailing 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 ___________________________________________________________________________= ______________________________________________ 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. From hadriel.kaplan@oracle.com Fri Jul 12 08:59: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 77BC721E80A8 for ; Fri, 12 Jul 2013 08:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.758 X-Spam-Level: X-Spam-Status: No, score=-5.758 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guVCprE8w+4K for ; Fri, 12 Jul 2013 08:59:46 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 06DAA21E8053 for ; Fri, 12 Jul 2013 08:59: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 r6CFxgdG006211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 12 Jul 2013 15:59:43 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6CFxgYA023175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jul 2013 15:59:42 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6CFxfGr023164; Fri, 12 Jul 2013 15:59:41 GMT Received: from [10.235.136.197] (/174.254.177.218) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 12 Jul 2013 08:59:41 -0700 References: <2432405C-213B-444A-8F11-01307ED90DEA@neustar.biz> <371D5F4C-17C7-497A-9258-409E815DF39B@neustar.biz> <12FF2857-14B4-4C7E-A1FD-BE89EFC01189@neustar.biz> Mime-Version: 1.0 (1.0) In-Reply-To: <12FF2857-14B4-4C7E-A1FD-BE89EFC01189@neustar.biz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <65A43D35-4E01-46C9-B625-508A09622907@oracle.com> X-Mailer: iPhone Mail (10B329) From: "hadriel.kaplan@oracle.com" Date: Fri, 12 Jul 2013 11:59:39 -0400 To: "Rosen, Brian" X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: Richard Barnes , "stir@ietf.org" , Russ Housley , Gonzalo Camarillo Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 15:59:52 -0000 Sent from my iPhone On Jul 12, 2013, at 10:25 AM, "Rosen, Brian" wrote= : >=20 > On Jul 11, 2013, at 10:37 PM, Hadriel Kaplan w= rote: >=20 >>=20 >> On Jul 11, 2013, at 10:21 AM, Russ Housley wrote: >>=20 >>> Initially, the working group will specify an in-band mechanism to authen= ticate the originator of a SIP session where the identity being authenticate= d is a telephone number and the session is established with SIP end to end. = The working group will consider choices for protecting the identity informa= tion and the credentials used, but will likely be similar to the methods des= cribed in RFC 4474, which employs a signature over a set of information in t= he SIP headers using a credential assigned to the identity. In order to be a= uthoritative, credentials used with this mechanism will be derived from exis= ting telephone number assignment and delegation models. That is, when a tel= ephone number or range of telephone numbers is delegated to an entity, a cre= dential will accompany such delegation. =20 >>=20 >> This is a bit of a nitpick, but the solution does not have to accompany a= delegation with credentials. It could, for example, instead accompany a de= legation with access rights to the same or another database to upload a publ= ic-key for the delegated number. Or it could even divorce the process of nu= mber delegation from STIR altogether - for example we could rely on existing= number-lookup databases providing a SPID of the delegated-to carrier, and u= se a separate web-pki model for certificate signing of SPIDs (instead of dir= ectly relating the signing to indicate authority of numbers). > Okay, but please send text. "Accompany" was meant to not imply all of tho= se. We deliberately stayed away from mentioning how any one got the credent= ial, what kind of databases existed, etc, just that there was a credential t= hat mirrored the delegation which was used to sign and verify. >=20 As long as we're cool with keeping it open, I'm cool with letting the curren= t wording stay. As I said it was a bit of a nitpick. :) -hadriel= From hadriel.kaplan@oracle.com Fri Jul 12 08:57: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 45A5321F9D0A for ; Fri, 12 Jul 2013 08:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.778 X-Spam-Level: X-Spam-Status: No, score=-5.778 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oanVQmG+8L1Q for ; Fri, 12 Jul 2013 08:57:33 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id AF5B421F9D7D for ; Fri, 12 Jul 2013 08:57:33 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6CFvNf8016420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 12 Jul 2013 15:57:24 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 r6CFvL3B017691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jul 2013 15:57:22 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 r6CFvL3S017651; Fri, 12 Jul 2013 15:57:21 GMT Received: from [10.235.136.197] (/174.254.177.218) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 12 Jul 2013 08:57:20 -0700 References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <3599_1373638407_51E00F07_3599_1118_1_B5939C6860701C49AA39C5DA5189448B0B4135@PEXCVZYM12.corporate.adroot.infra.ftgroup> <9B2F33E0-E9DA-497C-8878-A251C2555D00@neustar.biz> Mime-Version: 1.0 (1.0) In-Reply-To: <9B2F33E0-E9DA-497C-8878-A251C2555D00@neustar.biz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <668ADA86-B3FB-4810-811F-8CC14BBC7127@oracle.com> X-Mailer: iPhone Mail (10B329) From: "hadriel.kaplan@oracle.com" Date: Fri, 12 Jul 2013 11:57:16 -0400 To: "Rosen, Brian" X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Mailman-Approved-At: Fri, 12 Jul 2013 09:03:04 -0700 Cc: "" , "Peterson, Jon" , "rlb@ipv.sx" , "housley@vigilsec.com" , "Gonzalo.Camarillo@ericsson.com" , "stir@ietf.org" , "stephen.farrell@cs.tcd.ie" , Michael Hammer , "timothy.dwight@verizon.com" , "Henning.Schulzrinne@fcc.gov" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 15:57:39 -0000 Yes I think that's the right thing to do for the charter. Even during WG wo= rk, we're not really trying to authenticate E.164 numbers per se, but rather= the caller-id telephone number. It just happens that handling it as an E.1= 64 makes it a lot easier/straight-forward. -hadriel Sent from my iPhone On Jul 12, 2013, at 10:18 AM, "Rosen, Brian" wrote= : > Can we conclude this discussion by leaving the text alone, so it refers to= vague "telephone numbers" and not even try to define them further? >=20 > Brian >=20 > On Jul 12, 2013, at 10:13 AM, wrote: >=20 >> Regarding tool free and the like, I would agree to defer this to a WG dis= cussion. I think we're now confusing reachability (which a relative concept e= ven in the so called _P_STN) and uniqueness. There are lots of E.164 numbers= that are not globally reachable. =20 >>=20 >> Whether this applies only to geographic country codes or to any E.164 cou= ntry codes is an interesting question. All I've read so far most applies to g= eographic country codes,... well, groups of countries in fact, mmmh... +1 ac= tually :) >>=20 >> Re. national only numbers, I'd prefer dealing with this at a later stage.= (I'm not even sure it calls for a significantly different solution, other t= han the URI format, that is) =20 >>=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: Thursday, July 11, 2013 10:30 PM >> To: Peterson, Jon >> Cc: rlb@ipv.sx; housley@vigilsec.com; Gonzalo.Camarillo@ericsson.com; sti= r@ietf.org; Henning.Schulzrinne@fcc.gov; Michael Hammer; timothy.dwight@veri= zon.com; stephen.farrell@cs.tcd.ie >> Subject: Re: [stir] Draft STIR Charter >>=20 >> Yeah, well, let's talk about that, because you are right. >>=20 >> It really would be a good idea to be able to get a call which had a calle= d party number of 9-1-1 or 1-1-2 and was verifiably from that number. >>=20 >> We certainly want to be able to handle "toll free" numbers, which in many= cases are not actually e.164s, even though they look like them. >>=20 >> The problem is that while the latter is usually easy to handle, because e= ven if 18005551212 is not truly an e.164, we certainly could canonicalize th= em as if they were and everything would work, doing that with 1-1-2 is anoth= er story. >>=20 >> Probably not worth dealing with these issues in charter language. >>=20 >> So, Stephen, unless someone can come up with some wording that works, I'd= prefer to defer the discussion to the work group (if/when we get one), rath= er than do it in charter language. >>=20 >> Brian >>=20 >> On Jul 11, 2013, at 4:22 PM, "Peterson, Jon" >> wrote: >>=20 >>>=20 >>> My understanding was that certain nationally-specific numbers, such as >>> freephone numbers, actually don't fall under the E.164 plan, and that th= us >>> restricting this to "E.164 numbers" may rule out some numbers we probabl= y >>> want to provide identity for. These numbers have the quality that they >>> aren't reachable internationally. No? >>>=20 >>> Jon Peterson >>> Neustar, Inc. >>>=20 >>> On 7/11/13 12:32 PM, "Michael Hammer" wro= te: >>>=20 >>>> Tim, >>>>=20 >>>> The national specific part is a sub-component of the complete E.164 >>>> number. >>>>=20 >>>> You wouldn't call a car complete if you took the engine out. :) >>>>=20 >>>> Mike >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of= >>>> Dwight, Timothy M (Tim) >>>> Sent: Thursday, July 11, 2013 3:23 PM >>>> To: Henning Schulzrinne; 'Stephen Farrell'; Rosen, Brian >>>> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >>>> Subject: Re: [stir] Draft STIR Charter >>>>=20 >>>> Henning, >>>>=20 >>>> I think what you describe is what Rec. E.164 calls an International E.1= 64 >>>> number. It also discusses National (Significant) Numbers, which are th= e >>>> International E.164 number minus the Country Code. >>>>=20 >>>> tim >>>>=20 >>>> -----Original Message----- >>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of= >>>> Henning Schulzrinne >>>> Sent: Thursday, July 11, 2013 2:00 PM >>>> To: 'Stephen Farrell'; Rosen, Brian >>>> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >>>> Subject: Re: [stir] Draft STIR Charter >>>>=20 >>>> E.164 implies full phone number. >>>>=20 >>>> =46rom E.164, Section 6.2: >>>>=20 >>>> The international ITU-T E.164-number is composed of a variable number o= f >>>> decimal digits arranged in specific code fields. The international ITU-= T >>>> E.164-number code fields are the country code (CC) and remaining fields= >>>> are >>>> specific to the use being made of the international ITU-T E.164 number a= s >>>> shown in Figures 1 to 5. >>>> A numbering plan does not include prefixes, suffixes, and additional >>>> information required to complete a call. >>>>=20 >>>> -----Original Message----- >>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of= >>>> Stephen Farrell >>>> Sent: Thursday, July 11, 2013 2:53 PM >>>> To: Rosen, Brian >>>> Cc: Richard Barnes; ; Russ Housley; Gonzalo Camarillo >>>> Subject: Re: [stir] Draft STIR Charter >>>>=20 >>>>=20 >>>>=20 >>>> On 07/11/2013 07:29 PM, Rosen, Brian wrote: >>>>> So maybe where we say "where the identity being authenticated is a >>>>> telephone number" add "in e.164 format"? >>>>=20 >>>> Better all right. Some people were saying "full e.164" which I guess me= ans >>>> including country code and a +, which'd be even better, if its not alre= ady >>>> implied in e.164. >>>>=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 >> _______________________________________________ >> 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 e= lectroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and de= lete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> 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 housley@vigilsec.com Fri Jul 12 13:08: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 78F9921F9EA7 for ; Fri, 12 Jul 2013 13:08:26 -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 BnirdPvFf+Wv for ; Fri, 12 Jul 2013 13:08:20 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 2B74521F9E94 for ; Fri, 12 Jul 2013 13:08:20 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 59669F240B0; Fri, 12 Jul 2013 16:09:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id miVaFQIUGq7A; Fri, 12 Jul 2013 16:08:03 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-163-41.washdc.fios.verizon.net [96.241.163.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id F25D7F2408B; Fri, 12 Jul 2013 16:09:14 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley Date: Fri, 12 Jul 2013 16:08:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1328ADD7-D65E-4D5D-9E7E-49A991E41B1B@vigilsec.com> References: <51DFDC83.6060005@cs.tcd.ie> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1085) Cc: IETF STIR Mail List Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 20:08:26 -0000 Hadriel: >> Initially, the working group will specify an in-band mechanism to = authenticate the originator of a SIP session where the identity being = authenticated is a telephone number and the session is established with = SIP end to end. The working group will consider choices for protecting = the identity information and the credentials used, but will likely be = similar to the methods described in RFC 4474, which employs a signature = over a set of information in the SIP headers using a credential assigned = to the identity. In order to be authoritative, credentials used with = this mechanism will be derived from existing telephone number assignment = and delegation models. That is, when a telephone number or range of = telephone numbers is delegated to an entity, a credential will accompany = such delegation. =20 >=20 > This is a bit of a nitpick, but the solution does not have to = accompany a delegation with credentials. It could, for example, instead = accompany a delegation with access rights to the same or another = database to upload a public-key for the delegated number. Or it could = even divorce the process of number delegation from STIR altogether - for = example we could rely on existing number-lookup databases providing a = SPID of the delegated-to carrier, and use a separate web-pki model for = certificate signing of SPIDs (instead of directly relating the signing = to indicate authority of numbers). Does this change that was made based on Stephen's comments also address = your concern? If so, please say so on the list. If not, please tell us = on list what concern remains. Russ --- FROM THE THREAD WITH STEPHEN --- >>>>=20 >>>> Initially, the working group will specify an in-band mechanism >>>> to authenticate the originator of a SIP session where the >>>> identity being authenticated is a telephone number and the >>>> session is established with SIP end to end. The working group >>>> will consider choices for protecting the identity information and >>>> the credentials used, but will likely be similar to the methods >>>> described in RFC 4474, which employs a signature over a set of >>>> information in the SIP headers using a credential assigned to the >>>> identity. >>>=20 >>> I suggest replacing the above with >>>=20 >>> "will likely be based on a digital signature mechanism that is=20 >>> cryptographically similar to the one described in RFC 4474 and=20 >>> where the signature continues to be represented in SIP headers." >>>=20 >>> Saying "methods" and 4474 is a bit vague and could be read to mean >>> "s/mime-based" or "cms based" or "x.509 based" whereas what I think >>> we want is just to say its a signature. >>>=20 >>> Similarly "assigned to the identity" is very ambiguous and probably >>> better just omitted for now. >>=20 >> Some means of associating the identity with the public key is >> needed. >>=20 >> How about: >>=20 >> The working group will consider choices for protecting the identity >> information and the credentials used, but will likely be based on a >> digital signature mechanism that covers a set of information in the >> SIP headers, and verification will employ a credential that contains >> the public key and is associated with the identity. From housley@vigilsec.com Fri Jul 12 13:27: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 F3AC421F9EA9 for ; Fri, 12 Jul 2013 13:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 5cyw2QKA0yKW for ; Fri, 12 Jul 2013 13:27:36 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 1583121F9E98 for ; Fri, 12 Jul 2013 13:27:36 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 47DB3F240B0 for ; Fri, 12 Jul 2013 16:27:57 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id QsNSBkLlSTy2 for ; Fri, 12 Jul 2013 16:27:34 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-163-41.washdc.fios.verizon.net [96.241.163.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id A9156F2408B for ; Fri, 12 Jul 2013 16:27:55 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> Date: Fri, 12 Jul 2013 16:27:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> To: IETF STIR Mail List X-Mailer: Apple Mail (2.1085) Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 20:27:41 -0000 How about (with a bit more surrounding text to make sure we all see the = context): Initially, the working group will specify an in-band mechanism to = authenticate the originator of a SIP session where the identity being = authenticated is a telephone number and the session is established with = SIP end to end. The mechanism will use a canonical telephone number = representation specified by the working group, including any mappings = that might be needed between the SIP header fields and the canonical = telephone number representation. ... Russ On Jul 12, 2013, at 10:39 AM, Rosen, Brian wrote: > I don't have a problem with that concept. >=20 > There is the difficulty that we may have to deal with PAI instead of = =46rom in some cases. We may even need to send the number in some other = new header, although I hope we don't have to. We haven't settled that = issue yet. =20 >=20 > The mechanism will likely also use the destination TN, which has the = same issue. =20 >=20 > I edited the text to remove references to specific headers. We could = have "The mechanism will use a canonical form of telephone number, based = on the contents of the SIP header fields. The working group will specify = the details of the form, as well as any mapping that might be needed = between the header fields and the canonical form." >=20 >=20 > On Jul 12, 2013, at 10:32 AM, Dave Crocker > wrote: >=20 >> On 7/12/2013 3:32 AM, Stephen Farrell wrote: >>>> So, Stephen, unless someone can come up with some wording that = works, >>>>> I'd prefer to defer the discussion to the work group (if/when we = get >>>>> one), rather than do it in charter language. >>> Given the amount of discussion this caused (sorry for that:-), I >>> agree. >>=20 >>=20 >> In fact the amount of discussion suggests that this is enough of an = issue to be worth calling out the issue explicitly in the charter. >>=20 >> Perhaps adding something like: >>=20 >> The mechanism will use a canonical form of telephone number, based = on the contents of the SIP =46rom field. The working group will specify = the details of the form, as well as any mapping that might be needed = between the =46rom field and the canonical form. >>=20 >>=20 >> --=20 >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From dhc@dcrocker.net Fri Jul 12 15:19: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 6DD1F21E8054 for ; Fri, 12 Jul 2013 15:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxyZutd38irD for ; Fri, 12 Jul 2013 15:19:06 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2C321E8056 for ; Fri, 12 Jul 2013 15:19: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 r6CMJ21o021151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 Jul 2013 15:19:06 -0700 Message-ID: <51E080BB.2060403@dcrocker.net> Date: Fri, 12 Jul 2013 15:18:35 -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: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> In-Reply-To: <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 12 Jul 2013 15:19:06 -0700 (PDT) Cc: IETF STIR Mail List Subject: Re: [stir] Draft STIR 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: Fri, 12 Jul 2013 22:19:11 -0000 On 7/12/2013 1:27 PM, Russ Housley wrote: > Initially, the working group will specify an in-band mechanism to authenticate the originator of a SIP session where the identity being authenticated is a telephone number and the session is established with SIP end to end. The mechanism will use a canonical telephone number representation specified by the working group, including any mappings that might be needed between the SIP header fields and the canonical telephone number representation. Looks good. For what it's worth, the "Initially" is superfluous as charter text. Charters are very existential. There's here and now; the work to be done as chartered. Everything else is fantasy, because it can't be promised. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From housley@vigilsec.com Fri Jul 12 16:05: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 32DF721E80B5 for ; Fri, 12 Jul 2013 16:05:10 -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.035, 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 M3trbyi0ij6j for ; Fri, 12 Jul 2013 16:05:05 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id C65D721E8054 for ; Fri, 12 Jul 2013 16:05:04 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 30A45F240B0 for ; Fri, 12 Jul 2013 19:05:49 -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 02fHF4cmZT1D for ; Fri, 12 Jul 2013 19:04:50 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-163-41.washdc.fios.verizon.net [96.241.163.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 2E1AFF2408B for ; Fri, 12 Jul 2013 19:05:45 -0400 (EDT) From: Russ Housley Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/mixed; boundary=Apple-Mail-26-226108249 Date: Fri, 12 Jul 2013 19:04:59 -0400 In-Reply-To: <51E080BB.2060403@dcrocker.net> To: IETF STIR Mail List References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> Message-Id: X-Mailer: Apple Mail (2.1085) Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 23:05:10 -0000 --Apple-Mail-26-226108249 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have tried to pull all of the discussion into an updated charter. I = have also attached a diff to make it easier to review. Russ --Apple-Mail-26-226108249 Content-Disposition: attachment; filename=charter-stir-00-00ab.wdiff.html Content-Type: text/html; name="charter-stir-00-00ab.wdiff.html" Content-Transfer-Encoding: 7bit wdiff charter-stir-00-00a.txt charter-stir-00-00b.txt 

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

Chairs: TBD
Area Advisor: Richard Barnes

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

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.  As with email, the claimed source identity of a SIP
request is not verified, and this permits unauthorized use of source
identities as part of deceptive and coercive activities, such as
robocalling (bulk unsolicited commercial communications), vishing
(voicemail hacking, and impersonating banks) and swatting (impersonating
callers to emergency services to stimulate unwarranted large scale law
enforcement deployments).  This working group will define a deployable
mechanism to validate the identity of the calling party that can be
verified by entities in the path of a call.

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

Initially, As its first work item, the working group will specify an in-band
mechanism to authenticate the originator of a SIP session where the
identity being authenticated is a telephone number and the session is
established with SIP end to end.  The mechanism will use a canonical
telephone number representation specified by the working group, including
any mappings that might be needed between the SIP header fields and the
canonical telephone number representation.  The working group will
consider choices for protecting the identity information and the
credentials used, but will likely be
similar to the methods described in RFC 4474, which employs based on a digital signature
over
mechanism that covers a set of information in the SIP headers using headers, and
verification will employ a credential assigned
to that contains the public key and is
associated with the identity.  In order to be authoritative, credentials
used with this mechanism will be derived from existing telephone number
assignment and delegation models.  That is, when a telephone number or
range of telephone numbers is delegated to an entity, a credential relevant
credentials will accompany be generated (or modified) to reflect such delegation.
The mechanism must allow parties who are not delegated a telephone
number, but are preauthorized by the entity who is delegated the number,
to place calls using the identity.  Expansion of the authentication
mechanism to identities using the user@domain form should be considered
in the initial design. design, but the main focus of the working group is to
develop a solution for telephone numbers.  After completing the SIP end
to end solution, the working group will consider session establishment
where there are one or more non-SIP hops, most likely using an
out-of-band authentication mechanism.  However, the in-band and
out-of-band mechanisms should share as much in common as possible,
especially the credentials.

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

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

Authenticated identity is closely linked to privacy, and one frequently
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.

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

The working group will deliver the following:

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

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

  - A document describing the credentials required to support secure
    telephone identity

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

Milestones

Sep 2013   Submit problem statement for Informational
Nov 2013   Submit RFC4474bis in-band mechanism for Proposed Standard
Feb 2014   Submit credential specification for Proposed Standard
Jun 2014   Submit fallback for Proposed Standard
--Apple-Mail-26-226108249 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii = = = = = = = = = = Name: Secure Telephone Identity Revisited (stir) Area: RAI Chairs: TBD Area Advisor: Richard Barnes Mailing list: stir@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/stir 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. As with email, the claimed source identity of a SIP request is not verified, and this permits unauthorized use of source identities as part of deceptive and coercive activities, such as robocalling (bulk unsolicited commercial communications), vishing (voicemail hacking, and impersonating banks) and swatting (impersonating callers to emergency services to stimulate unwarranted large scale law enforcement deployments). This working group will define a deployable mechanism to validate the identity of the calling party that can be verified by entities in the path of a call. SIP is one of the main VoIP technologies used by parties that want to present an incorrect origination. Several previous efforts have tried to secure the origins of SIP communications, including RFC 3325, RFC 4474, and the VIPR working group. To date, however, true validation of the source of SIP calls has not seen any appreciable deployment. Several factors contributed to this lack of success, including: failure of the problem to be seen as critical at the time; lack of any real means of asserting authority over telephone numbers; misalignment of the mechanisms proposed by RFC 4474 with the complex deployment environment that has emerged for SIP; lack of end-to-end SIP session establishment; and inherent operational problems with a transitive trust model. To make deployment of this solution more likely, consideration must be given to user experience as well as overhead for the call source and all verifiers. As its first work item, the working group will specify an in-band mechanism to authenticate the originator of a SIP session where the identity being authenticated is a telephone number and the session is established with SIP end to end. The mechanism will use a canonical telephone number representation specified by the working group, including any mappings that might be needed between the SIP header fields and the canonical telephone number representation. The working group will consider choices for protecting the identity information and the credentials used, but will likely be based on a digital signature mechanism that covers a set of information in the SIP headers, and verification will employ a credential that contains the public key and is associated with the identity. In order to be authoritative, credentials used with this mechanism will be derived from existing telephone number assignment and delegation models. That is, when a telephone number or range of telephone numbers is delegated to an entity, relevant credentials will be generated (or modified) to reflect such delegation. The mechanism must allow parties who are not delegated a telephone number, but are preauthorized by the entity who is delegated the number, to place calls using the identity. Expansion of the authentication mechanism to identities using the user@domain form should be considered in the initial design, but the main focus of the working group is to develop a solution for telephone numbers. After completing the SIP end to end solution, the working group will consider session establishment where there are one or more non-SIP hops, most likely using an out-of-band authentication mechanism. However, the in-band and out-of-band mechanisms should share as much in common as possible, especially the credentials. The working group will coordinate with the Security Area on credential management. The working group will coordinate with other working groups in the RAI Area regarding signaling through existing deployments. Authenticated identity is closely linked to privacy, and one frequently 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. 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 The working group will deliver the following: - A problem statement detailing the deployment environment and situation that motivate work on secure telephone identity - A mechanism document describing the SIP end-to-end with telephone number-based identities - A document describing the credentials required to support secure telephone identity - A fallback mechanism to allow out-of-band identity establishment during call setup Milestones Sep 2013 Submit problem statement for Informational Nov 2013 Submit in-band mechanism for Proposed Standard Feb 2014 Submit credential specification for Proposed Standard Jun 2014 Submit fallback for Proposed Standard --Apple-Mail-26-226108249-- From hadriel.kaplan@oracle.com Fri Jul 12 16:35: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 2C86E21F9F9C for ; Fri, 12 Jul 2013 16:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.438 X-Spam-Level: X-Spam-Status: No, score=-6.438 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+M3Omr7kGHS for ; Fri, 12 Jul 2013 16:34:57 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8282C21F918F for ; Fri, 12 Jul 2013 16:34:57 -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 r6CNYtY8004354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 12 Jul 2013 23:34:55 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 r6CNYs1b022328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jul 2013 23:34:55 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 r6CNYrF2019077; Fri, 12 Jul 2013 23:34:53 GMT Received: from [192.168.2.6] (/184.61.127.93) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 12 Jul 2013 16:34: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: <1328ADD7-D65E-4D5D-9E7E-49A991E41B1B@vigilsec.com> Date: Fri, 12 Jul 2013 19:34:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51DFDC83.6060005@cs.tcd.ie> <1328ADD7-D65E-4D5D-9E7E-49A991E41B1B@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: IETF STIR Mail List Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 23:35:04 -0000 Yup works for me. -hadriel On Jul 12, 2013, at 4:08 PM, Russ Housley wrote: > Hadriel: >=20 >>> Initially, the working group will specify an in-band mechanism to = authenticate the originator of a SIP session where the identity being = authenticated is a telephone number and the session is established with = SIP end to end. The working group will consider choices for protecting = the identity information and the credentials used, but will likely be = similar to the methods described in RFC 4474, which employs a signature = over a set of information in the SIP headers using a credential assigned = to the identity. In order to be authoritative, credentials used with = this mechanism will be derived from existing telephone number assignment = and delegation models. That is, when a telephone number or range of = telephone numbers is delegated to an entity, a credential will accompany = such delegation. =20 >>=20 >> This is a bit of a nitpick, but the solution does not have to = accompany a delegation with credentials. It could, for example, instead = accompany a delegation with access rights to the same or another = database to upload a public-key for the delegated number. Or it could = even divorce the process of number delegation from STIR altogether - for = example we could rely on existing number-lookup databases providing a = SPID of the delegated-to carrier, and use a separate web-pki model for = certificate signing of SPIDs (instead of directly relating the signing = to indicate authority of numbers). >=20 >=20 > Does this change that was made based on Stephen's comments also = address your concern? If so, please say so on the list. If not, please = tell us on list what concern remains. >=20 > Russ >=20 >=20 > --- FROM THE THREAD WITH STEPHEN --- >=20 >>>>>=20 >>>>> Initially, the working group will specify an in-band mechanism >>>>> to authenticate the originator of a SIP session where the >>>>> identity being authenticated is a telephone number and the >>>>> session is established with SIP end to end. The working group >>>>> will consider choices for protecting the identity information and >>>>> the credentials used, but will likely be similar to the methods >>>>> described in RFC 4474, which employs a signature over a set of >>>>> information in the SIP headers using a credential assigned to the >>>>> identity. >>>>=20 >>>> I suggest replacing the above with >>>>=20 >>>> "will likely be based on a digital signature mechanism that is=20 >>>> cryptographically similar to the one described in RFC 4474 and=20 >>>> where the signature continues to be represented in SIP headers." >>>>=20 >>>> Saying "methods" and 4474 is a bit vague and could be read to mean >>>> "s/mime-based" or "cms based" or "x.509 based" whereas what I think >>>> we want is just to say its a signature. >>>>=20 >>>> Similarly "assigned to the identity" is very ambiguous and probably >>>> better just omitted for now. >>>=20 >>> Some means of associating the identity with the public key is >>> needed. >>>=20 >>> How about: >>>=20 >>> The working group will consider choices for protecting the identity >>> information and the credentials used, but will likely be based on a >>> digital signature mechanism that covers a set of information in the >>> SIP headers, and verification will employ a credential that contains >>> the public key and is associated with the identity. >=20 From dhc@dcrocker.net Fri Jul 12 16:44: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 13A4211E8139 for ; Fri, 12 Jul 2013 16:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0q6MkKVSXmO for ; Fri, 12 Jul 2013 16:44:11 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAA321F9FD6 for ; Fri, 12 Jul 2013 16:44: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 r6CNi7tG024225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 Jul 2013 16:44:10 -0700 Message-ID: <51E094AB.4000105@dcrocker.net> Date: Fri, 12 Jul 2013 16:43:39 -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: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@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, 12 Jul 2013 16:44:10 -0700 (PDT) Cc: IETF STIR Mail List Subject: Re: [stir] Draft STIR 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: Fri, 12 Jul 2013 23:44:16 -0000 Meta-point: The text is only about authentication, but the discussion has been about authorization. For example one might have an authenticated originator value that is not the string displayed as Caller-ID.[*] I understood the purpose of the wg to be ensuring that the displayed string was authorized by its assignee. If no one cares about this distinction and everyone feels that "authenticate the originator" is sufficiently precise and accurate, fine, but I thought it worth making sure. > To make > deployment of this solution more likely, consideration must be given to > user experience as well as overhead for the call source and all > verifiers. In this form, the text is sufficiently generic so that it applies to essentially all protocol work ever done in the IETF. It would help to have it provide some substantive guidance and/or constraint. The list that was developed in the earlier discussion seemed reasonable for this: To ensure usability, consideration will be given to computational and administrative overhead, exchange latency, and real-time performance within call-setup limits. > As its first work item, the working group will specify an in-band > mechanism to authenticate the originator of a SIP session where the > identity being authenticated is a telephone number and the session is Thinking about having someone read this who hasn't already tracked the discussion: The meaning of 'in-band' might not be at all obvious. Perhaps: the working group will specify a mechanism to authenticate the originator of a SIP session, where the identity being authenticated is a telephone number based on information in SIP headers, the session is established end to end, and the mechanism works within the SIP session (in-band). The reference to SIP headers is core to what's been discussed and it provides context for the reference in the next sentence. > established with SIP end to end. The mechanism will use a canonical > telephone number representation specified by the working group, including > any mappings that might be needed between the SIP header fields and the > canonical telephone number representation. The working group will > consider choices for protecting the identity information and the > credentials used, but will likely be based on a digital signature > mechanism that covers a set of information in the SIP headers, and > verification will employ a credential that contains the public key and is > associated with the identity. In order to be authoritative, credentials > used with this mechanism will be derived from existing telephone number > assignment and delegation models. That is, when a telephone number or > range of telephone numbers is delegated to an entity, relevant > credentials will be generated (or modified) to reflect such delegation. > The mechanism must allow parties who are not delegated a telephone > number, but are preauthorized by the entity who is delegated the number, preauthorized -> authorized The 'pre' actually confused me for awhile > to place calls using the identity. Expansion of the authentication > mechanism to identities using the user@domain form should be considered > in the initial design, but the main focus of the working group is to > develop a solution for telephone numbers. After completing the SIP end 'Considered...but main focus' essentially calls for solving the issue in the current effort. Instead: Expansion of the authentication mechanism to identifiers using the user@domain form is deferred. This creates awareness of the issue and implies an intent to deal with it (later). > to end solution, the working group will consider session establishment > where there are one or more non-SIP hops, most likely using an > out-of-band authentication mechanism. However, the in-band and > out-of-band mechanisms should share as much in common as possible, > especially the credentials. These two draft sentence essentially require defining an out-of-band mechanism; if they don't they are meaningless or a distraction. Instead: Consideration of out-of-band mechanisms, to deal with transit across non-SIP hops, is deferred. > The working group will coordinate with the Security Area on credential > management. On advice of others, the draft text I had circulated for this was: 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 other working groups in the RAI > Area regarding signaling through existing deployments. > > Authenticated identity is closely linked to privacy, and one frequently > 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. > > 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 > > The working group will deliver the following: > > - A problem statement detailing the deployment environment and > situation that motivate work on secure telephone identity > > - A mechanism document describing the SIP end-to-end with telephone > number-based identities > > - A document describing the credentials required to support secure > telephone identity 'secure'? that's quite generic, and probably far beyond the scope of this working group. > > - A fallback mechanism to allow out-of-band identity establishment > during call setup I thought there was agreement to drop this deliverable. It seems to have crept back in. > Milestones > > Sep 2013 Submit problem statement for Informational > Nov 2013 Submit in-band mechanism for Proposed Standard > Feb 2014 Submit credential specification for Proposed Standard > Jun 2014 Submit fallback for Proposed Standard ditto. [*] Since provides such a wealth of odd experience, I'll note that DKIM is an example of creating an authenticated identifier that says nothing about the author address. -- Dave Crocker Brandenburg InternetWorking bbiw.net From stephen.farrell@cs.tcd.ie Fri Jul 12 16:51: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 5145221F933B for ; Fri, 12 Jul 2013 16:51:26 -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 45O-gOAKQO19 for ; Fri, 12 Jul 2013 16:51:12 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 05DA021F91AB for ; Fri, 12 Jul 2013 16:51:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4D96BBEB1; Sat, 13 Jul 2013 00:50:48 +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 g61MGzwp5o6D; Sat, 13 Jul 2013 00:50:46 +0100 (IST) Received: from [10.87.48.9] (unknown [86.44.68.94]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3575BBE9C; Sat, 13 Jul 2013 00:50:46 +0100 (IST) Message-ID: <51E09655.2050909@cs.tcd.ie> Date: Sat, 13 Jul 2013 00:50:45 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hadriel Kaplan References: <51DFDC83.6060005@cs.tcd.ie> <1328ADD7-D65E-4D5D-9E7E-49A991E41B1B@vigilsec.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF STIR Mail List , Russ Housley Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jul 2013 23:51:26 -0000 On 07/13/2013 12:34 AM, Hadriel Kaplan wrote: > > Yup works for me. Same here. S. > > -hadriel > > On Jul 12, 2013, at 4:08 PM, Russ Housley wrote: > >> Hadriel: >> >>>> Initially, the working group will specify an in-band mechanism to authenticate the originator of a SIP session where the identity being authenticated is a telephone number and the session is established with SIP end to end. The working group will consider choices for protecting the identity information and the credentials used, but will likely be similar to the methods described in RFC 4474, which employs a signature over a set of information in the SIP headers using a credential assigned to the identity. In order to be authoritative, credentials used with this mechanism will be derived from existing telephone number assignment and delegation models. That is, when a telephone number or range of telephone numbers is delegated to an entity, a credential will accompany such delegation. >>> >>> This is a bit of a nitpick, but the solution does not have to accompany a delegation with credentials. It could, for example, instead accompany a delegation with access rights to the same or another database to upload a public-key for the delegated number. Or it could even divorce the process of number delegation from STIR altogether - for example we could rely on existing number-lookup databases providing a SPID of the delegated-to carrier, and use a separate web-pki model for certificate signing of SPIDs (instead of directly relating the signing to indicate authority of numbers). >> >> >> Does this change that was made based on Stephen's comments also address your concern? If so, please say so on the list. If not, please tell us on list what concern remains. >> >> Russ >> >> >> --- FROM THE THREAD WITH STEPHEN --- >> >>>>>> >>>>>> Initially, the working group will specify an in-band mechanism >>>>>> to authenticate the originator of a SIP session where the >>>>>> identity being authenticated is a telephone number and the >>>>>> session is established with SIP end to end. The working group >>>>>> will consider choices for protecting the identity information and >>>>>> the credentials used, but will likely be similar to the methods >>>>>> described in RFC 4474, which employs a signature over a set of >>>>>> information in the SIP headers using a credential assigned to the >>>>>> identity. >>>>> >>>>> I suggest replacing the above with >>>>> >>>>> "will likely be based on a digital signature mechanism that is >>>>> cryptographically similar to the one described in RFC 4474 and >>>>> where the signature continues to be represented in SIP headers." >>>>> >>>>> Saying "methods" and 4474 is a bit vague and could be read to mean >>>>> "s/mime-based" or "cms based" or "x.509 based" whereas what I think >>>>> we want is just to say its a signature. >>>>> >>>>> Similarly "assigned to the identity" is very ambiguous and probably >>>>> better just omitted for now. >>>> >>>> Some means of associating the identity with the public key is >>>> needed. >>>> >>>> How about: >>>> >>>> The working group will consider choices for protecting the identity >>>> information and the credentials used, but will likely be based on a >>>> digital signature mechanism that covers a set of information in the >>>> SIP headers, and verification will employ a credential that contains >>>> the public key and is associated with the identity. >> > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > From ekr@rtfm.com Sun Jul 14 17:37: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 980E021F92A5 for ; Sun, 14 Jul 2013 17:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=0.625, 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 QCsbGSxGM7n7 for ; Sun, 14 Jul 2013 17:37:55 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id 37F0F21F8FF8 for ; Sun, 14 Jul 2013 17:37:51 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id l10so6001372qcy.18 for ; Sun, 14 Jul 2013 17:37: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:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=Ozb58Fq+bpClYqxJ/YUXIq5qeGXNBxT4RplwJ9u+tbE=; b=I52G59oaE9X7CtoUq87BJQ6RInAxTyw5KiM3c44as22lM5v8GByTfa8bywuUJDgIT6 pGRIFDnYXU0sHYPix/tke40egLn7Kuob+UbpnIRcT/rxaguPv3j1JTGNWvUYlEulSAKY Tk5MNePd44aQVR0zVRhHNowuO15D97t0RFN/r1EVTs+gl3Vb1NNNYmALAl4ODh42Atl+ 3UJNi6kN7pzRxnRWwV7QsVOre0MIl3Iuv+3e0f8SdxugmGG0j4ZxvLnWSgyF4EBGRNHt YO5eX10gNGQtdB4DiSpNwKJWO5KXpWm7aejMXgbAoe64I7lo6BPiSN8xUONEimeprnxb a8pA== X-Received: by 10.224.4.202 with SMTP id 10mr50140976qas.1.1373848670711; Sun, 14 Jul 2013 17:37:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.48.234 with HTTP; Sun, 14 Jul 2013 17:37:10 -0700 (PDT) X-Originating-IP: [74.95.2.173] From: Eric Rescorla Date: Sun, 14 Jul 2013 17:37:10 -0700 Message-ID: To: "stir@ietf.org" Content-Type: multipart/alternative; boundary=001a11c20dfefe41b504e1821171 X-Gm-Message-State: ALoCoQlabp4QkLWbEiYD3XK0oT+LawgQsagY0kAu6PDcxNmgfVW7yhaIbCYFH3upJlEz+PTldZyt Subject: [stir] Draft posted X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 15 Jul 2013 00:37:59 -0000 --001a11c20dfefe41b504e1821171 Content-Type: text/plain; charset=ISO-8859-1 Folks, I have posted a -00 draft that provides a high-level description of how one might do STIR out-of-band mode. I've deliberately cut out a lot of the detail of the previous version and/or relegated it to a separate section. The idea here is to look at the big picture. http://tools.ietf.org/html/draft-rescorla-stir-fallback-00 -Ekr --001a11c20dfefe41b504e1821171 Content-Type: text/html; charset=ISO-8859-1 --001a11c20dfefe41b504e1821171-- From ekr@rtfm.com Sun Jul 14 17:43: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 9530D21F9BEF for ; Sun, 14 Jul 2013 17:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=0.599, 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 h46RMe1Qb1cJ for ; Sun, 14 Jul 2013 17:43:33 -0700 (PDT) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id A35A321F9A34 for ; Sun, 14 Jul 2013 17:43:33 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id n20so1319811qaj.13 for ; Sun, 14 Jul 2013 17:43:33 -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=L+4VmMkI5KJvAmI0igwWP/iO/H8WcQ9n+hhs6jrTUxs=; b=B14NlXXAMm9Li6JAuPTXKBs0NrlOQwFN+gi+Dt6wsn8A6edklyGr/HHE6FDg4VxtjA NncBzSpAwQZrbuyuXQMMCkDx0B2i8ksQqDQ7bV/NpGtA7TqHBrBb7S3PIUsIn60dAm7r Km8fRBgB8JPg333P5O8zDEMYUoN1nCMG7kZAjOOTDo8i9Hs7jpnvM1lk4za89MXMsyVi 3CNLydrgrifg1qRq9Pcop8/NRH1sNI6hxxaR0QPP7QitpAcTRVGFZi4uK/zVcbh5Zs4y y/TnEau3Dop02+AcSgSzvqsn93KbCsvpCSDP1hxOkTbtzzLdY86aOa2uCrRAQVey1sU0 rM9g== X-Received: by 10.224.4.202 with SMTP id 10mr50157358qas.1.1373849013137; Sun, 14 Jul 2013 17:43:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.48.234 with HTTP; Sun, 14 Jul 2013 17:42:53 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <51E094AB.4000105@dcrocker.net> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> From: Eric Rescorla Date: Sun, 14 Jul 2013 17:42:53 -0700 Message-ID: To: Dave Crocker Content-Type: multipart/alternative; boundary=001a11c20dfe673d8004e1822610 X-Gm-Message-State: ALoCoQmCjZHbouRiHYcMPaF8p6f2SKgdRTkUzrw0QYlwEFJsmVj0ZRRGK9C3R0/0YQlmhgJII/qg Cc: IETF STIR Mail List , Russ Housley Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 15 Jul 2013 00:43:39 -0000 --001a11c20dfe673d8004e1822610 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 12, 2013 at 4:43 PM, Dave Crocker wrote: > > >> - A fallback mechanism to allow out-of-band identity establishment >> during call setup >> > > I thought there was agreement to drop this deliverable. It seems to have > crept back in. I don't recall such an agreement. I certainly recall that there were voices on both sides. Seems like something that would be useful to discuss at the BOF. -Ekr --001a11c20dfe673d8004e1822610 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Jul 12, 2013 at 4:43 PM, Dave Crocker <= ;dhc@dcrocker.net= > wrote:


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

I thought there was agreement to drop this deliverable. =A0It seems to have= crept back in.=A0

I don't recall such = an agreement. I certainly recall that there were voices on
both s= ides. Seems like something that would be useful to discuss at the BOF.

-Ekr

--001a11c20dfe673d8004e1822610-- From dhc@dcrocker.net Sun Jul 14 18: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 E3C1C21F9C7A for ; Sun, 14 Jul 2013 18:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJRddv628oTB for ; Sun, 14 Jul 2013 18:29:13 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF6121F943C for ; Sun, 14 Jul 2013 18:29: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 r6F1T8x5008452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 14 Jul 2013 18:29:12 -0700 Message-ID: <51E35046.90202@dcrocker.net> Date: Sun, 14 Jul 2013 18:28:38 -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: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@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]); Sun, 14 Jul 2013 18:29:12 -0700 (PDT) Cc: IETF STIR Mail List Subject: Re: [stir] Draft STIR 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, 15 Jul 2013 01:29:18 -0000 On 7/14/2013 5:42 PM, Eric Rescorla wrote: > On Fri, Jul 12, 2013 at 4:43 PM, Dave Crocker > wrote: > - A fallback mechanism to allow out-of-band identity > establishment > during call setup > > I thought there was agreement to drop this deliverable. It seems to > have crept back in. > > I don't recall such an agreement. I certainly recall that there were > voices on > both sides. Seems like something that would be useful to discuss at the BOF. Why wait? Mailing lists are better for thoughtful exploration of issues. It would be quite helpful to go into the f2f meeting with a clear understanding of the issues. I suspect we lack that as of now. A number of basic concerns with an out-of-band approach have been raised and I don't recall seeing them resolved or even extensively responded to. For one thing, the meaning of term and, more importantly, the scope of the mechanism's use, have been subject to different explanations. At this point, it is not clear when it is expected to apply or with what what actors. That puts it into the category of "abstract concept" rather than "engineering task". One of the critical components to answering the above, pragmatically, is how it can be viable in concert with the pure-SIP (in-band) mechanism. One offered scenario that Jon Peterson confirmed was that it would be fully redundant with in-band, having originator set it up and callee do parallel verification. I'm not aware of any other Internet service that has attempted end-to-end redundancy. Perhaps you are? Lastly is the question of having a working group pursue two different-but-redunant solutions at the same time. I'm also not aware of that having been done successfully, but perhaps you are? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hadriel.kaplan@oracle.com Sun Jul 14 19:38: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 4329E21F9B19 for ; Sun, 14 Jul 2013 19:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.452 X-Spam-Level: X-Spam-Status: No, score=-6.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTBKseu5ypcc for ; Sun, 14 Jul 2013 19:38:13 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id D08E521F92A5 for ; Sun, 14 Jul 2013 19:38:13 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6F2cBpT004335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Jul 2013 02:38:12 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 r6F2cBXr019485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jul 2013 02:38:11 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 r6F2cAAW019482; Mon, 15 Jul 2013 02:38:10 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 14 Jul 2013 19:38: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: Date: Sun, 14 Jul 2013 22:38:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Eric Rescorla X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "stir@ietf.org" Subject: Re: [stir] Draft posted X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 15 Jul 2013 02:38:19 -0000 Questions: 1) Section 4.1 says: "The question of how an entity is determined to = have control of a given number is out of scope for this document." But that's like half the problem, if not more. Are you saying this = fallback mechanism would re-use whatever authentication mechanism/model = the in-band one uses? I.e., it could come from some database of public = keys, or some certificate signing authority chain, and either way it = doesn't matter to this fallback thing? I have a hard time understanding how that would work in practice. The = in-band mechanism's number authentication/credentials model has so far = assumed private/public keys... and that realistically an end user/device = wouldn't have a private key for the phone number, but that its service = provider or carrier would instead. So if the fallback is meant for = carriers to be the "Alice" and "Bob", I would understand how the same = authentication/credentials model of in-band could possibly work for = fallback. But not if Alice and Bob are truly end users/devices. On the other hand, for a real end-user model, I could see very different = authentication models used: for example by having Alice sign up for the = CPS service, and part of the sign-up process being the CPS calling her = phone or sending her an SMS, using the claimed phone number, and giving = her some cookie to type/copy into the CPS' app to complete the sign-up = process authentication. After that her app would always have = credentials to claim her number, though it would have to be renewed once = a year or something. And of course Bob would have to do the same, since = you can't let just anyone ask if Alice is calling Bob. But those types of details make a big difference for this stuff. As = I've said before on the list: if the fallback is meant for end-user = smartphones/apps, I grok that something we define could be useful in = *theory*; but I don't think we know if something we define would be = useful in *practice*. I don't know if it is actually needed by those = who would deploy it, nor if it works the way they'd want it to work, = with the features they'd want it to have. In short: we don't have the = right people involved in STIR for that type of thing. We'd just be = shooting in the dark. 2) How would this thing handle call-forwarding scenarios? It's a nasty, = ugly, brutal scenario even for in-band to handle... but I think it has = to be handled. (as much as I wish it were otherwise) 3) What are the odds that Alice and Bob happen to use the same CPS = service? Would there be only one? Who decides who that Highlander CPS = is? If it follows a "Federated Verification Service" model instead, = where everyone uses their favorite CPS service and the CPS providers = interconnect some way, why isn't that just either re-creating the PSTN = using a protocol other than SIP, or even just re-creating the existing = SIP service provider interconnection world of today? I mean that's = essentially what section 5.5 proposes to do. Or worse, it's like VIPR = all over again, without learning the lessons from VIPR's failure. Maybe = the fallback thing could be called "VIPRedux"? ;) -hadriel On Jul 14, 2013, at 8:37 PM, Eric Rescorla wrote: > Folks, >=20 > I have posted a -00 draft that provides a high-level description of > how one might do STIR out-of-band mode. I've deliberately > cut out a lot of the detail of the previous version and/or > relegated it to a separate section. The idea here is to look > at the big picture. >=20 > http://tools.ietf.org/html/draft-rescorla-stir-fallback-00 >=20 > -Ekr >=20 >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From jon.peterson@neustar.biz Sun Jul 14 20:26:41 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE8121F9AB3 for ; Sun, 14 Jul 2013 20:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.278 X-Spam-Level: X-Spam-Status: No, score=-106.278 tagged_above=-999 required=5 tests=[AWL=0.321, 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 AuJbekQ+TtCG for ; Sun, 14 Jul 2013 20:26:37 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id B37F921F9980 for ; Sun, 14 Jul 2013 20:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1373858684; x=1689217630; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=sMujlHXPsr 7E7iRZylHUxoSGCp+y90YQqH3hbli5VCo=; b=Iy519kZ4CWevhbzmKvmpfPaK5t ZodWSkaPTs7OeekE45Hl5EmdrgrEtu6YHoDj7Y3HVKofY+7NZaC9L8Ucwkyw== Received: from ([10.31.58.70]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.20873722; Sun, 14 Jul 2013 23:24:42 -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, 14 Jul 2013 23:26:10 -0400 From: "Peterson, Jon" To: "dcrocker@bbiw.net" , Eric Rescorla Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkICx1fsldqNdEa1H4oCYTQLxplgBgeAgAAEgQCAAANuAIAAAaEAgAAGyYCAAAH6AIAABkaAgAACpAD//5iRAIAAd2uAgADroICAAEL+gIAAAeAAgABhRQCAAB8HgIAADPaAgAAKzoCAAzU2gIAADMkA//+reQA= Date: Mon, 15 Jul 2013 03:26:08 +0000 Message-ID: In-Reply-To: <51E35046.90202@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: oO1Xef+DwMt8v2pVN73v0w== Content-Type: text/plain; charset="us-ascii" Content-ID: <23D43265B2809F4F88833FFC8FE0573A@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF STIR Mail List Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 15 Jul 2013 03:26:41 -0000 I don't believe I've "confirmed" on the list that out-of-band would be fully redundant with in-band. Instead, what I've said is that there are different applicabilities for these two proposed mechanisms. I don't think anyone could reasonably maintain that an in-band solution for SIP would be a complete solution for the robocalling or voicemail hacking out there in the wild today. At best, in-band handles IP-to-IP cases, and maybe (if it were cast something like Hadriel's ikes draft) it could handle IP-to-something-to-IP cases. There are however plenty of IP-to-PSTN cases, and PSTN-to-PSTN cases. In fact, those two would seem to be the dominant use cases for calls for the foreseeable future. What I have said in the past that may have confused you is that I envisioned that an authentication service (i.e., the originating side) that supported both in-band and out-of-band should ideally use both, since it couldn't anticipate which would work, as callers can't anticipate where calls will land and what the intervening network or capabilities at the terminating side will be. But of course, if the originating side isn't signaling SIP, then you're not going to be doing in-band from originating side, say. So no, it's not in any meaningful sense "fully redundant." And again, this is just based on my own sketch of how the two mechanisms might interact. Maybe we could do better. To me, this out-of-band question is a question about the problem we're aiming to solve, not the solution mechanisms. Are we going to try to do anything about the parts of the robocalling and voicemail hacking problem where SIP is not the protocol used on both side, or are we going to skip that? And if the latter, are we addressing enough of the problem for this to be worth our effort? Jon Peterson Neustar, Inc. On 7/14/13 6:28 PM, "Dave Crocker" wrote: >On 7/14/2013 5:42 PM, Eric Rescorla wrote: >> On Fri, Jul 12, 2013 at 4:43 PM, Dave Crocker > > wrote: >> - A fallback mechanism to allow out-of-band identity >> establishment >> during call setup >> >> I thought there was agreement to drop this deliverable. It seems to >> have crept back in. >> >> I don't recall such an agreement. I certainly recall that there were >> voices on >> both sides. Seems like something that would be useful to discuss at the >>BOF. > > >Why wait? Mailing lists are better for thoughtful exploration of >issues. It would be quite helpful to go into the f2f meeting with a >clear understanding of the issues. I suspect we lack that as of now. > >A number of basic concerns with an out-of-band approach have been raised >and I don't recall seeing them resolved or even extensively responded to. > >For one thing, the meaning of term and, more importantly, the scope of >the mechanism's use, have been subject to different explanations. At >this point, it is not clear when it is expected to apply or with what >what actors. That puts it into the category of "abstract concept" >rather than "engineering task". > >One of the critical components to answering the above, pragmatically, is >how it can be viable in concert with the pure-SIP (in-band) mechanism. >One offered scenario that Jon Peterson confirmed was that it would be >fully redundant with in-band, having originator set it up and callee do >parallel verification. I'm not aware of any other Internet service that >has attempted end-to-end redundancy. Perhaps you are? > >Lastly is the question of having a working group pursue two >different-but-redunant solutions at the same time. I'm also not aware >of that having been done successfully, but perhaps you are? > > >d/ > >--=20 >Dave Crocker >Brandenburg InternetWorking >bbiw.net >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From dhc@dcrocker.net Sun Jul 14 20:52: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 AA37C21F9B19 for ; Sun, 14 Jul 2013 20:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.429 X-Spam-Level: X-Spam-Status: No, score=-6.429 tagged_above=-999 required=5 tests=[AWL=-0.163, 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 zAmCwyKEI0el for ; Sun, 14 Jul 2013 20:51:56 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9438C21F89C3 for ; Sun, 14 Jul 2013 20:51:56 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r6F3pqGX010312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 14 Jul 2013 20:51:56 -0700 Message-ID: <51E371BA.9060009@dcrocker.net> Date: Sun, 14 Jul 2013 20:51: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: "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, 14 Jul 2013 20:51:56 -0700 (PDT) Cc: IETF STIR Mail List Subject: Re: [stir] Draft STIR 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, 15 Jul 2013 03:52:01 -0000 On 7/14/2013 8:26 PM, Peterson, Jon wrote: > > I don't believe I've "confirmed" on the list that out-of-band would be > fully redundant with in-band. Actually, you did: >> Subject: Re: [stir] Out-of-band vs. in-band >> Date: Mon, 24 Jun 2013 17:18:01 +0000 >> From: Peterson, Jon >> To: dcrocker@bbiw.net >> CC: stir@ietf.org >> .... >> 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. That describes usage that is fully redundant. Perhaps you didn't mean it or that you meant something else. This merely underscores the confusion I cited about what exactly is meant by an out-of-band mechanism, who it's actors would be and when it would be used -- I'll also toss in how the actors will know they are to use it. Without a fair sense of answers to all of the above, we can't have any idea what the engineering challenges for the mechanism will be, or even whether the mechanism is viable. > Instead, what I've said is that there are > different applicabilities for these two proposed mechanisms. So sometimes use one, sometimes use the other, sometimes use both? There's a nice term for such an approach and, I might add, quite a bit of experience with its applicability. The term is "non-interoperable'. > I don't think > anyone could reasonably maintain that an in-band solution for SIP would be > a complete solution for the robocalling or voicemail hacking out there in > the wild today. Right. So it's a good thing, indeed, that no one has attempted to maintain that, isn't it? > What I have said in the past that may have confused you is that I > envisioned that an authentication service (i.e., the originating side) > that supported both in-band and out-of-band should ideally use both, And you don't think that makes it fully redundant for the caller? (And fully redundant for /some/ callees.) > To me, this out-of-band question is a question about the problem we're > aiming to solve, not the solution mechanisms. Are we going to try to do > anything about the parts of the robocalling and voicemail hacking problem > where SIP is not the protocol used on both side, or are we going to skip > that? And if the latter, are we addressing enough of the problem for this > to be worth our effort? So a proposed solution isn't about solutions but about the problem? Sorry, but I've no idea what this paragraph means or how it responds. Really, my note asked very simple, very basic technical questions about the out-of-band 'proposal'. Very simple. Very basic. For those promoting an immediate effort at producing an out-of-band solution, the answers also out to be very simple and basic. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From philippe.fouquart@orange.com Mon Jul 15 03:08: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 A333721E8096 for ; Mon, 15 Jul 2013 03:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, 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 WxWM9fJ7rmz1 for ; Mon, 15 Jul 2013 03:07:54 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 75CB221F8546 for ; Mon, 15 Jul 2013 03:07:34 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id BF01D3B4560; Mon, 15 Jul 2013 12:07:33 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 9D80D27C4E1; Mon, 15 Jul 2013 12:07:33 +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, 15 Jul 2013 12:07:33 +0200 From: To: Russ Housley , IETF STIR Mail List Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIC/Xfx9OM2CUaqk2gsBTAQDJlfoXKAgAAEgQCAAANtAIAAAaIAgAAGyICAAAH7AIAABkaAgAACpACAAA3sAIAAAhCAgADroICAAEL+gIAAAeAAgABhRACAAB8HgIAADPeAgAP0mpA= Date: Mon, 15 Jul 2013 10:07:31 +0000 Message-ID: <30484_1373882853_51E3C9E5_30484_344_1_B5939C6860701C49AA39C5DA5189448B0B43A1@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@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.2] 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.7.1.45418 Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 15 Jul 2013 10:08:02 -0000 It looks good to me. Probably a minor point, but where the second paragraph= reads: Several factors contributed to this lack of success, including: [...] lack = of any real means of asserting authority over telephone numbers; I'd prefer something like: "lack of any technical means of producing a proof of authority over telepho= ne numbers"=20 The point being that strictly speaking and contrary to what the text seems = to imply, there are real means of asserting the authority over a number ran= ge, luckily enough: for many numbering plans, there's an NRA ruling for num= ber ranges, generally made public, sometimes on-line, there are NPDBs when = numbers are portable... So, depending on the number, both would provide a r= eal means with which the authority over a number (range) can be asserted. T= he problem, however, is that there's indeed no technical way of producing (= , conveying for in-band) and checking that proof of authority 'over the wir= e', which make these 'real means' technically unfit for the purpose describ= ed in the first/second paragraph.=20 Apologies, this could have gone with the first round.=20 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 Rus= s Housley Sent: Saturday, July 13, 2013 1:05 AM To: IETF STIR Mail List Subject: Re: [stir] Draft STIR Charter I have tried to pull all of the discussion into an updated charter.=A0 I ha= ve also attached a diff to make it easier to review. Russ =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D Name: Secure Telephone Identity Revisited (stir) Area: RAI Chairs: TBD Area Advisor: Richard Barnes Mailing list: stir@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/stir 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.=A0 As with email, the claimed source identity of a SIP request is not verified, and this permits unauthorized use of source identities as part of deceptive and coercive activities, such as robocalling (bulk unsolicited commercial communications), vishing (voicemail hacking, and impersonating banks) and swatting (impersonating callers to emergency services to stimulate unwarranted large scale law enforcement deployments).=A0 This working group will define a deployable mechanism to validate the identity of the calling party that can be verified by entities in the path of a call. SIP is one of the main VoIP technologies used by parties that want to present an incorrect origination.=A0 Several previous efforts have tried to secure the origins of SIP communications, including RFC 3325, RFC 4474, and the VIPR working group.=A0 To date, however, true validation of the source of SIP calls has not seen any appreciable deployment.=A0 Several factors contributed to this lack of success, including: failure of the problem to be seen as critical at the time; lack of any real means of asserting authority over telephone numbers; misalignment of the mechanisms proposed by RFC 4474 with the complex deployment environment that has emerged for SIP; lack of end-to-end SIP session establishment; and inherent operational problems with a transitive trust model.=A0 To make deployment of this solution more likely, consideration must be given to user experience as well as overhead for the call source and all verifiers. As its first work item, the working group will specify an in-band mechanism to authenticate the originator of a SIP session where the identity being authenticated is a telephone number and the session is established with SIP end to end.=A0 The mechanism will use a canonical telephone number representation specified by the working group, including any mappings that might be needed between the SIP header fields and the canonical telephone number representation.=A0 The working group will consider choices for protecting the identity information and the credentials used, but will likely be based on a digital signature mechanism that covers a set of information in the SIP headers, and verification will employ a credential that contains the public key and is associated with the identity.=A0 In order to be authoritative, credentials used with this mechanism will be derived from existing telephone number assignment and delegation models.=A0 That is, when a telephone number or range of telephone numbers is delegated to an entity, relevant credentials will be generated (or modified) to reflect such delegation. The mechanism must allow parties who are not delegated a telephone number, but are preauthorized by the entity who is delegated the number, to place calls using the identity.=A0 Expansion of the authentication mechanism to identities using the user@domain form should be considered in the initial design, but the main focus of the working group is to develop a solution for telephone numbers.=A0 After completing the SIP end to end solution, the working group will consider session establishment where there are one or more non-SIP hops, most likely using an out-of-band authentication mechanism.=A0 However, the in-band and out-of-band mechanisms should share as much in common as possible, especially the credentials. The working group will coordinate with the Security Area on credential management. The working group will coordinate with other working groups in the RAI Area regarding signaling through existing deployments. Authenticated identity is closely linked to privacy, and one frequently comes at the cost of the other.=A0 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. 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-dispatch-rfc4474bis-00 The working group will deliver the following: =A0 - A problem statement detailing the deployment environment and =A0=A0=A0 situation that motivate work on secure telephone identity =A0 - A mechanism document describing the SIP end-to-end with telephone =A0=A0=A0=A0 number-based identities=20 =A0 - A document describing the credentials required to support secure =A0=A0=A0 telephone identity =A0 - A fallback mechanism to allow out-of-band identity establishment =A0=A0=A0 during call setup Milestones Sep 2013=A0=A0 Submit problem statement for Informational Nov 2013=A0=A0 Submit in-band mechanism for Proposed Standard Feb 2014=A0=A0 Submit credential specification for Proposed Standard Jun 2014=A0=A0 Submit fallback for Proposed Standard _______________________________________________ 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 michael.hammer@yaanatech.com Mon Jul 15 06: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 7A1BC21F9F3A for ; Mon, 15 Jul 2013 06:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 TvWbW6bVZGUg for ; Mon, 15 Jul 2013 06:54: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 0F7E221F9D62 for ; Mon, 15 Jul 2013 06:54:16 -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, 15 Jul 2013 06:54:14 -0700 From: Michael Hammer To: "dcrocker@bbiw.net" , "housley@vigilsec.com" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIBWXEGbn3ibkCpY0NkPYfuGZlgOFKAgAAEgQCAAANtAIAAAaEAgAAGyYCAAAH7AIAABkaA//+MAvCAAISOAIAAAhCAgADroICAAEL9gIAAAeEAgABhRACAAB8HgIAADPeAgAAKzoCAA5ym0A== Date: Mon, 15 Jul 2013 13:54:13 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC163D7@EX2K10MB1.corp.yaanatech.com> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> In-Reply-To: <51E094AB.4000105@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_0013_01CE8141.4246B2F0" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 15 Jul 2013 13:54:21 -0000 ------=_NextPart_000_0013_01CE8141.4246B2F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit +1 Especially about authorization. I thought that was the #1 point. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dave Crocker Sent: Friday, July 12, 2013 7:44 PM To: Russ Housley Cc: IETF STIR Mail List Subject: Re: [stir] Draft STIR Charter Meta-point: The text is only about authentication, but the discussion has been about authorization. For example one might have an authenticated originator value that is not the string displayed as Caller-ID.[*] I understood the purpose of the wg to be ensuring that the displayed string was authorized by its assignee. If no one cares about this distinction and everyone feels that "authenticate the originator" is sufficiently precise and accurate, fine, but I thought it worth making sure. > To make > deployment of this solution more likely, consideration must be given > to user experience as well as overhead for the call source and all > verifiers. In this form, the text is sufficiently generic so that it applies to essentially all protocol work ever done in the IETF. It would help to have it provide some substantive guidance and/or constraint. The list that was developed in the earlier discussion seemed reasonable for this: To ensure usability, consideration will be given to computational and administrative overhead, exchange latency, and real-time performance within call-setup limits. > As its first work item, the working group will specify an in-band > mechanism to authenticate the originator of a SIP session where the > identity being authenticated is a telephone number and the session is Thinking about having someone read this who hasn't already tracked the discussion: The meaning of 'in-band' might not be at all obvious. Perhaps: the working group will specify a mechanism to authenticate the originator of a SIP session, where the identity being authenticated is a telephone number based on information in SIP headers, the session is established end to end, and the mechanism works within the SIP session (in-band). The reference to SIP headers is core to what's been discussed and it provides context for the reference in the next sentence. > established with SIP end to end. The mechanism will use a canonical > telephone number representation specified by the working group, including > any mappings that might be needed between the SIP header fields and the > canonical telephone number representation. The working group will > consider choices for protecting the identity information and the > credentials used, but will likely be based on a digital signature > mechanism that covers a set of information in the SIP headers, and > verification will employ a credential that contains the public key and is > associated with the identity. In order to be authoritative, credentials > used with this mechanism will be derived from existing telephone number > assignment and delegation models. That is, when a telephone number or > range of telephone numbers is delegated to an entity, relevant > credentials will be generated (or modified) to reflect such delegation. > The mechanism must allow parties who are not delegated a telephone > number, but are preauthorized by the entity who is delegated the number, preauthorized -> authorized The 'pre' actually confused me for awhile > to place calls using the identity. Expansion of the authentication > mechanism to identities using the user@domain form should be considered > in the initial design, but the main focus of the working group is to > develop a solution for telephone numbers. After completing the SIP end 'Considered...but main focus' essentially calls for solving the issue in the current effort. Instead: Expansion of the authentication mechanism to identifiers using the user@domain form is deferred. This creates awareness of the issue and implies an intent to deal with it (later). > to end solution, the working group will consider session establishment > where there are one or more non-SIP hops, most likely using an > out-of-band authentication mechanism. However, the in-band and > out-of-band mechanisms should share as much in common as possible, > especially the credentials. These two draft sentence essentially require defining an out-of-band mechanism; if they don't they are meaningless or a distraction. Instead: Consideration of out-of-band mechanisms, to deal with transit across non-SIP hops, is deferred. > The working group will coordinate with the Security Area on credential > management. On advice of others, the draft text I had circulated for this was: 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 other working groups in the RAI > Area regarding signaling through existing deployments. > > Authenticated identity is closely linked to privacy, and one frequently > 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. > > 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 > > The working group will deliver the following: > > - A problem statement detailing the deployment environment and > situation that motivate work on secure telephone identity > > - A mechanism document describing the SIP end-to-end with telephone > number-based identities > > - A document describing the credentials required to support secure > telephone identity 'secure'? that's quite generic, and probably far beyond the scope of this working group. > > - A fallback mechanism to allow out-of-band identity establishment > during call setup I thought there was agreement to drop this deliverable. It seems to have crept back in. > Milestones > > Sep 2013 Submit problem statement for Informational > Nov 2013 Submit in-band mechanism for Proposed Standard > Feb 2014 Submit credential specification for Proposed Standard > Jun 2014 Submit fallback for Proposed Standard ditto. [*] Since provides such a wealth of odd experience, I'll note that DKIM is an example of creating an authenticated identifier that says nothing about the author address. -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_0013_01CE8141.4246B2F0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NTEzNTQxMlowIwYJKoZIhvcNAQkEMRYEFDc7f9NZM7A9IeDKIX8KKLs+8vnNMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAG+TX+AK63LimMQBd+vm0iFIcrI0CtF4ufTRAfdbq WiQbW4TLEd+2JR6drCkMF4yGmqNx1gzJuyFBVIRSR8osymBtbBlnP1PmKCnt1KMvBgvUSqctPOk0 4+LxKN+hbk2rAV25G4WjKqU1dO7iItbAdID+X6zSh9fDmBXUDRo4VCx49e301N533pQl/H29u/6H ggE5WHPtR0+ffl2tlqAXvHx6fqBeQV8Y69Y6u385+WTHX3llQ31kAhOYINxFurx0mr/vfiQxuo+Q 6PIfmQikPU2SquHAhkV6QM+I1K3q6RWsTQ8ES/xbd9LW7W6F6n/mmMaekSTq4XYGyCm/cudzqQAA AAAAAA== ------=_NextPart_000_0013_01CE8141.4246B2F0-- From hadriel.kaplan@oracle.com Mon Jul 15 11:43: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 C506A11E81BF for ; Mon, 15 Jul 2013 11:43:16 -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 p6Fp0ufUguyC for ; Mon, 15 Jul 2013 11:43:10 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 28A5511E817C for ; Mon, 15 Jul 2013 11:43: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 r6FIgums002457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Jul 2013 18:42:57 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 r6FIgsut026861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jul 2013 18:42: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 r6FIgsru026947; Mon, 15 Jul 2013 18:42:54 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 15 Jul 2013 11:42: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: <51E094AB.4000105@dcrocker.net> Date: Mon, 15 Jul 2013 14:42:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3145728A-87FA-4217-9B93-E14A01307784@oracle.com> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: IETF STIR Mail List , Russ Housley Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 15 Jul 2013 18:43:16 -0000 On Jul 12, 2013, at 7:43 PM, Dave Crocker wrote: > Meta-point: >=20 > The text is only about authentication, but the discussion has been = about authorization. For example one might have an authenticated = originator value that is not the string displayed as Caller-ID.[*] I = understood the purpose of the wg to be ensuring that the displayed = string was authorized by its assignee. >=20 > If no one cares about this distinction and everyone feels that = "authenticate the originator" is sufficiently precise and accurate, = fine, but I thought it worth making sure. It took me a while to grok what you mean, because from my perspective = STIR is about verifying the received Caller-ID is authentic for a given = call request, and authenticating it to be so - not that STIR is = authorizing the originator to make a call. But really what you mean is = STIR is about verifying the originator of the call request is authorized = to use the claimed caller-id. How about this: As its first work item, the working group will specify a SIP=20 header-field-based mechanism to verify the originator of a=20 SIP session is authorized to use the claimed source identifier,=20 where the identity is a telephone number and the session is=20 established with SIP end to end. -hadriel From richard@shockey.us Mon Jul 15 11:54: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 3B71F11E820D for ; Mon, 15 Jul 2013 11:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.716 X-Spam-Level: X-Spam-Status: No, score=-101.716 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, FB_YOUR_REFI=0.333, 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 z3V98EDpBpDR for ; Mon, 15 Jul 2013 11:54:42 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 9916411E8208 for ; Mon, 15 Jul 2013 11:54:35 -0700 (PDT) Received: (qmail 10308 invoked by uid 0); 15 Jul 2013 18:45:32 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy14.unifiedlayer.com with SMTP; 15 Jul 2013 18:45: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=Kg0vUdtj/AVOfsTP/GY61rWdMV5+hdYALmNQudmf5/k=; b=JIa5Xw0ll7bU+zKVsclDquj41rpsokVNzmugii5/VKed6r+BDNn4cjR3H+7O8UvUmbvJKJS4P+9OVI4ITcgA7LuQwu4PFJBLRl/e0w6aLWOHHlGoPBICXDXpIEnJsCMY; Received: from [72.66.111.124] (port=54470 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Uynm7-0002Dq-Uc; Mon, 15 Jul 2013 12:45:32 -0600 From: "Richard Shockey" To: , "'Peterson, Jon'" References: <51E371BA.9060009@dcrocker.net> In-Reply-To: <51E371BA.9060009@dcrocker.net> Date: Mon, 15 Jul 2013 14:45:30 -0400 Message-ID: <011601ce818b$7bdd48e0$7397daa0$@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: AQL/BCbN34pvssG/zmP8Y9dsYJE+5AHGECHJlvbVrHA= 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: 'IETF STIR Mail List' Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 15 Jul 2013 18:54:54 -0000 You know I have to agree with Dave here. The central problem with any out of band mechanism is trying to understand if its is actually deployable. First the existing TDM Class infrastructure is not going to be modified in any way shape or form. That has to be considered a given here. The conversion of the PSTN to the Public SIP Telephony Network is progressing a breathtaking pace. I would hazard a guess that fully 50% or more of all voice in the US will use SIP/IMS in the core within 3 years once the conversion of the mobile networks to VoLTE begins and it is coming. I read EKR's draft with some amusement since it attempts, again to rely on endpoints actually being intelligent, when in fact they may not be and the vast majority of SIP endpoints will continue to be "black phone B2BUA's" with SIP used for switching and interconnection. This will certainly be true in residential and SMB markets. This is what is happening in the market today with anyone with a voice service from Cable Operator, ATT Verizon etc that have "digital voice services". Not to mention I'm equally skeptical such validation methods will reach the smartphone handsets. This statement is simply incorrect. "While the core network of the PSTN remains fixed, the endpoints of the telephone network are becoming increasingly programmable and sophisticated. Landline "plain old telephone service" deployments, especially in the developed world, are shrinking, and increasingly being replaced by three classes of intelligent devices: smart phones, IP PBXs, and terminal adapters. All three are general purpose computers, and typically all three have Internet access as well as access to the PSTN. This provides a potential avenue for building an authentication system that changes only the endpoints while leaving the PSTN intact." I take it you have a unlimited data roaming plan? I have enormous trouble believing for one instant that CUA's are going to play a meaningful role in Validation/Authentication/Authorization. IMHO this is a network service. To additionally postulate that consumers and business are going to sign up for some rendezvous call placement service is almost preposterous. That is what a SIP proxy CSCF should do and I'm happy to pay Verizon etal to do that. That is why they are called "service providers" irrespective of what the access device is and what the last mile infrastructure is. I'm certainly willing to listen to ideas about out of band solutions especially at the wholesale carrier GW layer. But right now its clear to me the shortest first path to success is defining what in band looks like within the SIP headers so it's possible to move on to the real heavy lifting of what the directory look up system might look like. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dave Crocker Sent: Sunday, July 14, 2013 11:51 PM To: Peterson, Jon Cc: IETF STIR Mail List Subject: Re: [stir] Draft STIR Charter On 7/14/2013 8:26 PM, Peterson, Jon wrote: > > I don't believe I've "confirmed" on the list that out-of-band would be > fully redundant with in-band. Actually, you did: >> Subject: Re: [stir] Out-of-band vs. in-band >> Date: Mon, 24 Jun 2013 17:18:01 +0000 >> From: Peterson, Jon >> To: dcrocker@bbiw.net >> CC: stir@ietf.org >> .... >> 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. That describes usage that is fully redundant. Perhaps you didn't mean it or that you meant something else. This merely underscores the confusion I cited about what exactly is meant by an out-of-band mechanism, who it's actors would be and when it would be used -- I'll also toss in how the actors will know they are to use it. Without a fair sense of answers to all of the above, we can't have any idea what the engineering challenges for the mechanism will be, or even whether the mechanism is viable. > Instead, what I've said is that there are different applicabilities > for these two proposed mechanisms. So sometimes use one, sometimes use the other, sometimes use both? There's a nice term for such an approach and, I might add, quite a bit of experience with its applicability. The term is "non-interoperable'. > I don't think > anyone could reasonably maintain that an in-band solution for SIP would be > a complete solution for the robocalling or voicemail hacking out there in > the wild today. Right. So it's a good thing, indeed, that no one has attempted to maintain that, isn't it? > What I have said in the past that may have confused you is that I > envisioned that an authentication service (i.e., the originating side) > that supported both in-band and out-of-band should ideally use both, And you don't think that makes it fully redundant for the caller? (And fully redundant for /some/ callees.) > To me, this out-of-band question is a question about the problem we're > aiming to solve, not the solution mechanisms. Are we going to try to do > anything about the parts of the robocalling and voicemail hacking problem > where SIP is not the protocol used on both side, or are we going to skip > that? And if the latter, are we addressing enough of the problem for this > to be worth our effort? So a proposed solution isn't about solutions but about the problem? Sorry, but I've no idea what this paragraph means or how it responds. Really, my note asked very simple, very basic technical questions about the out-of-band 'proposal'. Very simple. Very basic. For those promoting an immediate effort at producing an out-of-band solution, the answers also out to be very simple and basic. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From michael.hammer@yaanatech.com Mon Jul 15 11:56: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 25EAB21E80E1 for ; Mon, 15 Jul 2013 11:56:01 -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.073, 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 qUyvvV8xKOEz for ; Mon, 15 Jul 2013 11:55:50 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id C190411E81CE for ; Mon, 15 Jul 2013 11:55:45 -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, 15 Jul 2013 11:55:42 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" , "dcrocker@bbiw.net" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIBWXEGbn3ibkCpY0NkPYfuGZlgOFKAgAAEgQCAAANtAIAAAaEAgAAGyYCAAAH7AIAABkaA//+MAvCAAISOAIAAAhCAgADroICAAEL9gIAAAeEAgABhRACAAB8HgIAADPeAgAAKzoCABGLzgP//jdEg Date: Mon, 15 Jul 2013 18:55:41 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC16DAD@EX2K10MB1.corp.yaanatech.com> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> <3145728A-87FA-4217-9B93-E14A01307784@oracle.com> In-Reply-To: <3145728A-87FA-4217-9B93-E14A01307784@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.65] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0038_01CE816B.5FC20E40" MIME-Version: 1.0 Cc: "stir@ietf.org" , "housley@vigilsec.com" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 15 Jul 2013 18:56:03 -0000 ------=_NextPart_000_0038_01CE816B.5FC20E40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Would you want to say: "to verify the *authenticated* originator" Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Monday, July 15, 2013 2:43 PM To: dcrocker@bbiw.net Cc: IETF STIR Mail List; Russ Housley Subject: Re: [stir] Draft STIR Charter On Jul 12, 2013, at 7:43 PM, Dave Crocker wrote: > Meta-point: > > The text is only about authentication, but the discussion has been about authorization. For example one might have an authenticated originator value that is not the string displayed as Caller-ID.[*] I understood the purpose of the wg to be ensuring that the displayed string was authorized by its assignee. > > If no one cares about this distinction and everyone feels that "authenticate the originator" is sufficiently precise and accurate, fine, but I thought it worth making sure. It took me a while to grok what you mean, because from my perspective STIR is about verifying the received Caller-ID is authentic for a given call request, and authenticating it to be so - not that STIR is authorizing the originator to make a call. But really what you mean is STIR is about verifying the originator of the call request is authorized to use the claimed caller-id. How about this: As its first work item, the working group will specify a SIP header-field-based mechanism to verify the originator of a SIP session is authorized to use the claimed source identifier, where the identity is a telephone number and the session is established with SIP end to end. -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_0038_01CE816B.5FC20E40 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NTE4NTU0MFowIwYJKoZIhvcNAQkEMRYEFIaehGG1Zb1AF4ngOIDLHLmChxImMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEANWzlSUIoUvhnzh1TASx+nazfErClQfs+M4v7aw7y sK9Ev7XW4kgv+8J/LkktTloeHlrdeFgLyO7IHvVupvSlqyL2Ifn8D8mXv1y7Wma+TqOMhe7SNxbQ hNmMVTvXpl26jX7bh8CxxwnfXutzoCg083UdNzIZJ91jN4/17ugQJnOXL8yA9L2ibv6MAPOrBy8E 2NXdZXYR8KN7wBRR/mChM6t9Iigr0EvEuYJ44r4IAy17MwtgPTaOSDA2NzUxLZmo4YcXW1tQ01Pd 088+nHZ9g8Yioz7sJPLMSjADHFJc+E3ifJuoO1lTWq6nEFjJigrcBLhGrSPZTfdUghoTDjgw/AAA AAAAAA== ------=_NextPart_000_0038_01CE816B.5FC20E40-- From matthew.cannon@twcable.com Mon Jul 15 12: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 7086511E820F for ; Mon, 15 Jul 2013 12:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.463 X-Spam-Level: X-Spam-Status: No, score=-1.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 N21ytXPihA3B for ; Mon, 15 Jul 2013 12:07:52 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 3D53411E821D for ; Mon, 15 Jul 2013 12:07:35 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.89,670,1367985600"; d="scan'208";a="107888440" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 15 Jul 2013 15:07:00 -0400 Received: from PRVPEXVS02.corp.twcable.com ([10.136.163.25]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Mon, 15 Jul 2013 15:07:33 -0400 From: "Cannon, Matthew" To: Hadriel Kaplan , "dcrocker@bbiw.net" Date: Mon, 15 Jul 2013 15:07:31 -0400 Thread-Topic: [stir] Draft STIR Charter Thread-Index: Ac6Bjo7qaEszqdQ6Rk+7VZWKICKuiQ== Message-ID: In-Reply-To: <3145728A-87FA-4217-9B93-E14A01307784@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF STIR Mail List , Russ Housley Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 15 Jul 2013 19:07:56 -0000 It seems to me that there is a pretty large implication to this small change in wording. Providing a SIP header mechanism that allows a called party to authenticate the claimed source identifier was really provide by the originator is very different than a header that lets a called party authenticate that the claimed source identifier was really provide by the originator and that the originator is authorized to use that source identifier. Considering the various national variations on how a service provider is 'authorized' to represent a callers TN in an originating call, this might be more than a bit of a challenge as far as a solution goes. matt On 7/15/13 2:42 PM, "Hadriel Kaplan" wrote: > >On Jul 12, 2013, at 7:43 PM, Dave Crocker wrote: > >> Meta-point: >> >> The text is only about authentication, but the discussion has been >>about authorization. For example one might have an authenticated >>originator value that is not the string displayed as Caller-ID.[*] I >>understood the purpose of the wg to be ensuring that the displayed >>string was authorized by its assignee. >> >> If no one cares about this distinction and everyone feels that >>"authenticate the originator" is sufficiently precise and accurate, >>fine, but I thought it worth making sure. > >It took me a while to grok what you mean, because from my perspective >STIR is about verifying the received Caller-ID is authentic for a given >call request, and authenticating it to be so - not that STIR is >authorizing the originator to make a call. But really what you mean is >STIR is about verifying the originator of the call request is authorized >to use the claimed caller-id. > >How about this: > As its first work item, the working group will specify a SIP > header-field-based mechanism to verify the originator of a > SIP session is authorized to use the claimed source identifier, > where the identity is a telephone number and the session is > established with SIP end to end. > >-hadriel > > > > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From Henning.Schulzrinne@fcc.gov Mon Jul 15 12:11: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 EEE6121E813E for ; Mon, 15 Jul 2013 12:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.711 X-Spam-Level: X-Spam-Status: No, score=-1.711 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, FB_YOUR_REFI=0.333, 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 JbjYbwibkdBm for ; Mon, 15 Jul 2013 12:11: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 CF15B11E821D for ; Mon, 15 Jul 2013 12:11:32 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Richard Shockey' , "dcrocker@bbiw.net" , "'Peterson, Jon'" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIF2w2hhDzu+kKP+YqzEEYfuplgBgeAgAAEgQCAAANuAIAAAaEAgAAGyYD//73RMIAABfoQgABHGQCAAA3sAIAAAhCAgADroICAAEL+gIAAAeAAgABhRQCAAB8HgIAADPaAgAAKzoCAAzU2gIAADMkAgAAg1ACAAAcNAIAA+dEA///B8xA= Date: Mon, 15 Jul 2013 19:11:31 +0000 References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> In-Reply-To: <011601ce818b$7bdd48e0$7397daa0$@shockey.us> 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: 'IETF STIR Mail List' Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 15 Jul 2013 19:11:37 -0000 Today, millions of users subscribe to end-system based call filtering and r= ating services on smart phones, so there is some existence proof that they = fulfill a need, however limited these service are by necessity. There are a= t least a dozen such apps available on the various app stores. Given that m= ore than half of all cell phones are smartphones, this is not a trivial mar= ket, recognizing that it doesn't help many users. I suspect we'd all prefer a solution that achieves 100% coverage by network= providers, sooner rather than later. Some may prefer a solution that offer 80% coverage by network providers sup= plemented by 15% by end-to-end solutions to leaving those 20% exposed to th= e tender mercies of Rachel from Credit Card Services. Rather than a somewhat-unhelpful discussion on general principles, maybe it= would be more conducive to forward progress to see how we can deal with va= rious kinds of non-implementation by having mechanisms that work together, = e.g., share the keying/certificate infrastructure, and maybe even other com= ponents.=20 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Ric= hard Shockey Sent: Monday, July 15, 2013 2:46 PM To: dcrocker@bbiw.net; 'Peterson, Jon' Cc: 'IETF STIR Mail List' Subject: Re: [stir] Draft STIR Charter You know I have to agree with Dave here. The central problem with any out = of band mechanism is trying to understand if its is actually deployable.=20 First the existing TDM Class infrastructure is not going to be modified in = any way shape or form. That has to be considered a given here. The conversion of the PSTN to the Public SIP Telephony Network is progressi= ng a breathtaking pace. I would hazard a guess that fully 50% or more of al= l voice in the US will use SIP/IMS in the core within 3 years once the conv= ersion of the mobile networks to VoLTE begins and it is coming. I read EKR's draft with some amusement since it attempts, again to rely on = endpoints actually being intelligent, when in fact they may not be and the = vast majority of SIP endpoints will continue to be "black phone B2BUA's" with SIP used for switching and interconnection. This will certainly be tr= ue in residential and SMB markets. This is what is happening in the market= today with anyone with a voice service from Cable Operator, ATT Verizon et= c that have "digital voice services". Not to mention I'm equally skeptical= such validation methods will reach the smartphone handsets.=20 This statement is simply incorrect. "While the core network of the PSTN remains fixed, the endpoints of the telephone network are becoming increasingly programmable and sophisticated. Landline "plain old telephone service" deployments, especially in the developed world, are shrinking, and increasingly being replaced by three classes of intelligent devices: smart phones, IP PBXs, and terminal adapters. All three are general purpose computers, and typically all three have Internet access as well as access to the PSTN. This provides a potential avenue for building an authentication system that changes only the endpoints while leaving the PSTN intact." I take it you have a unlimited data roaming plan?=20 I have enormous trouble believing for one instant that CUA's are going to p= lay a meaningful role in Validation/Authentication/Authorization. IMHO this= is a network service. To additionally postulate that consumers and busines= s are going to sign up for some rendezvous call placement service is almost= preposterous. That is what a SIP proxy CSCF should do and I'm happy to pay= Verizon etal to do that. That is why they are called "service providers" irrespective of what the access device is and what the last mile infrastruc= ture is. I'm certainly willing to listen to ideas about out of band solutions especi= ally at the wholesale carrier GW layer. But right now its clear to me the s= hortest first path to success is defining what in band looks like within th= e SIP headers so it's possible to move on to the real heavy lifting of what= the directory look up system might look like. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dav= e Crocker Sent: Sunday, July 14, 2013 11:51 PM To: Peterson, Jon Cc: IETF STIR Mail List Subject: Re: [stir] Draft STIR Charter On 7/14/2013 8:26 PM, Peterson, Jon wrote: > > I don't believe I've "confirmed" on the list that out-of-band would be=20 > fully redundant with in-band. Actually, you did: >> Subject: Re: [stir] Out-of-band vs. in-band >> Date: Mon, 24 Jun 2013 17:18:01 +0000 >> From: Peterson, Jon >> To: dcrocker@bbiw.net >> CC: stir@ietf.org >> .... >> To your refined question, about using two approaches "always and=20 >> simultaneously," some STIR deployments would be capable of doing=20 >> both, and yes under the model I at least have in mind they would do both= . That describes usage that is fully redundant. Perhaps you didn't mean it or that you meant something else. This merely u= nderscores the confusion I cited about what exactly is meant by an out-of-b= and mechanism, who it's actors would be and when it would be used -- I'll a= lso toss in how the actors will know they are to use it. Without a fair sense of answers to all of the above, we can't have any idea= what the engineering challenges for the mechanism will be, or even whether= the mechanism is viable. > Instead, what I've said is that there are different applicabilities=20 > for these two proposed mechanisms. So sometimes use one, sometimes use the other, sometimes use both? There's a nice term for such an approach and, I might add, quite a bit of e= xperience with its applicability. The term is "non-interoperable'. > I don't think > anyone could reasonably maintain that an in-band solution for SIP=20 > would be a complete solution for the robocalling or voicemail hacking=20 > out there in the wild today. Right. So it's a good thing, indeed, that no one has attempted to maintain= that, isn't it? > What I have said in the past that may have confused you is that I > envisioned that an authentication service (i.e., the originating side) > that supported both in-band and out-of-band should ideally use both, And you don't think that makes it fully redundant for the caller? (And=20 fully redundant for /some/ callees.) > To me, this out-of-band question is a question about the problem we're > aiming to solve, not the solution mechanisms. Are we going to try to do > anything about the parts of the robocalling and voicemail hacking problem > where SIP is not the protocol used on both side, or are we going to skip > that? And if the latter, are we addressing enough of the problem for this > to be worth our effort? So a proposed solution isn't about solutions but about the problem?=20 Sorry, but I've no idea what this paragraph means or how it responds. Really, my note asked very simple, very basic technical questions about=20 the out-of-band 'proposal'. Very simple. Very basic. For those promoting an immediate effort at producing an out-of-band=20 solution, the answers also out to be very simple and basic. d/ --=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 Henning.Schulzrinne@fcc.gov Mon Jul 15 12: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 C302C21E8112 for ; Mon, 15 Jul 2013 12:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=0.557, 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 oqjgwfXDti2u for ; Mon, 15 Jul 2013 12:21: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 7D90D21E8107 for ; Mon, 15 Jul 2013 12:21:00 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Michael Hammer' Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIF2w2hhDzu+kKP+YqzEEYfuplgBgeAgAAEgQCAAANuAIAAAaEAgAAGyYD//73RMIAABfoQgABHGQCAAA3sAIAAAhCAgADroICAAEL+gIAAAeAAgABhRQCAAB8HgIAADPaAgAAKzoCABGL0gIAAA5WA///BagA= Date: Mon, 15 Jul 2013 19:20:58 +0000 References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> <3145728A-87FA-4217-9B93-E14A01307784@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC16DAD@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC16DAD@EX2K10MB1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 15 Jul 2013 19:21:07 -0000 I think the classical terms of "authentication" and "authorization" don't q= uite apply here, as we're trying to ascertain the right to use an identifie= r, not authenticate to a service (establish identity) or be authorized to u= se a service (establish capability). In some cases, the caller may well aut= henticate to the provider or the carrier may authenticate to the number adm= inistrator and be authorized to retrieve a public key or certificate, but t= hat's a separate component. One way to phrase this is to state simply "is the caller entitled to use th= e telephone number in the callerID information", avoiding the a*e vs. a*o d= ebate altogether and, I think, stating the goal reasonably accurately. One indication that this is different is that none of us have been talking = about using RADIUS/DIAMETER or 802.1.x or Kerberos for this - not just as a= specific protocol, but as a model. I'm guessing that neither DKIM or SPF c= onsider that authorization. (A quick check of RFC 4871 shows only 3 uses of= the term authorize, and they seem to relate to authorization to use an out= going mail server. The term "authentication" appears more frequently, if lo= osely, mostly as "authenticated email" or "authenticity".) -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Mic= hael Hammer Sent: Monday, July 15, 2013 2:56 PM To: hadriel.kaplan@oracle.com; dcrocker@bbiw.net Cc: stir@ietf.org; housley@vigilsec.com Subject: Re: [stir] Draft STIR Charter Would you want to say: "to verify the *authenticated* originator" Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Had= riel Kaplan Sent: Monday, July 15, 2013 2:43 PM To: dcrocker@bbiw.net Cc: IETF STIR Mail List; Russ Housley Subject: Re: [stir] Draft STIR Charter On Jul 12, 2013, at 7:43 PM, Dave Crocker wrote: > Meta-point: >=20 > The text is only about authentication, but the discussion has been about authorization. For example one might have an authenticated originato= r value that is not the string displayed as Caller-ID.[*] I understood the= purpose of the wg to be ensuring that the displayed string was authorized = by its assignee. >=20 > If no one cares about this distinction and everyone feels that "authenticate the originator" is sufficiently precise and accurate, fine, b= ut I thought it worth making sure. It took me a while to grok what you mean, because from my perspective STIR = is about verifying the received Caller-ID is authentic for a given call req= uest, and authenticating it to be so - not that STIR is authorizing the ori= ginator to make a call. But really what you mean is STIR is about verifyin= g the originator of the call request is authorized to use the claimed calle= r-id. How about this: As its first work item, the working group will specify a SIP=20 header-field-based mechanism to verify the originator of a=20 SIP session is authorized to use the claimed source identifier,=20 where the identity is a telephone number and the session is=20 established with SIP end to end. -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From br@brianrosen.net Mon Jul 15 12:36:23 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5C521E815D for ; Mon, 15 Jul 2013 12:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.275 X-Spam-Level: X-Spam-Status: No, score=-100.275 tagged_above=-999 required=5 tests=[AWL=0.162, 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 GOAtz30tzaLS for ; Mon, 15 Jul 2013 12:36:18 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id EFE2421E813E for ; Mon, 15 Jul 2013 12:36: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=taK3X6yxtvl2p751cLghsdeplX1cUuWSkR8nTVbIj7Y=; b=Lzkq+6cmIxumbKbzXeUpIgBgGmu+n/vfgcTlIyo3NN0g9UKg3wUZ6Xs3GxQo0FX0+EHDVudhEaRZLxoqVyW1ENufRiXeuphfQ7bFrqaqn+8F9IWNtf8VQ9nBwTr8/V1XwBcOgWVLohBLSC8KtVp7hng0Zk/6lMoI+2gGklelgnY=; Received: from neustargw.va.neustar.com ([209.173.53.233]:53446 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UyoZE-0004Ts-7m; Mon, 15 Jul 2013 15:36: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: <011601ce818b$7bdd48e0$7397daa0$@shockey.us> Date: Mon, 15 Jul 2013 15:36:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8345FC3B-C151-4F25-8190-3D0848B59B95@brianrosen.net> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> To: Richard Shockey 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: 'IETF STIR Mail List' , dcrocker@bbiw.net, "'Peterson, Jon'" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 15 Jul 2013 19:36:23 -0000 As an individual, I strongly support the notion we need an out of band = solution to get to the goal. Exactly how that works isn't yet clear to = me, but it's necessity is, because I don't believe we will have enough = "end to end" SIP in the time frame we need solutions. I wanted to respond to one little tidbit: > But right now its clear to me > the shortest first path to success is defining what in band looks like > within the SIP headers so it's possible to move on to the real heavy = lifting > of what the directory look up system might look like. >=20 If we do something along the lines of 4474 for the in band solution, we = need a non-centralized storage for credentials that can be used to = dereference a URI in the header which leads to the credential, but we = don't need any look-up mechanism. If you want to call the thing that delivers the credential from a URI = obtained from the SIP header a "look up mechanism", okay, but it's not a = public TN to credential mapping service. EKR's proposal needs one of those, but the in-band mechanism doesn't. One of the reasons to at least consider out of band mechanisms is the = effect it has on credential storage. If you have something along the = lines of my proposed alternative (new DB written by SIP->SS7 and queried = by SS7-SIP GW which restores the signature), it doesn't need one either. Brian From michael.hammer@yaanatech.com Mon Jul 15 12:59: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 EE86A11E8233 for ; Mon, 15 Jul 2013 12:59:35 -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 JP2mxBrQDInz for ; Mon, 15 Jul 2013 12:59:31 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7C011E81FD for ; Mon, 15 Jul 2013 12:59:26 -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, 15 Jul 2013 12:59:26 -0700 From: Michael Hammer To: "Henning.Schulzrinne@fcc.gov" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIBWXEGbn3ibkCpY0NkPYfuGZlgOFKAgAAEgQCAAANtAIAAAaEAgAAGyYCAAAH7AIAABkaA//+MAvCAAISOAIAAAhCAgADroICAAEL9gIAAAeEAgABhRACAAB8HgIAADPeAgAAKzoCABGLzgP//jdEggAB81QD//5CrkA== Date: Mon, 15 Jul 2013 19:59:25 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC17062@EX2K10MB1.corp.yaanatech.com> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> <3145728A-87FA-4217-9B93-E14A01307784@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC16DAD@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.65] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_003D_01CE8174.46D24D60" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 15 Jul 2013 19:59:36 -0000 ------=_NextPart_000_003D_01CE8174.46D24D60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Whether you want to say "authorization" or "entitlement checking" doesn't matter as much to me. The important point is that authenticating a self-signed certificate may prove nothing. There needs to be some traceability of the private key used to sign back to the chain of assignments from the number resource authority. This is an odd cat. It doesn't tell you who signed, just that the tel# to private key binding was delegated appropriately. Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Monday, July 15, 2013 3:21 PM To: Michael Hammer Cc: stir@ietf.org Subject: RE: [stir] Draft STIR Charter I think the classical terms of "authentication" and "authorization" don't quite apply here, as we're trying to ascertain the right to use an identifier, not authenticate to a service (establish identity) or be authorized to use a service (establish capability). In some cases, the caller may well authenticate to the provider or the carrier may authenticate to the number administrator and be authorized to retrieve a public key or certificate, but that's a separate component. One way to phrase this is to state simply "is the caller entitled to use the telephone number in the callerID information", avoiding the a*e vs. a*o debate altogether and, I think, stating the goal reasonably accurately. One indication that this is different is that none of us have been talking about using RADIUS/DIAMETER or 802.1.x or Kerberos for this - not just as a specific protocol, but as a model. I'm guessing that neither DKIM or SPF consider that authorization. (A quick check of RFC 4871 shows only 3 uses of the term authorize, and they seem to relate to authorization to use an outgoing mail server. The term "authentication" appears more frequently, if loosely, mostly as "authenticated email" or "authenticity".) -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Monday, July 15, 2013 2:56 PM To: hadriel.kaplan@oracle.com; dcrocker@bbiw.net Cc: stir@ietf.org; housley@vigilsec.com Subject: Re: [stir] Draft STIR Charter Would you want to say: "to verify the *authenticated* originator" Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Monday, July 15, 2013 2:43 PM To: dcrocker@bbiw.net Cc: IETF STIR Mail List; Russ Housley Subject: Re: [stir] Draft STIR Charter On Jul 12, 2013, at 7:43 PM, Dave Crocker wrote: > Meta-point: > > The text is only about authentication, but the discussion has been about authorization. For example one might have an authenticated originator value that is not the string displayed as Caller-ID.[*] I understood the purpose of the wg to be ensuring that the displayed string was authorized by its assignee. > > If no one cares about this distinction and everyone feels that "authenticate the originator" is sufficiently precise and accurate, fine, but I thought it worth making sure. It took me a while to grok what you mean, because from my perspective STIR is about verifying the received Caller-ID is authentic for a given call request, and authenticating it to be so - not that STIR is authorizing the originator to make a call. But really what you mean is STIR is about verifying the originator of the call request is authorized to use the claimed caller-id. How about this: As its first work item, the working group will specify a SIP header-field-based mechanism to verify the originator of a SIP session is authorized to use the claimed source identifier, where the identity is a telephone number and the session is established with SIP end to end. -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_003D_01CE8174.46D24D60 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NTE5NTkyNFowIwYJKoZIhvcNAQkEMRYEFFsnybl7Ndh/f+GdbAgC5r4aPWiUMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAScln+DhLvBcpnK2tD1+6A6Org8vTySsoakDtDHGW r8pU/YG1VpP5DgicnYjrTl6t9MNL3dLjYhoK4BLNGX+laqqxmUjBxAmFZV2RArOV7lBo7wwkOPzR 1A99ONAuNOgItFyIVA/E0ut+JZN05Y8+d66JCIFcpLJNwzrI8DTuNPGQZZ2+zzZ+NyHtSh5vVdd+ eWw2Iz/LtcO1Svow05seZyCjeZM2Cz8Nz0zCY2vmf4imLw+4WmaUt2DGXf5hNzT9MdTO6gnrD1KH XwbPwprLcoh1o4PZUb2RWUDxU0Ybk9k3jJG420Nq/ZBTj4jblB9qbLe0fCKR6qQg32GY3KEE4AAA AAAAAA== ------=_NextPart_000_003D_01CE8174.46D24D60-- From dhc@dcrocker.net Mon Jul 15 13:04: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 AD45011E822E for ; Mon, 15 Jul 2013 13:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.592 X-Spam-Level: X-Spam-Status: No, score=-6.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeoDytujlanY for ; Mon, 15 Jul 2013 13:04:29 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id BDE0121E811F for ; Mon, 15 Jul 2013 13:04: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 r6FK4POp031229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Jul 2013 13:04:28 -0700 Message-ID: <51E455A9.4040804@dcrocker.net> Date: Mon, 15 Jul 2013 13:03: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: Michael Hammer References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> <3145728A-87FA-4217-9B93-E14A01307784@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC16DAD@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC17062@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC17062@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]); Mon, 15 Jul 2013 13:04:29 -0700 (PDT) Cc: "stir@ietf.org" Subject: [stir] self-signing certificates ( was Re: Draft STIR 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, 15 Jul 2013 20:04:34 -0000 On 7/15/2013 12:59 PM, Michael Hammer wrote: > The important point is that authenticating a self-signed certificate may > prove nothing. That depends upon the derivation of the certificate. For example, DKIM uses self-signed certificates, but they are stored in a place in the DNS that belongs to the owner of the name being authenticated. Hence, the presence of the key in that location means that the owner of the name put it there. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From tsearle@sipstacks.com Mon Jul 15 13:05:47 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE5511E8228 for ; Mon, 15 Jul 2013 13:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNgTzPSZ18CN for ; Mon, 15 Jul 2013 13:05:43 -0700 (PDT) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by ietfa.amsl.com (Postfix) with ESMTP id 81A3911E81A2 for ; Mon, 15 Jul 2013 13:05:42 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id s9so27308500iec.27 for ; Mon, 15 Jul 2013 13:05:42 -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=tK8bzTPsWGWY3mDkPKqybuv6h/n3EvhbDFUg1p27C8U=; b=i/VLfeas5l3aKdvIfSPCstYgxtHJAysD/KHy9Vz1WUprkJY8BN9+6nVKVZZ7Debj0T oKiGp/YR6DJHP/mEZYF1D+jN2KiAJtFIRXDr2SmP0GJ7tPA4pHLvnlvacW5ORlIUOZro dK3zGqHj2eq8naF2fxn3tnt6/9say+w3UC5HkLA28/Fu+QCkvc9h4MWvQFt9C6qH/Knt VurHMyHzk0bX6+YyUTw9iPA4iSVJdHP9rbOf1IQKFD8c1TACNzJ6OFkzIiLgPmtvlJum nyCGWFxjnr9fY0dXFi1ZNe1+IQ+Q2CTrD1TKpZnhbwHje526YRSmJeKzjqtt4JEbBLw5 l55w== MIME-Version: 1.0 X-Received: by 10.43.137.65 with SMTP id in1mr18938723icc.103.1373918741029; Mon, 15 Jul 2013 13:05:41 -0700 (PDT) Received: by 10.64.68.132 with HTTP; Mon, 15 Jul 2013 13:05:40 -0700 (PDT) In-Reply-To: <1F4B4D44-BD3E-4995-876A-147832C925F9@oracle.com> References: <20130712043221.11767.74779.idtracker@ietfa.amsl.com> <1F4B4D44-BD3E-4995-876A-147832C925F9@oracle.com> Date: Mon, 15 Jul 2013 22:05:40 +0200 Message-ID: From: Torrey Searle To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=001a11c2456e82957204e192620d X-Gm-Message-State: ALoCoQkfXxLpo4W2KM1IwnIBMbqUevoLvFi024+MBCMTEyQSGUX1eoYEUMSQg0dIAFsqY0lT5Kp3 Cc: "stir@ietf.org" Subject: Re: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 15 Jul 2013 20:05:47 -0000 --001a11c2456e82957204e192620d Content-Type: text/plain; charset=ISO-8859-1 I really like your draft, especially the fact that inter networks with ss7. Just have a initial comment that in the case of the UUI header, the spec should probably specify that the Protocol Discriminator for the UUI header should be set to 00 - User Specific Coding. Though it might me an interesting question if it is possible to use a new value for the protocol discriminator to easily identify that the value in the UUI header is a signature. Also how about the case where bob@example.com gets aliased to an e164 when reaching the pstn gateway? I assume the pstn gateway would "own" the e164 and can re-sign the call before forwarding, but would it be interesting to mention this case in the spec? Look forward to hearing your thoughts! Torrey On Fri, Jul 12, 2013 at 6:39 AM, Hadriel Kaplan wrote: > Howdy, > I've been meaning to submit a couple drafts for STIR - one for how a DNS > model could work, and one for how the stuff can get through SIP and other > protocols in-band. > > Since some of the recent discussion has touched on some of the issues, and > the deadline for new drafts is fast approaching, I've submitted the latter > draft just now: > http://tools.ietf.org/html/draft-kaplan-stir-ikes-out-00 > > Sorry about the length, and yes it's still drafty/straw-man-ish. It's > also repetitive in sections, and needs a re-write, but the general concept > should be understandable. > > Comments/flames appreciated. > > -hadriel > > > Begin forwarded message: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : An Identity Key-based and Effective Signature > for Origin-Unknown Types > > Author(s) : Hadriel Kaplan > > Filename : draft-kaplan-stir-ikes-out-00.txt > > Pages : 28 > > Date : 2013-07-11 > > > > Abstract: > > This document describes a mechanism and format for signing source > > identity information of communication requests, in a manner capable > > of crossing multiple communication protocol types - even if the > > origin's protocol type is unknown. This is useful for providing > > E.164 and other forms of Caller-ID reputability for various > > communication protocols, such as SIP, XMPP, WebRTC, H.323, and > > SS7/ISUP. > > > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-kaplan-stir-ikes-out > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-kaplan-stir-ikes-out-00 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --001a11c2456e82957204e192620d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I really like your draft, especially the fact that inter networks with ss= 7. =A0Just have a initial comment that in the case of the UUI header, the s= pec should probably specify that =A0the Protocol Discriminator for the UUI = header should be set to 00 - User Specific Coding. =A0Though it might me an= interesting question if it is possible to use a new value for the protocol= discriminator to easily identify that the value in the UUI header is a sig= nature.


Also how abo= ut the case where=A0bo= b@example.com=A0gets aliased to an e164 when reaching the pstn gateway?= =A0I assume the pstn gateway would "own" the e164 and can re-sig= n the call before forwarding, but would it be interesting to mention this c= ase in the spec?


Look forward to hearing yo= ur thoughts!

Torrey


On Fri, Jul 12, 2= 013 at 6:39 AM, Hadriel Kaplan <hadriel.kaplan@oracle.com><= /span> wrote:
Howdy,
I've been meaning to submit a couple drafts for STIR - one for how a DN= S model could work, and one for how the stuff can get through SIP and other= protocols in-band.

Since some of the recent discussion has touched on some of the issues, and = the deadline for new drafts is fast approaching, I've submitted the lat= ter draft just now:
http://tools.ietf.org/html/draft-kaplan-stir-ikes-out-00
Sorry about the length, and yes it's still drafty/straw-man-ish. =A0It&= #39;s also repetitive in sections, and needs a re-write, but the general co= ncept should be understandable.

Comments/flames appreciated.

-hadriel


Begin forwarded message:

> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : An Identity Key-based and Effe= ctive Signature for Origin-Unknown Types
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Hadriel Kaplan
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-kaplan-stir-ikes-out-00.tx= t
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 28
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-07-11
>
> Abstract:
> =A0 This document describes a mechanism and format for signing source<= br> > =A0 identity information of communication requests, in a manner capabl= e
> =A0 of crossing multiple communication protocol types - even if the > =A0 origin's protocol type is unknown. =A0This is useful for provi= ding
> =A0 E.164 and other forms of Caller-ID reputability for various
> =A0 communication protocols, such as SIP, XMPP, WebRTC, H.323, and
> =A0 SS7/ISUP.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-kaplan-stir-ikes= -out
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-kaplan-stir-ikes-out-00
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

--001a11c2456e82957204e192620d-- From michael.hammer@yaanatech.com Mon Jul 15 13: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 9659611E8211 for ; Mon, 15 Jul 2013 13:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 gcnIQTLFmYcl for ; Mon, 15 Jul 2013 13:15: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 4F4D711E820D for ; Mon, 15 Jul 2013 13:15:13 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Mon, 15 Jul 2013 13:15:13 -0700 From: Michael Hammer To: "dcrocker@bbiw.net" Thread-Topic: self-signing certificates ( was Re: [stir] Draft STIR Charter ) Thread-Index: AQHOgZaEsBsTxhJEyUmJALmSfewPdZlmK62g Date: Mon, 15 Jul 2013 20:15:11 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC1710D@EX2K10MB1.corp.yaanatech.com> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> <3145728A-87FA-4217-9B93-E14A01307784@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC16DAD@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC17062@EX2K10MB1.corp.yaanatech.com> <51E455A9.4040804@dcrocker.net> In-Reply-To: <51E455A9.4040804@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_0042_01CE8176.7B2465B0" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] self-signing certificates ( was Re: Draft STIR Charter ) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 15 Jul 2013 20:15:17 -0000 ------=_NextPart_000_0042_01CE8176.7B2465B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This would seem to be circular logic since we are trying to discover who is the "owner" of the name. Would that not mean that the national authority needs to maintain that place and self-sign all the certs? Mike -----Original Message----- From: Dave Crocker [mailto:dhc@dcrocker.net] Sent: Monday, July 15, 2013 4:04 PM To: Michael Hammer Cc: stir@ietf.org Subject: self-signing certificates ( was Re: [stir] Draft STIR Charter ) On 7/15/2013 12:59 PM, Michael Hammer wrote: > The important point is that authenticating a self-signed certificate > may prove nothing. That depends upon the derivation of the certificate. For example, DKIM uses self-signed certificates, but they are stored in a place in the DNS that belongs to the owner of the name being authenticated. Hence, the presence of the key in that location means that the owner of the name put it there. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ------=_NextPart_000_0042_01CE8176.7B2465B0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NTIwMTUxMVowIwYJKoZIhvcNAQkEMRYEFLykv3hM7Z2vDr96rDglcZXO01qrMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAWBHJyEfdwsKBUV/D2Qk9vcUj1isyKUZ8kVIMgh5A dRnGedQk9+QNiaLhhDoEMIcgzIW40lgEn2VT761Cs9QvGIVZVKAxSkmTdxV/pyy1HGZPxMGAhrtJ YQlXwMuJqovxklHFZK6Ueu0xk2+Vts33LulsqgB8KraxVvsgYQXPp0VUT7Ot2cFfqjbcKB2yRPJj 1vacO32PKKDORYVrQpnfbReL4iLG5e/8BEOP0LBznGYErIvK6MFH2EE9G1FR/Rkb+fllhz/92Bw4 VX+AnnPMDWhAtvadDBpGICYN9/159ZbX1uNGxO6LEZmc4uKt6T/gnG6g9B1quK0mwPtm2hLduAAA AAAAAA== ------=_NextPart_000_0042_01CE8176.7B2465B0-- From dhc@dcrocker.net Mon Jul 15 13: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 8361721E8164 for ; Mon, 15 Jul 2013 13:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.592 X-Spam-Level: X-Spam-Status: No, score=-6.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0hCl4qoMXIF for ; Mon, 15 Jul 2013 13:20:33 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id D371821E8136 for ; Mon, 15 Jul 2013 13:20: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 r6FKKPmG031534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Jul 2013 13:20:29 -0700 Message-ID: <51E45969.9050707@dcrocker.net> Date: Mon, 15 Jul 2013 13:19: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: Michael Hammer References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> <3145728A-87FA-4217-9B93-E14A01307784@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC16DAD@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC17062@EX2K10MB1.corp.yaanatech.com> <51E455A9.4040804@dcrocker.net> <00C069FD01E0324C9FFCADF539701DB3BBC1710D@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC1710D@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]); Mon, 15 Jul 2013 13:20:29 -0700 (PDT) Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] self-signing certificates ( was Re: Draft STIR 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, 15 Jul 2013 20:20:38 -0000 On 7/15/2013 1:15 PM, Michael Hammer wrote: > This would seem to be circular logic since we are trying to discover who is > the "owner" of the name. Not quite. We're trying to verify that the owner has authorized the use of the number in the caller-id field for this call. This is usefully different; for one thing, it is an easier privacy-maintaining function. > Would that not mean that the national authority needs to maintain that place > and self-sign all the certs? There does needs to be a basis for trust the storage 'place' for the key, yes... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From york@isoc.org Mon Jul 15 13:25: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 3AFEE21E8177 for ; Mon, 15 Jul 2013 13:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 MgzA9xHKookW for ; Mon, 15 Jul 2013 13:25:50 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id 387B921E8173 for ; Mon, 15 Jul 2013 13:25:43 -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.731.12; Mon, 15 Jul 2013 20:25:41 +0000 Received: from BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.198]) by BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.45]) with mapi id 15.00.0731.000; Mon, 15 Jul 2013 20:25:41 +0000 From: Dan York To: "dcrocker@bbiw.net" , Michael Hammer Thread-Topic: [stir] self-signing certificates ( was Re: Draft STIR Charter ) Thread-Index: AQHOgZaJ6bgWS0Ge2Ueit6No4hTEXplmUVMA Date: Mon, 15 Jul 2013 20:25:40 +0000 Message-ID: In-Reply-To: <51E455A9.4040804@dcrocker.net> 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: 09086FB5C5 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(51704005)(377454003)(24454002)(479174003)(74662001)(16406001)(76796001)(31966008)(80022001)(56816003)(76786001)(49866001)(54316002)(79102001)(53806001)(81542001)(77096001)(50986001)(81342001)(47976001)(46102001)(51856001)(74502001)(56776001)(4396001)(63696002)(74706001)(47446002)(76176001)(74876001)(65816001)(83072001)(47736001)(59766001)(74366001)(36756003)(76482001)(77982001)(54356001)(69226001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB065; H:BLUPR06MB067.namprd06.prod.outlook.com; CLIP:10.255.101.4; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <1A1D8EB89F36D24B88530045B37E4477@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org Cc: "stir@ietf.org" Subject: Re: [stir] self-signing certificates ( was Re: Draft STIR Charter ) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 15 Jul 2013 20:25:55 -0000 On 7/15/13 10:03 PM, "Dave Crocker" wrote: >On 7/15/2013 12:59 PM, Michael Hammer wrote: >> The important point is that authenticating a self-signed certificate may >> prove nothing. > > >That depends upon the derivation of the certificate. For example, DKIM >uses self-signed certificates, but they are stored in a place in the DNS >that belongs to the owner of the name being authenticated. Hence, the >presence of the key in that location means that the owner of the name >put it there. This sounds a whole lot like one mode of DANE where you store the entire certificate (self-signed or CA-signed) in the TLSA record. You could say that the presence of the key in the TLSA record means that the owner of the name put it there. Of course, DANE is used in conjunction with DNSSEC to *prove* that the owner of the name put it there. (Although to be precise, DANE/DNSSEC proves that the *operator* of the zone put that information in there.) Dan From hadriel.kaplan@oracle.com Mon Jul 15 13:59: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 2928121E816C for ; Mon, 15 Jul 2013 13:59:51 -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 TQ3qaLo6jNVx for ; Mon, 15 Jul 2013 13:59:44 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id A986121E8114 for ; Mon, 15 Jul 2013 13:59:44 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6FKxgDN010275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Jul 2013 20:59:43 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 r6FKxesH025771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jul 2013 20:59:41 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 r6FKxemi027464; Mon, 15 Jul 2013 20:59:40 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 15 Jul 2013 13:59: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: <8345FC3B-C151-4F25-8190-3D0848B59B95@brianrosen.net> Date: Mon, 15 Jul 2013 16:59:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <8345FC3B-C151-4F25-8190-3D0848B59B95@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: IETF STIR Mail List Subject: [stir] Out-of-bound STIR (was: Re: Draft STIR Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 15 Jul 2013 20:59:51 -0000 On Jul 15, 2013, at 3:36 PM, Brian Rosen wrote: > As an individual, I strongly support the notion we need an out of band = solution to get to the goal. Exactly how that works isn't yet clear to = me, but it's necessity is, because I don't believe we will have enough = "end to end" SIP in the time frame we need solutions. We seem to be repeating the same arguments using different words, so = I'll repeat mine too: I fully agree that there is a large market of smartphones, apps, and a = billion uses for them; and that caller-id verification could be one of = those uses. I fully agree that a smartphone-to-smartphone solution = would cover some percentage of calls. I generally agree in theory that = the overall coverage would be improved if there were multiple usable and = actually-used ways of verifying caller-id. For that matter, having two = dozen different mechanisms might improve overall coverage too. But that's not sufficient justification for forming a working group, nor = for creating a specific solution. Even if we had interested IETF = participants for doing it, just because we publish an RFC means = absolutely nothing. If we don't want to waste everyone's time, we need = to know (1) the requirements for such a mechanism, (2) the = features/capabilities such a mechanism needs to be successful, and (3) = some indication that it would be useful and actually *used* by people.=20= To get those three things, we need participation from multiple potential = implementers of the technology, and participation from potential = deployers/administrators of it. Otherwise we're just shooting darts at = a dartboard. We've done that before in RAI, and were then shocked that = no one implemented the resulting RFCs, or we didn't publish an RFC = because we realized it was futile. We did it with numerous RFCs, and we = did it when we formed ATOCA, BLISS, P2PSIP, and SPLICES WGs. We need to = learn from our mistakes. Forming a working group or specifying a solution without the right = participants involved is a complete waste of time. And we don't have = the right participants involved for a smartphone app-based out-of-band = solution. We could try and find some of them, but that hasn't happened. My = personal belief is they don't want our help, and don't need our help. = Afaict, you don't need an IETF standard to deploy such a thing today, = and you wouldn't want to be constrained by an IETF spec or process = timeline to begin with. -hadriel From br@brianrosen.net Mon Jul 15 14:06: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 90EEB21E816C for ; Mon, 15 Jul 2013 14:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.284 X-Spam-Level: X-Spam-Status: No, score=-100.284 tagged_above=-999 required=5 tests=[AWL=0.153, 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 IlQ4DF281WUC for ; Mon, 15 Jul 2013 14:05:57 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 709B821E8147 for ; Mon, 15 Jul 2013 14:05: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=71uMDWXJa7TTJOd5cdeJAoP5JQqWfLLrqgzjdsXSfjE=; b=llA4gTA04bpGt0HBS3TWpk741nLbtcr5VF4rkUwFAi1UGQy9vt4fvWsn0KRBrf1U/L/N7F6BPqITnUF93Zjav8EVljlxKMf63hL5JT1XracTzbYNbT0u7LN4SWWqHY00FmpJNHPOKQOursT2DpVuxHaqqsN0gZZMUYYf7BSvxp4=; Received: from neustargw.va.neustar.com ([209.173.53.233]:49663 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1Uypy0-0002Hr-Fa; Mon, 15 Jul 2013 17:05:56 -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: Mon, 15 Jul 2013 17:05:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <39ADFAE0-8864-4ACE-9C64-BB64A52A4462@brianrosen.net> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <8345FC3B-C151-4F25-8190-3D0848B59B95@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: IETF STIR Mail List Subject: Re: [stir] Out-of-bound STIR (was: Re: Draft STIR Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 15 Jul 2013 21:06:02 -0000 You are making assumptions I am not. I am not assuming the endpoints are the only entities that use the out = of band solution - an SP may use them on it's behalf. EKR agrees. I am not assuming out of band means end to end. I've proposed = alternatives that work with SS7 hops that don't depend on UUI = transparency for example. I agree that creating documents that don't get implemented is not = helpful for this work. Brian On Jul 15, 2013, at 4:59 PM, Hadriel Kaplan = wrote: >=20 > On Jul 15, 2013, at 3:36 PM, Brian Rosen wrote: >=20 >> As an individual, I strongly support the notion we need an out of = band solution to get to the goal. Exactly how that works isn't yet = clear to me, but it's necessity is, because I don't believe we will have = enough "end to end" SIP in the time frame we need solutions. >=20 > We seem to be repeating the same arguments using different words, so = I'll repeat mine too: >=20 > I fully agree that there is a large market of smartphones, apps, and a = billion uses for them; and that caller-id verification could be one of = those uses. I fully agree that a smartphone-to-smartphone solution = would cover some percentage of calls. I generally agree in theory that = the overall coverage would be improved if there were multiple usable and = actually-used ways of verifying caller-id. For that matter, having two = dozen different mechanisms might improve overall coverage too. >=20 > But that's not sufficient justification for forming a working group, = nor for creating a specific solution. Even if we had interested IETF = participants for doing it, just because we publish an RFC means = absolutely nothing. If we don't want to waste everyone's time, we need = to know (1) the requirements for such a mechanism, (2) the = features/capabilities such a mechanism needs to be successful, and (3) = some indication that it would be useful and actually *used* by people.=20= >=20 > To get those three things, we need participation from multiple = potential implementers of the technology, and participation from = potential deployers/administrators of it. Otherwise we're just shooting = darts at a dartboard. We've done that before in RAI, and were then = shocked that no one implemented the resulting RFCs, or we didn't publish = an RFC because we realized it was futile. We did it with numerous RFCs, = and we did it when we formed ATOCA, BLISS, P2PSIP, and SPLICES WGs. We = need to learn from our mistakes. >=20 > Forming a working group or specifying a solution without the right = participants involved is a complete waste of time. And we don't have = the right participants involved for a smartphone app-based out-of-band = solution. >=20 > We could try and find some of them, but that hasn't happened. My = personal belief is they don't want our help, and don't need our help. = Afaict, you don't need an IETF standard to deploy such a thing today, = and you wouldn't want to be constrained by an IETF spec or process = timeline to begin with. >=20 > -hadriel >=20 From hadriel.kaplan@oracle.com Mon Jul 15 14:23: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 6F2C721F9D1F for ; Mon, 15 Jul 2013 14:23:07 -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 83oA3k4HhcgF for ; Mon, 15 Jul 2013 14:23:01 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 05EFB21E8103 for ; Mon, 15 Jul 2013 14: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 r6FLMswF031639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Jul 2013 21:22:55 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 r6FLMsur019582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jul 2013 21:22:54 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 r6FLMsmd016638; Mon, 15 Jul 2013 21:22:54 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 15 Jul 2013 14:22: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: Mon, 15 Jul 2013 17:22:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: IETF STIR Mail List Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 15 Jul 2013 21:23:07 -0000 On Jul 15, 2013, at 3:11 PM, Henning Schulzrinne = wrote: > I suspect we'd all prefer a solution that achieves 100% coverage by = network providers, sooner rather than later. > Some may prefer a solution that offer 80% coverage by network = providers supplemented by 15% by end-to-end solutions to leaving those = 20% exposed to the tender mercies of Rachel from Credit Card Services. I don't think the math will work out that way though. I have a hunch = that the 15% coverage for smartphone-based caller-id verification would = 99% overlap the 80% coverage by network providers doing in-band. In = other words, my guess is the mobile phone providers would almost all be = the type of network providers who would do the in-band thing anyway, and = my guess is they'd even be among the early-adopters. The 20% of network providers who wouldn't do the in-band thing, are the = type of providers who serve purely TDM access, without smartphones, and = for customers who wouldn't/couldn't do an out-of-band thing either. = There's no solution for them no matter what we do. In a Venn diagram, my guess is the in-band coverage almost completely = overlaps any smartphone-app coverage, if we do a good job with in-band. -hadriel From michael.hammer@yaanatech.com Mon Jul 15 14:24: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 7585F11E81C4 for ; Mon, 15 Jul 2013 14:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.066, 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 F8enTR-EdTFL for ; Mon, 15 Jul 2013 14:24:20 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD1311E81B8 for ; Mon, 15 Jul 2013 14:24:20 -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, 15 Jul 2013 14:24:19 -0700 From: Michael Hammer To: "dcrocker@bbiw.net" Thread-Topic: self-signing certificates ( was Re: [stir] Draft STIR Charter ) Thread-Index: AQHOgZaEsBsTxhJEyUmJALmSfewPdZlmK62ggAB304D//5v3kA== Date: Mon, 15 Jul 2013 21:24:18 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC172FE@EX2K10MB1.corp.yaanatech.com> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> <3145728A-87FA-4217-9B93-E14A01307784@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC16DAD@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC17062@EX2K10MB1.corp.yaanatech.com> <51E455A9.4040804@dcrocker.net> <00C069FD01E0324C9FFCADF539701DB3BBC1710D@EX2K10MB1.corp.yaanatech.com> <51E45969.9050707@dcrocker.net> In-Reply-To: <51E45969.9050707@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_0047_01CE8180.228C7370" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] self-signing certificates ( was Re: Draft STIR Charter ) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 15 Jul 2013 21:24:24 -0000 X-List-Received-Date: Mon, 15 Jul 2013 21:24:24 -0000 ------=_NextPart_000_0047_01CE8180.228C7370 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Squeezing the balloon? :) I would hope that it is intuitively obvious to validate the chain of trust. At least as obvious as tracing a series of certificates to a well-known one. Mike -----Original Message----- From: Dave Crocker [mailto:dhc@dcrocker.net] Sent: Monday, July 15, 2013 4:20 PM To: Michael Hammer Cc: dcrocker@bbiw.net; stir@ietf.org Subject: Re: self-signing certificates ( was Re: [stir] Draft STIR Charter ) On 7/15/2013 1:15 PM, Michael Hammer wrote: > This would seem to be circular logic since we are trying to discover > who is the "owner" of the name. Not quite. We're trying to verify that the owner has authorized the use of the number in the caller-id field for this call. This is usefully different; for one thing, it is an easier privacy-maintaining function. > Would that not mean that the national authority needs to maintain that place > and self-sign all the certs? There does needs to be a basis for trust the storage 'place' for the key, yes... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ------=_NextPart_000_0047_01CE8180.228C7370 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NTIxMjQxN1owIwYJKoZIhvcNAQkEMRYEFHx/3kLqW6bYZd3MkxCBW7emip5qMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEARwyHjTLHVFXaOwO0Wcl343xMVfKFMUahhv6hInJd kbm0CBHHzJiwUKxLTXVMybc98rsYao9WsVVaiaoq2//Rw5VeHVPkC8vxeG/Rg3ImG9qXO7X6FUOI BtmVEmtNqsjGTxAzYKeSOxykjB0kDtw0HmI3XTZhBbJ08pyw+17qhSBeu+b2c21+PjMRjpf+hLkD 5XP1iKYCl8cEU6bmr8YA0cq4Bhl81ZiPvG2B3tWURUQLiFb6nuyg2YVK4wSDr1SxUC3s8+saDR3K J334QzbGKneq84Jam+m+TP7zaxc6VZQUFYMSJW8iCAaJJ+hUFainr3uPXeBROjBa53AM5ByRuQAA AAAAAA== ------=_NextPart_000_0047_01CE8180.228C7370-- From br@brianrosen.net Mon Jul 15 14:29: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 65A4311E81C9 for ; Mon, 15 Jul 2013 14:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.251 X-Spam-Level: X-Spam-Status: No, score=-100.251 tagged_above=-999 required=5 tests=[AWL=0.186, 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 N0ApEqCTkY7g for ; Mon, 15 Jul 2013 14:29:53 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id F094411E81D2 for ; Mon, 15 Jul 2013 14:29:50 -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=PmA6ehjKwCuvzve3CXRwvACttVkCZktPAcWL1QMpV78=; b=GSEAqnS1JgzztfSUt8eNGdMm3juTxkaBnOUiXUuwk1QunbKbHyT5MlhMH6iSAKklY5GiBtn9TXPu+0KLKkj4cEc5X865weUQ6ecsalW5UkbaTYcTCbBYf4bOmd+BKmnV3ObPhVO2K/jdHUbR4BwlpVNClPT4imxpTgyOiG+hFkM=; Received: from neustargw.va.neustar.com ([209.173.53.233]:58774 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UyqL7-0007W1-9N; Mon, 15 Jul 2013 17:29:49 -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: <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> Date: Mon, 15 Jul 2013 17:29:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> 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: IETF STIR Mail List , Henning Schulzrinne Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 15 Jul 2013 21:29:57 -0000 You are assuming that the pink carriers interwork with the mobile = carriers with a SIP path in the timeframe we can deploy. The pink guy starts out SIP, but you have to posit the wireless networks = doing SIP interwork with Tier 2 CLECs in a couple years. That seems = unlikely from where I sit. Much more likely that a VoIP carrier does than a wireless carrier. = We'll see of course. =20 Brian On Jul 15, 2013, at 5:22 PM, Hadriel Kaplan = wrote: >=20 > On Jul 15, 2013, at 3:11 PM, Henning Schulzrinne = wrote: >=20 >> I suspect we'd all prefer a solution that achieves 100% coverage by = network providers, sooner rather than later. >> Some may prefer a solution that offer 80% coverage by network = providers supplemented by 15% by end-to-end solutions to leaving those = 20% exposed to the tender mercies of Rachel from Credit Card Services. >=20 > I don't think the math will work out that way though. I have a hunch = that the 15% coverage for smartphone-based caller-id verification would = 99% overlap the 80% coverage by network providers doing in-band. In = other words, my guess is the mobile phone providers would almost all be = the type of network providers who would do the in-band thing anyway, and = my guess is they'd even be among the early-adopters. >=20 > The 20% of network providers who wouldn't do the in-band thing, are = the type of providers who serve purely TDM access, without smartphones, = and for customers who wouldn't/couldn't do an out-of-band thing either. = There's no solution for them no matter what we do. >=20 > In a Venn diagram, my guess is the in-band coverage almost completely = overlaps any smartphone-app coverage, if we do a good job with in-band. >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From dhc@dcrocker.net Mon Jul 15 14:38: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 CD5F911E8198 for ; Mon, 15 Jul 2013 14:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.293 X-Spam-Level: X-Spam-Status: No, score=-6.293 tagged_above=-999 required=5 tests=[AWL=-0.294, 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 Zppjnx1m2Hpu for ; Mon, 15 Jul 2013 14:38:02 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id AEAEE21F9E88 for ; Mon, 15 Jul 2013 14:38:02 -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 r6FLbw1r001135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Jul 2013 14:38:01 -0700 Message-ID: <51E46B96.7090708@dcrocker.net> Date: Mon, 15 Jul 2013 14:37: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: Brian Rosen References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <8345FC3B-C151-4F25-8190-3D0848B59B95@brianrosen.net> <39ADFAE0-8864-4ACE-9C64-BB64A52A4462@brianrosen.net> In-Reply-To: <39ADFAE0-8864-4ACE-9C64-BB64A52A4462@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]); Mon, 15 Jul 2013 14:38:01 -0700 (PDT) Cc: IETF STIR Mail List Subject: Re: [stir] Out-of-bound 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: Mon, 15 Jul 2013 21:38:08 -0000 On 7/15/2013 2:05 PM, Brian Rosen wrote: > You are making assumptions I am not. > > I am not assuming the endpoints are the only entities that use the out of band solution - an SP may use them on it's behalf. EKR agrees. Hadriel isn't making an assumption. He, I and I think others are simply hearing some folks consistently point specifically (and exclusively) to the end-to-end approach of doing Out-of-band. At the least, you and EKR seem to be entertaining importantly different models. From EKR's draft: > Abstract: ... > This document describes a mechanism for two compliant endpoints. The Abstract does not mention other actors participating in the validation mechanism. > Introduction ... > This provides a potential avenue for > building an authentication system that changes only the endpoints > while leaving the PSTN intact. Again, no mention of other uses in the Introduction. > 2. Operating Environment We finally see activity in gateways, but only as a limited alternative: > Similarly, the gateway > would verify Alice's identity, generate the right caller-id > information and provide caller-id information to Bob using ordinary > POTS mechanisms. Section 3 is only in terms of end-points. > 4.1. Phone Number Authentication ... > For purposes of exposition we will assume > that ownership is associated with the endpoint (e.g., a smartphone) > but it might well be associated with a gateway acting for the > endpoint instead. It might be the case that multiple entities are And the exclusively end-to-end use of out-of-band has been pressed by others. There has been minimal acknowledgement of the possible role of other components in the sequence. Using this function as a gateway trick for dealing with intermediary PSTN hops could make quite a bit of sense. But that sort of 'tunneling' approach has significantly different OA&M characteristics than the end-to-end one. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Mon Jul 15 14:44: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 D219721F9CD3 for ; Mon, 15 Jul 2013 14:44:03 -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 yxKhLsgLcFrM for ; Mon, 15 Jul 2013 14:43:58 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id AD5D711E81E1 for ; Mon, 15 Jul 2013 14:43: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 r6FLhdtW001388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Jul 2013 14:43:42 -0700 Message-ID: <51E46CEB.1020308@dcrocker.net> Date: Mon, 15 Jul 2013 14:43: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: Brian Rosen References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@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]); Mon, 15 Jul 2013 14:43:43 -0700 (PDT) Cc: IETF STIR Mail List , Hadriel Kaplan Subject: Re: [stir] Draft STIR 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, 15 Jul 2013 21:44:03 -0000 On 7/15/2013 2:29 PM, Brian Rosen wrote: > You are assuming that the pink carriers interwork with the mobile carriers with a SIP path in the timeframe we can deploy. He's assuming that the math is more delicate than what is otherwise being offered and that there are likely to be interaction effects distorting the sampling and therefore affecting the numbers. That is, these are not entirely independent populations being sampled. In other words, he's right. Rather than criticize the details of his criticism, anyone promoting effort on a second mechanism has an affirmative obligation to make a solid argument for its success. Solid arguments for "sufficient" use deal with implementation, deployment and use, and the basis for predicting the likelihood and scale of each. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Mon Jul 15 14:59: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 9D2D621E8177 for ; Mon, 15 Jul 2013 14:59: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 HI7+t3rq3rxP for ; Mon, 15 Jul 2013 14:59:26 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id F26B721E816E for ; Mon, 15 Jul 2013 14:59: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 r6FLx97l002197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Jul 2013 14:59:14 -0700 Message-ID: <51E4708C.4000206@dcrocker.net> Date: Mon, 15 Jul 2013 14:58: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: Eric Rescorla 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, 15 Jul 2013 14:59:14 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] Draft posted (draft-rescorla-stir-fallback-00) 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, 15 Jul 2013 21:59:34 -0000 Eric, Comments in-line (or should I stash them on a web page, for possible retrieval...?) > Abstract > > A major challenge with RFC 4474-style identity assertions has been > that SIP operates in highly mediated and interworked environments. Given the lack of implementation and deployment experience for RFC4474, there doesn't seem to be any public evidence of what specific problems the document has. So the opening attribution is problematic. A reference like "RFC 4474-style" is quite ambiguous; there's no established practice or other way to know what it refers to in technical terms, and certainly not for folk outside this close-knit club. I suspect that your core point hinges on something that is actually far more broadly applicable than just for that specification. Perhaps as an alternative opening: Any SIP-based authentication mechanism that relies on the carriage of its information in SIP headers encounters a basic problem. SIP typically operates in highly mediated and... > SIP requests may pass through gateways, policy enforcement devices or > other entities that receive SIP requests and effectively act as user > agents, re-initiating a request. In these circumstances, > intermediaries may recreate the fields protected by the RFC4474 > signature, making end-to end integrity impossible. This document > describes a mechanism for two compliant endpoints to exchange > authentication data even in the face of intermediaries which remove > all additional call signaling meta-data or which translate from SIP > into protocols incapable of understanding identity meta-data (e.g., > where one side is the PSTN). > 1. Introduction ... > > While the core network of the PSTN remains fixed, the endpoints of > the telephone network are becoming increasingly programmable and > sophisticated. Landline "plain old telephone service" deployments, Not just the end-points. All of the SIP-based components in the sequence ought to be equally programmable, certainly including SIP/PSTN gateways. And gateways are the more typical place for performing channel-specific tunneling hacks like this. > especially in the developed world, are shrinking, and increasingly > being replaced by three classes of intelligent devices: smart > phones, IP PBXs, and terminal adapters. All three are general > purpose computers, and typically all three have Internet access as > well as access to the PSTN. This provides a potential avenue for > building an authentication system that changes only the endpoints > while leaving the PSTN intact. A benefit of, instead, placing the function in gateways is that it is only active when it is needed and by the relatively few nodes that need the special capability. So this works for more users, as indicated by your second example, below. > 3. Architectural Options ... > There are roughly two plausible dataflow architectures for the CPS: > > > > Rescorla Expires January 14, 2014 [Page 5] > > Internet-Draft Caller-ID Fallback July 2013 > > > o The callee registers with the CPS. When the caller wishes to > place a call to the callee, it sends the CPR to the CPS which > forwards it to the callee. > > o The caller stores the CPR with the CPS at the time of call > placement. When the callee receives the call, it contacts the CPS > and retrieves the CDR. The caller actions is the same for both. The difference is simply a push (forwarding) vs. pull (retrieving) model for the callee-side of things. Yes? > While the first architecture is roughly isomorphic to current VoIP > protocols, it shares their drawbacks. Specifically, the callee must > maintain a full-time connection to the CPS to serve as a notification > channel. That depends upon what is registered. If a contact-me-at entry is registered, it does not require maintaining an open connection, does it? > This comes with the usual networking costs to the callee > and is especially problemtatic for mobile endpoints. Thus, we focus > on the second architecture in which the PSTN incoming call serves as > the notification channel and the callee can then contact the CPS to > retrieve the CPR. These don't have to be mutually exclusive. Forwarding can be a performance optimization, available if the callee has registered, with pull (storage awaiting retrieval) is the default. > 4. Strawman Architecture > > In this section, we discuss a strawman architecture along the lines > described in the previous section. This discussion is deliberately > sketchy, focusing on broad concepts and skipping over details. The > intent here is merely to provide a rough concept, not a complete > solution. > > 4.1. Phone Number Authentication > > We start from the premise that each phone number in the system is > associated with a set of credentials which can be used to prove > ownership of that number. For purposes of exposition we will assume Prove 'ownership' or prove 'assignment'? > that ownership is associated with the endpoint (e.g., a smartphone) > but it might well be associated with a gateway acting for the > endpoint instead. It might be the case that multiple entities are > able to act for a given number, provided that they have the > appropriate authority. The question of how an entity is determined > to have control of a given number is out of scope for this document. > > 4.2. Call Placement Service ... > Once Alice has stored the CPR, she then places the call to Bob as > usual. At this point, Bob's phone would usually ring and display > Alice's number (+1.111.111.1111), which is provided by the usual > caller-id mechanisms (i.e., the CIN field of the IAM). Instead, > Bob's phone transparently contacts the CPS and requests any current > CPRs from Alice. The CPS responds with any such CPRs (assuming they > exists). If such a CPR exists, he can then present the callerid > information as valid. Otherwise, the call is unverifiable. Note > that this does not necessarily mean that the call is bogus; because > we expect incremental deployment many legitimate calls will be > unverifiable This 'Note' sentence is more significant than it's placement in the document would seem to indicate. It goes to a core challenge to make any of these mechanisms useful. > > 4.3. Security Analysis > > The primary attack we seek to prevent is an attacker convincing the > callee that a given call is from some other caller C. There are two > scenarios to be concerned with: > > o The attacker wishes to simulate a call when none exists. What does that mean? > o The attacker wishes to substitute himself for an existing call as > described in Section 4.3.1 Neither of these sounds like the scenario that I thought I'd been hearing during the life of this mailing list: The attacker initiates a call, using a Caller-ID value for which they do not have authorization. Confusion about this suggests that the wg charter needs to be explicit and clear about the threat vectors that are to be of concern for the wg effort. > > If an attacker can inject fake CPRs into the CPS or in the > > > > Rescorla Expires January 14, 2014 [Page 7] > > Internet-Draft Caller-ID Fallback July 2013 > > > communication from the CPS to the callee, he can mount either attack. > In order to prevent this, either the communication to the CPS should > be secured in transport (e.g., with TLS) or the CPRs should be > digitally signed by the caller and verified by the callee > (Section 5.2. For privacy and robustness reasons, both are both are -> using both is Anyhow, really? Belts and suspenders? With the object-based approach, signing isn't enough to provide privacy. It needs confidentiality. Since it's unlikely the caller and callee information will be encrypted, it won't provide meta-data privacy even then. If object-based authentication is performed, TLS provides no value-add for authentication. > preferable. In particular, if only transport security is used, then > a compromised CPS can forge call origination information. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jon.peterson@neustar.biz Mon Jul 15 15:38: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 8A70F11E8176 for ; Mon, 15 Jul 2013 15:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.862 X-Spam-Level: X-Spam-Status: No, score=-105.862 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, FB_YOUR_REFI=0.333, 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 3k322DFCfl-P for ; Mon, 15 Jul 2013 15:38:28 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1FB11E8167 for ; Mon, 15 Jul 2013 15:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1373928412; x=1689285370; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=00aTBL65az wmfZSx80fxIpKXt0+ARM8hc52FP/clmwk=; b=cPSAQ5DshL+WHl+HxM5Gt5M6DY 4Qt9KNtD0JZlYR7Ah4yN2oe//Ml0TUIETvZaZaSgcHecVEAFYzzk6Ln60Hqw== Received: from ([10.31.58.70]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.27983525; Mon, 15 Jul 2013 18:46: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; Mon, 15 Jul 2013 18:38:17 -0400 From: "Peterson, Jon" To: "dcrocker@bbiw.net" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkICx1fsldqNdEa1H4oCYTQLxplgBgeAgAAEgQCAAANuAIAAAaEAgAAGyYCAAAH6AIAABkaAgAACpAD//5iRAIAAd2uAgADroICAAEL+gIAAAeAAgABhRQCAAB8HgIAADPaAgAAKzoCAAzU2gIAADMkA//+reQCAAHxoAIAAxXwA Date: Mon, 15 Jul 2013 22:38:16 +0000 Message-ID: In-Reply-To: <51E371BA.9060009@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: cPtO65ncj4/FmdgRd9JbCg== Content-Type: text/plain; charset="us-ascii" Content-ID: <5E6D222302233547B0EED7DBA05310E2@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF STIR Mail List Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 15 Jul 2013 22:38:32 -0000 Inline. On 7/14/13 8:51 PM, "Dave Crocker" wrote: >On 7/14/2013 8:26 PM, Peterson, Jon wrote: >> >> I don't believe I've "confirmed" on the list that out-of-band would be >> fully redundant with in-band. > >Actually, you did: > >>> Subject: Re: [stir] Out-of-band vs. in-band >>> Date: Mon, 24 Jun 2013 17:18:01 +0000 >>> From: Peterson, Jon >>> To: dcrocker@bbiw.net >>> CC: stir@ietf.org >>> .... >>> 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. > >That describes usage that is fully redundant. I don't think there's much value in arguing over what you think what I said means, but in my last mail of the current thread, I already referred to having said exactly what you reproduce above, but I certainly didn't use the words "fully redundant" or anything that I believe encourages that interpretation. For the two approaches to be "fully redundant," there would be no case you could use one where you couldn't use the other, and no use of one that the other couldn't also fulfill. That isn't the case with in-band and out-of-band. I said there are some STIR deployments that would be capable of doing both, in the model I have in mind. For example, I have in mind a model where out-of-band support could be implemented in smart phones, and in-band support in a network element. A smart phone could have no idea that the network is using in-band, nor the network about the smart phone's usage of out-of-band. In that environment, sure, both could be used on the originating side. And potentially, both could even be consumed by mutually-unaware elements on the terminating side, or maybe just one element, or maybe none. >Perhaps you didn't mean it or that you meant something else. This >merely underscores the confusion I cited about what exactly is meant by >an out-of-band mechanism, who it's actors would be and when it would be >used -- I'll also toss in how the actors will know they are to use it. I think people are arguing for slightly different scopes for out-of-band, and that under different models there could be different actors. Saying that this constitutes "confusion" is, like "fully redundant," an interpretation projected onto the situation. >Without a fair sense of answers to all of the above, we can't have any >idea what the engineering challenges for the mechanism will be, or even >whether the mechanism is viable. Some few times in this thread, people have mentioned the existence of smart phone services that do a form of out-of-band verification today. People have pointed to services like iMessage that coordinate out-of-band rendezvous between smartphones and provide identity assertions. That VIPR thing did get some deployment too. So we believe there are existence proofs that it is possible to field something along these lines. Agreed that there are possible approaches to out-of-band that would not be viable, and we'd be wise not to choose one. >> Instead, what I've said is that there are >> different applicabilities for these two proposed mechanisms. > >So sometimes use one, sometimes use the other, sometimes use both? > >There's a nice term for such an approach and, I might add, quite a bit >of experience with its applicability. The term is "non-interoperable'. Well, sometimes, DKIM gets used. And sometimes PGP gets used. The entities that use DKIM and the entities that use PGP aren't really the same. They don't coordinate. I'm sure it happens that sometimes both are used simultaneously. The interoperability failure there isn't apparent to me. >> What I have said in the past that may have confused you is that I >> envisioned that an authentication service (i.e., the originating side) >> that supported both in-band and out-of-band should ideally use both, > >And you don't think that makes it fully redundant for the caller? (And >fully redundant for /some/ callees.) In the case where in-band and out-of-band on the originating are literally being managed by the same device or service, I think it's about as redundant as a SIP INVITE proposing two codecs in the hope that the far side supports one of them. You do it when you can't anticipate the capabilities of the far side, as it increases your chances of interoperating successfully. That doesn't mean the two codecs have identical properties, though: one might be much higher-bandwidth, say, and thus preferred. I don't think that's "full" redundancy, and I don't think it is in this proposed STIR case either. Now that much said, I also think the case where both an in-band and out-of-band would be provided by literally the same device is probably less likely than the smartphone/out-of-band network/in-band simultaneous usage. Again, much like it must happen for email. >> To me, this out-of-band question is a question about the problem we're >> aiming to solve, not the solution mechanisms. Are we going to try to do >> anything about the parts of the robocalling and voicemail hacking >>problem >> where SIP is not the protocol used on both side, or are we going to skip >> that? And if the latter, are we addressing enough of the problem for >>this >> to be worth our effort? > >So a proposed solution isn't about solutions but about the problem? >Sorry, but I've no idea what this paragraph means or how it responds. If the problem is to try to address robocalling and voicemail hacking, and those problems are not limited than the IP world, then should the scope of our work be limited to the IP world? >Really, my note asked very simple, very basic technical questions about >the out-of-band 'proposal'. Very simple. Very basic. > >For those promoting an immediate effort at producing an out-of-band >solution, the answers also out to be very simple and basic. I don't have all the answers about the solution. I do think we have a reasonable idea of what the problem is, and what some approaches are - enough to charter it and to work on it. As with many things in the IETF, different proposals for addressing problems will arise, and we sort through them, and hopefully we pick a good answer. Jon Peterson Neustar, Inc. >d/ > >--=20 >Dave Crocker >Brandenburg InternetWorking >bbiw.net From jon.peterson@neustar.biz Mon Jul 15 15:39: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 C6E1B11E81AD for ; Mon, 15 Jul 2013 15:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.294 X-Spam-Level: X-Spam-Status: No, score=-106.294 tagged_above=-999 required=5 tests=[AWL=0.305, 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 4nrsRqIycOdM for ; Mon, 15 Jul 2013 15:39:45 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0C48E11E8264 for ; Mon, 15 Jul 2013 15:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1373928488; x=1689285370; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=MC4BvXjg2t 6sARgv1DeG5dVVaUhGySwhlQ906QFbTac=; b=lGgML8Yn0iTMDPyAqglVEa5khi zaCMZ3u7l6rom3dcp7icitvowLSyromGh4OIhwGDMr07CUW4PkE4b/FkrSSA== Received: from ([10.31.58.70]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.27983558; Mon, 15 Jul 2013 18:48: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, 15 Jul 2013 18:39:36 -0400 From: "Peterson, Jon" To: Hadriel Kaplan , Brian Rosen Thread-Topic: [stir] Out-of-bound STIR (was: Re: Draft STIR Charter) Thread-Index: AQHOgZ5FUZ8oVGuTP0iGG9cNqdx3XplmItEA Date: Mon, 15 Jul 2013 22:39:35 +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: FyfjBUmjIr04pxVYBezgCQ== Content-Type: text/plain; charset="us-ascii" Content-ID: <9C86945F9B662D40AE179DF4B693C12A@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF STIR Mail List Subject: Re: [stir] Out-of-bound STIR (was: Re: Draft STIR Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 15 Jul 2013 22:39:50 -0000 There are some smartphone operating system vendors participating pretty actively in the IETF. Some of the things we're thinking about might be things it would be better for operating system vendors to address. Perhaps more materially, the scope of out-of-band isn't limited to smart phones. It includes things like IP PBX makers. At least one IP PBX maker has previously come to the IETF with an interest in working on an out-of-band mechanism here. So, not sure I agree, but I agree it's a valid question. Jon Peterson Neustar, Inc. On 7/15/13 1:59 PM, "Hadriel Kaplan" wrote: > >On Jul 15, 2013, at 3:36 PM, Brian Rosen wrote: > >> As an individual, I strongly support the notion we need an out of band >>solution to get to the goal. Exactly how that works isn't yet clear to >>me, but it's necessity is, because I don't believe we will have enough >>"end to end" SIP in the time frame we need solutions. > >We seem to be repeating the same arguments using different words, so I'll >repeat mine too: > >I fully agree that there is a large market of smartphones, apps, and a >billion uses for them; and that caller-id verification could be one of >those uses. I fully agree that a smartphone-to-smartphone solution would >cover some percentage of calls. I generally agree in theory that the >overall coverage would be improved if there were multiple usable and >actually-used ways of verifying caller-id. For that matter, having two >dozen different mechanisms might improve overall coverage too. > >But that's not sufficient justification for forming a working group, nor >for creating a specific solution. Even if we had interested IETF >participants for doing it, just because we publish an RFC means >absolutely nothing. If we don't want to waste everyone's time, we need >to know (1) the requirements for such a mechanism, (2) the >features/capabilities such a mechanism needs to be successful, and (3) >some indication that it would be useful and actually *used* by people. > >To get those three things, we need participation from multiple potential >implementers of the technology, and participation from potential >deployers/administrators of it. Otherwise we're just shooting darts at a >dartboard. We've done that before in RAI, and were then shocked that no >one implemented the resulting RFCs, or we didn't publish an RFC because >we realized it was futile. We did it with numerous RFCs, and we did it >when we formed ATOCA, BLISS, P2PSIP, and SPLICES WGs. We need to learn >from our mistakes. > >Forming a working group or specifying a solution without the right >participants involved is a complete waste of time. And we don't have the >right participants involved for a smartphone app-based out-of-band >solution. > >We could try and find some of them, but that hasn't happened. My >personal belief is they don't want our help, and don't need our help. >Afaict, you don't need an IETF standard to deploy such a thing today, and >you wouldn't want to be constrained by an IETF spec or process timeline >to begin with. > >-hadriel > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Mon Jul 15 17:04: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 8B0C411E8282 for ; Mon, 15 Jul 2013 17:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.467 X-Spam-Level: X-Spam-Status: No, score=-6.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOHBFjf-SqEf for ; Mon, 15 Jul 2013 17:04:22 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5834C11E8246 for ; Mon, 15 Jul 2013 17:04:13 -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 r6G047wa020614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 16 Jul 2013 00:04:08 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 r6G047oR004792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 Jul 2013 00:04:07 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 r6G046bp024215 for ; Tue, 16 Jul 2013 00:04:06 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 15 Jul 2013 17:04:06 -0700 From: Hadriel Kaplan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jul 2013 20:04:05 -0400 References: <20130715235519.10502.79008.idtracker@ietfa.amsl.com> To: IETF STIR Mail List Message-Id: <26F54E95-70CF-4FC9-BC6C-C4372E906F73@oracle.com> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [stir] DNS for STIR: draft-kaplan-stir-cider-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 00:04:27 -0000 Howdy, I've submitted a draft for how a DNS model could work for STIR, named = "CIDER". It still needs to ferment a bit, but it should provide the general = flavor of a DNS solution. Comments/questions/flames welcomed. -hadriel Begin forwarded message: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : A proposal for Caller Identity in a DNS-based = Entrusted Registry (CIDER) > Author(s) : Hadriel Kaplan > Filename : draft-kaplan-stir-cider-00.txt > Pages : 25 > Date : 2013-07-15 >=20 > Abstract: > This document describes a proposal for providing a database service > for authentication information for Caller-ID E.164 numbers, > nationally-specific number codes, and email-style names used in > communication requests (such as call setup, instant messages). The > model proposed uses a DNS service as a Registry for cryptographic > public-keys. The database service solution is called CIDER. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-kaplan-stir-cider >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-kaplan-stir-cider-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From hadriel.kaplan@oracle.com Mon Jul 15 17:08: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 D932811E8254 for ; Mon, 15 Jul 2013 17:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQ5+hnJtx7yS for ; Mon, 15 Jul 2013 17:08:35 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 62D6A11E8268 for ; Mon, 15 Jul 2013 17:08:35 -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 r6G08VVV031867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Jul 2013 00:08:32 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 r6G08UOk011447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 00:08:31 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 r6G08UIk005725; Tue, 16 Jul 2013 00:08:30 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 15 Jul 2013 17:08:30 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Mon, 15 Jul 2013 20:08:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: IETF STIR Mail List , Henning Schulzrinne Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 00:08:42 -0000 On Jul 15, 2013, at 5:29 PM, Brian Rosen wrote: > You are assuming that the pink carriers interwork with the mobile = carriers with a SIP path in the timeframe we can deploy. Nope - the "pink" carriers aren't the originators/terminators we care = about. They're what let the robocallers in to begin with. They're = "pink" for a reason, and the polite reason would be that they're too = under-staffed or inexperienced to have put customer caller-id policing = controls in place already today. They'll continue to be "pink" even = when we have in-band or out-of-band. We're not going to get the bad = guys telling us they're bad. We can only get the good guys telling us = they're good. What I am assuming is that the path between the set of call originators = who are the type that would publish their info into an out-of-band = thing, and the set of call receivers who are the type that would = retrieve the info from an out-of-band thing, will mostly be a SIP path = by the time we could have specified an out-of-band thing and gotten it = widely deployed. At least that's my assumption for North America, and = in certain countries in Europe, Asia, Middle East, and at least one = country in Africa.=20 > The pink guy starts out SIP, but you have to posit the wireless = networks doing SIP interwork with Tier 2 CLECs in a couple years. That = seems unlikely from where I sit. How so? The wireless carriers have to use SIP to peer, yes, but not = with Tier-2 CLECs. They can SIP peer to Tier-1 carriers, and those can = SIP peer with Tier-2 CLECs. It's not a full mesh connection model, and = never has been - you know that, so I'm confused by your statement. = (maybe I'm missing something?) If the Tier-1 carriers don't SIP peer with Tier-2 CLECs, then it's for = one of two reasons: (1) the Tier-2 CLEC still uses SS7/TDM itself, in = which case the Tier-2 isn't going to be doing squat for caller-id = anyway, or (2) it's just a short SS7 hop into a SIP-based CLEC, in which = case they can either use the UUI model or bite the bullet and move to = SIP peering. And it's not a "couple years". It will take us longer than that just to = get an out-of-band solution published as an RFC, let alone the timeframe = needed for it to be deployed and a Tier-2 CLEC or its customers to use = it. Let's say it takes 2 years to get an out-of-band into an RFC. After = that more time for the vendors implement it, getting tested in carriers, = etc. Even 3 years altogether would be a minor miracle. Meanwhile, how = long do you think before a significant majority of the carriers in North = America interconnect using SIP? 5 years? Let's say it's 7 years. The = time difference between the 3 years to get out-of-band and 7 years for = in-band would be 4 years. We'd do all that work, carriers would spend = all that time and money, all for a 4-year lifespan for 15% caller-id = coverage?!? How does that make any sense? -hadriel From hadriel.kaplan@oracle.com Mon Jul 15 20:19: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 EF12D21E8186 for ; Mon, 15 Jul 2013 20:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.177 X-Spam-Level: X-Spam-Status: No, score=-6.177 tagged_above=-999 required=5 tests=[AWL=-0.178, 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 3lfkHz6VBbJr for ; Mon, 15 Jul 2013 20:19:32 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 680FF21E8168 for ; Mon, 15 Jul 2013 20:19:32 -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 r6G3JTku022566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Jul 2013 03:19:31 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 r6G3JSIY029202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 03:19:29 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6G3JR7p029154; Tue, 16 Jul 2013 03:19:28 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 15 Jul 2013 20:19:27 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Mon, 15 Jul 2013 23:19:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7B23E7E8-2432-48B8-A2BF-75653D89936F@oracle.com> References: <20130712043221.11767.74779.idtracker@ietfa.amsl.com> <1F4B4D44-BD3E-4995-876A-147832C925F9@oracle.com> 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] I-D Action: draft-kaplan-stir-ikes-out-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 03:19:39 -0000 On Jul 15, 2013, at 4:05 PM, Torrey Searle = wrote: > I really like your draft, especially the fact that inter networks with = ss7. Just have a initial comment that in the case of the UUI header, = the spec should probably specify that the Protocol Discriminator for = the UUI header should be set to 00 - User Specific Coding. Though it = might me an interesting question if it is possible to use a new value = for the protocol discriminator to easily identify that the value in the = UUI header is a signature. Crap, I forgot about the protocol discriminator. I don't mean I forgot = to mention it, I mean I forgot about the byte it takes, not to mention = the type and length bytes. That means there're only 128 bytes = available, which for a 1024-bit private key means all of those 128 bytes = will be the signature. So I'll have to move the key index and timestamp = fields into the Call-Reference param instead. Ugh. But anyway, yeah good catch, the discriminator should probably be 0x00. > Also how about the case where bob@example.com gets aliased to an e164 = when reaching the pstn gateway? I assume the pstn gateway would "own" = the e164 and can re-sign the call before forwarding, but would it be = interesting to mention this case in the spec? Does that ever happen in the PSTN gateways? I know it happens in some = service providers (like skype for example), but I thought it happened on = some SIP or H.323 system just before it reached the PSTN GW. = Regardless, yes I should mention that in the draft too. Thanks for the feedback! -hadriel From dhc@dcrocker.net Mon Jul 15 21:53: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 3FE8921E8197 for ; Mon, 15 Jul 2013 21:53:50 -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 CLJaC53uSfMp for ; Mon, 15 Jul 2013 21:53:45 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 44DF521E8186 for ; Mon, 15 Jul 2013 21:53: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 r6G4rfAG012048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Jul 2013 21:53:44 -0700 Message-ID: <51E4D1B4.4060504@dcrocker.net> Date: Mon, 15 Jul 2013 21:53:08 -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]); Mon, 15 Jul 2013 21:53:45 -0700 (PDT) Cc: IETF STIR Mail List Subject: Re: [stir] Draft STIR 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, 16 Jul 2013 04:53:50 -0000 Jon, On 7/15/2013 3:38 PM, Peterson, Jon wrote: > On 7/14/13 8:51 PM, "Dave Crocker" wrote: > I don't think there's much value in arguing over what you think what I > said means, ... > For the two approaches to be "fully redundant," there > would be no case you could use one where you couldn't use the other, and > no use of one that the other couldn't also fulfill. Since you say arguing is of little value, it's odd that you then went on to impose a definition that significantly conflicts with the characterization I provided repeatedly: The caller creates the authentication information for every call, using both mechanisms. > I think people are arguing for slightly different scopes for out-of-band, End-to-end vs. only in gateways vs. ...? are not "slight" differences. They probably have significant technical differences and are certain to have substantial operational differences. >> Without a fair sense of answers to all of the above, we can't have any >> idea what the engineering challenges for the mechanism will be, or even >> whether the mechanism is viable. > > Some few times in this thread, people have mentioned the existence of > smart phone services that do a form of out-of-band verification today. That's not terribly important, since I don't recall anyone saying that it was not technically feasible to perform the function. The concern has been about costs and likely (or unlikely) scaling of adoption and use, in terms of the general problem that is motivating the group. >>> Instead, what I've said is that there are >>> different applicabilities for these two proposed mechanisms. >> >> So sometimes use one, sometimes use the other, sometimes use both? >> >> There's a nice term for such an approach and, I might add, quite a bit >> of experience with its applicability. The term is "non-interoperable'. > > Well, sometimes, DKIM gets used. And sometimes PGP gets used. Jon, seriously? You're invoking that one again? One of the hallmarks of constructive exchange is that both sides must pay attention to what the other says and must incorporate it into following responses. This permits some degree of incremental progress. Instead, here you seem to have entirely missed the response I offered when you earlier attempted to call DKIM and PGP 'redundant'. Since repetition seems to be the hallmark of today's mailing list activity: they are entirely different mechanisms, in terms of syntax and semantics. In other words: they have nothing to do with each other. So whatever you intended to demonstrate by the DKIM/PGP reference, again, the reality is that it's irrelevant to the current discussion. > The entities > that use DKIM and the entities that use PGP aren't really the same. They > don't coordinate. I'm sure it happens that sometimes both are used > simultaneously. The interoperability failure there isn't apparent to me. And this seems to continue the irrelevancy to somehow claim that it shouldn't be classed as an interoperability failure and this somehow is responsive to my own reference? So let's be clear: interoperability failure means that two (or more) entities that are seeking to interoperate using the same protocols fail to do so. My previous reference to non-interoperability was pointing out that the caller and callee are seeking to validate the Caller-ID value and that having the usage mixture of mechanisms that you described is likely to lead to one of them using one mechanism and the other use a different one, thereby ensuring that they fail to achieve the validation they both wanted. >>> What I have said in the past that may have confused you is that I >>> envisioned that an authentication service (i.e., the originating side) >>> that supported both in-band and out-of-band should ideally use both, >> >> And you don't think that makes it fully redundant for the caller? (And >> fully redundant for /some/ callees.) > > In the case where in-band and out-of-band on the originating are literally > being managed by the same device or service, I think it's about as > redundant as a SIP INVITE proposing two codecs in the hope that the far You think that including an offer list -- a list of options -- is comparable cost to the caller's doing all the work of performing two authentication functions? Really? (Now, if you had cited MIME multipart/alternative, it might be a bit more interesting, but you didn't, so it isn't...) >>> To me, this out-of-band question is a question about the problem we're >>> aiming to solve, not the solution mechanisms. Are we going to try to do >>> anything about the parts of the robocalling and voicemail hacking >>> problem >>> where SIP is not the protocol used on both side, or are we going to skip >>> that? And if the latter, are we addressing enough of the problem for >>> this >>> to be worth our effort? >> >> So a proposed solution isn't about solutions but about the problem? >> Sorry, but I've no idea what this paragraph means or how it responds. > > If the problem is to try to address robocalling and voicemail hacking, and > those problems are not limited than the IP world, then should the scope of > our work be limited to the IP world? As you state it, that's not the issue here. The issue here is how to approach dealing with a very complex operational environment. A term like "divide and conquer" is often applied. More specifically -- and quite common to IETF efforts that are successful -- is to start with developing the smallest useful solution that can be deployed, and then add to it... over time. So the most important issue is about project (working group) sequencing. In particular, /start/ with a clean, SIP-based mechanism. After that is done, consider enhancements that extend its utility. >> Really, my note asked very simple, very basic technical questions about >> the out-of-band 'proposal'. Very simple. Very basic. >> >> For those promoting an immediate effort at producing an out-of-band >> solution, the answers also out to be very simple and basic. > > I don't have all the answers about the solution. I do think we have a > reasonable idea of what the problem is, and what some approaches are - > enough to charter it and to work on it. If the listed "approaches" are clear enough to permit engineering estimates of feasibility, you are correct. Unfortunately, we are not doing very well in garnering such technical substance. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ekr@rtfm.com Mon Jul 15 22:33: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 1B17811E8231 for ; Mon, 15 Jul 2013 22:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.357 X-Spam-Level: X-Spam-Status: No, score=-102.357 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xw2AgOIsNgiB for ; Mon, 15 Jul 2013 22:33:41 -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 EBAE511E8253 for ; Mon, 15 Jul 2013 22:33:28 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id 2so151738qea.7 for ; Mon, 15 Jul 2013 22:33: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=QAmkzuq1G5Ze0smr9Yu5TuP38tVXrPGtpTMJZB3FpOE=; b=hLrf78MUUtPzgpI+Zm8+zNXhh5i+I2ZFqCWAFDQQ+vCkKGtEyPTz6wUqCJKfypFYSI EtOAIAsmdkxstYHgqsARweFFttZ094OsVIbWN6Ytr1604/j39YJQGvS/KGiaxty5KO6A o8Bxj9pxw/eWvcBnfMbKmhM+izoL2wSI1ZGH8oyIY6aNf+eAzqxfBN6NDKkS4xFs7NI5 aWIl4Tw0jA3niYBeQzD/kIyNnsJbOX/WdSfhlgMODjTJZnv4E6MWkbup+M7PFu7l3MDi 1M6o9BwnWAGUkROVQU0zc4pkO+gb0RRFna88TLhFXc+C3c241Zh5DHN5QvMsrrBce2+m OQXw== X-Received: by 10.224.79.14 with SMTP id n14mr799424qak.114.1373952808211; Mon, 15 Jul 2013 22:33:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.48.234 with HTTP; Mon, 15 Jul 2013 22:32:48 -0700 (PDT) X-Originating-IP: [210.229.158.64] In-Reply-To: <51E4708C.4000206@dcrocker.net> References: <51E4708C.4000206@dcrocker.net> From: Eric Rescorla Date: Mon, 15 Jul 2013 22:32:48 -0700 Message-ID: To: Dave Crocker Content-Type: multipart/alternative; boundary=047d7bdca38012661704e19a51e5 X-Gm-Message-State: ALoCoQnVU3HtFqJG9hsS+k/M4dFmFkNHhJkNVXTWNq+l7Daier4Rw4yqPaAfa245kRnNVH6TNDu5 Cc: "stir@ietf.org" Subject: Re: [stir] Draft posted (draft-rescorla-stir-fallback-00) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 05:33:47 -0000 --047d7bdca38012661704e19a51e5 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 15, 2013 at 2:58 PM, Dave Crocker wrote: > Eric, > > Comments in-line (or should I stash them on a web page, for possible > retrieval...?) > Sure, if you like. > > Abstract >> >> A major challenge with RFC 4474-style identity assertions has been >> that SIP operates in highly mediated and interworked environments. >> > > Given the lack of implementation and deployment experience for RFC4474, > there doesn't seem to be any public evidence of what specific problems the > document has. So the opening attribution is problematic. > > A reference like "RFC 4474-style" is quite ambiguous; there's no > established practice or other way to know what it refers to in technical > terms, and certainly not for folk outside this close-knit club. > > I suspect that your core point hinges on something that is actually far > more broadly applicable than just for that specification. Perhaps as an > alternative opening: > > Any SIP-based authentication mechanism that relies on the carriage of > its information in SIP headers encounters a basic problem. SIP typically > operates in highly mediated and... > Thanks. I'll take this under advisement for a future revidion. > >> While the core network of the PSTN remains fixed, the endpoints of >> the telephone network are becoming increasingly programmable and >> sophisticated. Landline "plain old telephone service" deployments, >> > > Not just the end-points. > > All of the SIP-based components in the sequence ought to be equally > programmable, certainly including SIP/PSTN gateways. > > And gateways are the more typical place for performing channel-specific > tunneling hacks like this. > > especially in the developed world, are shrinking, and increasingly >> being replaced by three classes of intelligent devices: smart >> phones, IP PBXs, and terminal adapters. All three are general >> purpose computers, and typically all three have Internet access as >> well as access to the PSTN. This provides a potential avenue for >> building an authentication system that changes only the endpoints >> while leaving the PSTN intact. >> > > A benefit of, instead, placing the function in gateways is that it is only > active when it is needed and by the relatively few nodes that need the > special capability. So this works for more users, as indicated by your > second example, below. > I'm not sure what you're objecting to here. Is it just that you would like me to namecheck gateways earlier on? > > 3. Architectural Options >> > ... > >> There are roughly two plausible dataflow architectures for the CPS: >> >> >> >> Rescorla Expires January 14, 2014 [Page 5] >> >> Internet-Draft Caller-ID Fallback July 2013 >> >> >> o The callee registers with the CPS. When the caller wishes to >> place a call to the callee, it sends the CPR to the CPS which >> forwards it to the callee. >> > > > >> o The caller stores the CPR with the CPS at the time of call >> placement. When the callee receives the call, it contacts the CPS >> and retrieves the CDR. >> > > The caller actions is the same for both. > > The difference is simply a push (forwarding) vs. pull (retrieving) model > for the callee-side of things. Yes? > Yes. > > While the first architecture is roughly isomorphic to current VoIP >> protocols, it shares their drawbacks. Specifically, the callee must >> maintain a full-time connection to the CPS to serve as a notification >> channel. >> > > That depends upon what is registered. If a contact-me-at entry is > registered, it does not require maintaining an open connection, does it > I'm not sure I follow what you're suggesting. > This comes with the usual networking costs to the callee >> and is especially problemtatic for mobile endpoints. Thus, we focus >> on the second architecture in which the PSTN incoming call serves as >> the notification channel and the callee can then contact the CPS to >> retrieve the CPR. >> > > These don't have to be mutually exclusive. > > Forwarding can be a performance optimization, available if the callee has > registered, with pull (storage awaiting retrieval) is the default. > That might or might not work. 4. Strawman Architecture >> >> In this section, we discuss a strawman architecture along the lines >> described in the previous section. This discussion is deliberately >> sketchy, focusing on broad concepts and skipping over details. The >> intent here is merely to provide a rough concept, not a complete >> solution. >> >> 4.1. Phone Number Authentication >> >> We start from the premise that each phone number in the system is >> associated with a set of credentials which can be used to prove >> ownership of that number. For purposes of exposition we will assume >> > > Prove 'ownership' or prove 'assignment'? > I'm happy to use "assignment" here. Perhaps there's some even more precise term that we could be using, like "authorization to use". > > that ownership is associated with the endpoint (e.g., a smartphone) >> but it might well be associated with a gateway acting for the >> endpoint instead. It might be the case that multiple entities are >> able to act for a given number, provided that they have the >> appropriate authority. The question of how an entity is determined >> to have control of a given number is out of scope for this document. >> >> 4.2. Call Placement Service >> > ... > >> Once Alice has stored the CPR, she then places the call to Bob as >> usual. At this point, Bob's phone would usually ring and display >> Alice's number (+1.111.111.1111), which is provided by the usual >> caller-id mechanisms (i.e., the CIN field of the IAM). Instead, >> Bob's phone transparently contacts the CPS and requests any current >> CPRs from Alice. The CPS responds with any such CPRs (assuming they >> exists). If such a CPR exists, he can then present the callerid >> information as valid. Otherwise, the call is unverifiable. Note >> that this does not necessarily mean that the call is bogus; because >> we expect incremental deployment many legitimate calls will be >> unverifiable >> > > This 'Note' sentence is more significant than it's placement in the > document would seem to indicate. It goes to a core challenge to make any > of these mechanisms useful. > I've been sort of hoping there would be some meta-document where this could be placed more prominently. > >> 4.3. Security Analysis >> >> The primary attack we seek to prevent is an attacker convincing the >> callee that a given call is from some other caller C. There are two >> scenarios to be concerned with: >> >> o The attacker wishes to simulate a call when none exists. >> > > What does that mean? > It means convincing the victim that there is a call from someone to him when in fact there is not (and presumably that the call that the victim is currently answering is that call). I.e., it's the threat you're suggesting is the primary purpose of the WG below. Sorry if the phrasing was confusing. > o The attacker wishes to substitute himself for an existing call as >> described in Section 4.3.1 >> > > Neither of these sounds like the scenario that I thought I'd been hearing > during the life of this mailing list: > > The attacker initiates a call, using a Caller-ID value for which they > do not have authorization. > > Confusion about this suggests that the wg charter needs to be explicit and > clear about the threat vectors that are to be of concern for the wg effort. > Well, I think that's always valuable, but I think in this case it's primarily an issue of phrasing, since this is the first threat I am mentioning above. > >> If an attacker can inject fake CPRs into the CPS or in the >> >> >> >> Rescorla Expires January 14, 2014 [Page 7] >> >> Internet-Draft Caller-ID Fallback July 2013 >> >> >> communication from the CPS to the callee, he can mount either attack. >> In order to prevent this, either the communication to the CPS should >> be secured in transport (e.g., with TLS) or the CPRs should be >> digitally signed by the caller and verified by the callee >> (Section 5.2. For privacy and robustness reasons, both are >> > > both are -> using both is > > Anyhow, really? Belts and suspenders? > Yes. > With the object-based approach, signing isn't enough to provide privacy. > It needs confidentiality. Since it's unlikely the caller and callee > information will be encrypted, it won't provide meta-data privacy even then. > I'm not taking a position on whether it's likely or not. As you no doubt noticed, this document discusses a mechanism for doing just that, so, no, I don't think it has probability 0. > If object-based authentication is performed, TLS provides no value-add for > authentication. > Not so. It makes anti-replay far easier in threat environments where you trust the CPS. -Ekr --047d7bdca38012661704e19a51e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jul 15, 2013 at 2:58 PM, Dave Crocker <= ;dhc@dcrocker.net= > wrote:
Eric,

Comments in-line (or should I stash them on a web page, for possible retrie= val...?)

Sure, if you like.
<= br>
=A0

Abstract

=A0 =A0A major challenge with RFC 4474-style identity assertions has been =A0 =A0that SIP operates in highly mediated and interworked environments.

Given the lack of implementation and deployment experience for RFC4474, the= re doesn't seem to be any public evidence of what specific problems the= document has. So the opening attribution is problematic.

A reference like "RFC 4474-style" is quite ambiguous; there's= no established practice or other way to know what it refers to in technica= l terms, and certainly not for folk outside this close-knit club.

I suspect that your core point hinges on something that is actually far mor= e broadly applicable than just for that specification. =A0Perhaps as an alt= ernative opening:

=A0 =A0 Any SIP-based authentication mechanism that relies on the carriage = of its information in SIP headers encounters a basic problem. =A0SIP typica= lly operates in highly mediated and...

= Thanks. I'll take this under advisement for a future revidion.




=A0 =A0While the core network of the PSTN remains fixed, the endpoints of =A0 =A0the telephone network are becoming increasingly programmable and
=A0 =A0sophisticated. =A0Landline "plain old telephone service" d= eployments,

Not just the end-points.

All of the SIP-based components in the sequence ought to be equally program= mable, certainly including SIP/PSTN gateways.

And gateways are the more typical place for performing channel-specific tun= neling hacks like this.

=A0 =A0especially in the developed world, are shrinking, and increasingly =A0 =A0being replaced by three classes of intelligent devices: =A0smart
=A0 =A0phones, IP PBXs, and terminal adapters. =A0All three are general
=A0 =A0purpose computers, and typically all three have Internet access as =A0 =A0well as access to the PSTN. =A0This provides a potential avenue for<= br> =A0 =A0building an authentication system that changes only the endpoints =A0 =A0while leaving the PSTN intact.

A benefit of, instead, placing the function in gateways is that it is only = active when it is needed and by the relatively few nodes that need the spec= ial capability. =A0So this works for more users, as indicated by your secon= d example, below.

I'm not sure what you're objecting= to here. Is it just that you would like me to
namecheck gateways= earlier on?



3. =A0Architectural Options
...
=A0 =A0There are roughly two plausible dataflow architectures for the CPS:<= br>


Rescorla =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Expires January 14, 2014 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0[Page 5]
=0C
Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 Caller-ID Fallback =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0July 2013


=A0 =A0o =A0The callee registers with the CPS. =A0When the caller wishes to=
=A0 =A0 =A0 place a call to the callee, it sends the CPR to the CPS which =A0 =A0 =A0 forwards it to the callee.
>
=A0 =A0o =A0The caller stores the CPR with the CPS at the time of call
=A0 =A0 =A0 placement. =A0When the callee receives the call, it contacts th= e CPS
=A0 =A0 =A0 and retrieves the CDR.

The caller actions is the same for both.

The difference is simply a push (forwarding) vs. pull (retrieving) model fo= r the callee-side of things. =A0Yes?

Ye= s.

=A0

=A0 =A0While the first architecture is roughly isomorphic to current VoIP =A0 =A0protocols, it shares their drawbacks. =A0Specifically, the callee mu= st
=A0 =A0maintain a full-time connection to the CPS to serve as a notificatio= n
=A0 =A0channel.

That depends upon what is registered. =A0If a contact-me-at entry is regist= ered, it does not require maintaining an open connection, does it

I'm not sure I follow what you're sugges= ting.



=A0 =A0This comes with the usual networking costs to the callee
=A0 =A0and is especially problemtatic for mobile endpoints. =A0Thus, we foc= us
=A0 =A0on the second architecture in which the PSTN incoming call serves as=
=A0 =A0the notification channel and the callee can then contact the CPS to<= br> =A0 =A0retrieve the CPR.

These don't have to be mutually exclusive.

Forwarding can be a performance optimization, available if the callee has r= egistered, with pull (storage awaiting retrieval) is the default.

That might or might not work.


4. =A0Strawman Architecture

=A0 =A0In this section, we discuss a strawman architecture along the lines<= br> =A0 =A0described in the previous section. =A0This discussion is deliberatel= y
=A0 =A0sketchy, focusing on broad concepts and skipping over details. =A0Th= e
=A0 =A0intent here is merely to provide a rough concept, not a complete
=A0 =A0solution.

4.1. =A0Phone Number Authentication

=A0 =A0We start from the premise that each phone number in the system is =A0 =A0associated with a set of credentials which can be used to prove
=A0 =A0ownership of that number. =A0For purposes of exposition we will assu= me

Prove 'ownership' or prove 'assignment'?

I'm happy to use "assignment" here. Perhaps= there's some even more precise
term that we could be using, = like "authorization to use".

=A0

=A0 =A0that ownership is associated with the endpoint (e.g., a smartphone)<= br> =A0 =A0but it might well be associated with a gateway acting for the
=A0 =A0endpoint instead. =A0It might be the case that multiple entities are=
=A0 =A0able to act for a given number, provided that they have the
=A0 =A0appropriate authority. =A0The question of how an entity is determine= d
=A0 =A0to have control of a given number is out of scope for this document.=

4.2. =A0Call Placement Service
...
=A0 =A0Once Alice has stored the CPR, she then places the call to Bob as =A0 =A0usual. =A0At this point, Bob's phone would usually ring and disp= lay
=A0 =A0Alice's number (+1.111.111.1111), which is provided by the usual=
=A0 =A0caller-id mechanisms (i.e., the CIN field of the IAM). =A0Instead, =A0 =A0Bob's phone transparently contacts the CPS and requests any curr= ent
=A0 =A0CPRs from Alice. =A0The CPS responds with any such CPRs (assuming th= ey
=A0 =A0exists). =A0If such a CPR exists, he can then present the callerid =A0 =A0information as valid. =A0Otherwise, the call is unverifiable. =A0Not= e
=A0 =A0that this does not necessarily mean that the call is bogus; because<= br> =A0 =A0we expect incremental deployment many legitimate calls will be
=A0 =A0unverifiable

This 'Note' sentence is more significant than it's placement in= the document would seem to indicate. =A0It goes to a core challenge to mak= e any of these mechanisms useful.

I'= ;ve been sort of hoping there would be some meta-document where this
could be placed more prominently.


<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

4.3. =A0Security Analysis

=A0 =A0The primary attack we seek to prevent is an attacker convincing the<= br> =A0 =A0callee that a given call is from some other caller C. There are two<= br> =A0 =A0scenarios to be concerned with:

=A0 =A0o =A0The attacker wishes to simulate a call when none exists.

What does that mean?

It means convincin= g the victim that there is a call from someone to him
when in fac= t there is not (and presumably that the call that the victim
is currently answering is that call).

I.e., it'= ;s the threat you're suggesting is the primary purpose of the WG
<= div>below. Sorry if the phrasing was confusing.



=A0 =A0o =A0The attacker wishes to substitute himself for an existing call = as
=A0 =A0 =A0 described in Section 4.3.1

Neither of these sounds like the scenario that I thought I'd been heari= ng during the life of this mailing list:

=A0 =A0The attacker initiates a call, using a Caller-ID value for which the= y do not have authorization.

Confusion about this suggests that the wg charter needs to be explicit and = clear about the threat vectors that are to be of concern for the wg effort.=

Well, I think that's always valuab= le, but I think in this case it's primarily
an issue of phrasing, since this is the first threat I am mentioning a= bove.




=A0 =A0If an attacker can inject fake CPRs into the CPS or in the



Rescorla =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Expires January 14, 2014 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0[Page 7]
=0C
Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 Caller-ID Fallback =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0July 2013


=A0 =A0communication from the CPS to the callee, he can mount either attack= .
=A0 =A0In order to prevent this, either the communication to the CPS should=
=A0 =A0be secured in transport (e.g., with TLS) or the CPRs should be
=A0 =A0digitally signed by the caller and verified by the callee
=A0 =A0(Section 5.2. =A0For privacy and robustness reasons, both are

=A0 =A0 =A0both are -> using both is

Anyhow, really? =A0Belts and suspenders?

Yes.

=A0
With the object-based approach, signing isn't enough to provide privacy= . =A0It needs confidentiality. =A0Since it's unlikely the caller and ca= llee information will be encrypted, it won't provide meta-data privacy = even then.

I'm not taking a position on whether i= t's likely or not. As you no doubt noticed,
this document dis= cusses a mechanism for doing just that, so, no, I don't think
it has probability 0.

=A0
If object-based authentication is performed, TLS provides no value-add for = authentication.

Not so. It makes anti-r= eplay far easier in threat environments where you trust the CPS.

-Ekr
=A0
--047d7bdca38012661704e19a51e5-- From philippe.fouquart@orange.com Tue Jul 16 01:56: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 B825A11E8271 for ; Tue, 16 Jul 2013 01:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, 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 up3g-XujunnW for ; Tue, 16 Jul 2013 01:56:18 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id EEC5D11E826B for ; Tue, 16 Jul 2013 01:56:09 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 4098D22CD07; Tue, 16 Jul 2013 10:56:09 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 2132227C057; Tue, 16 Jul 2013 10:56:09 +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, 16 Jul 2013 10:56:08 +0200 From: To: Henning Schulzrinne , 'Michael Hammer' Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIC/Xfx9OM2CUaqk2gsBTAQDJlfoXKAgAAEgQCAAANtAIAAAaIAgAAGyICAAAH7AIAABkaAgAACpACAAA3sAIAAAhCAgADroICAAEL+gIAAAeAAgABhRACAAB8HgIAADPeAgAAKzoCABGLzgIAAA5aAgAAHEQCAAPRtYA== Date: Tue, 16 Jul 2013 08:56:08 +0000 Message-ID: <21393_1373964969_51E50AA9_21393_2845_1_B5939C6860701C49AA39C5DA5189448B0B4651@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> <3145728A-87FA-4217-9B93-E14A01307784@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC16DAD@EX2K10MB1.corp.yaanatech.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.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.16.81239 Cc: "stir@ietf.org" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 08:56:23 -0000 Charter-wise I would also prefer this phrasing than referring to authentica= tion or "authenticate the originator of a SIP session".=20 > "is the caller entitled to use the telephone number in the callerID infor= mation" I understand that in some cases asserting that the caller is entitled to us= e a phone number may be enough for the receiving end to provide a given ser= vice and can therefore be used as some 'weak' or implicit authentication me= chanism - all networks have to do that sometimes.=20 Given the context, however, I'm with Dave's "meta point" on this. Using aut= hentication would be confusing for me (mostly because of what the term conv= eys with regard to the network the sip user is registered with): a) such authentication is generally carried out to provide a service to the= subscriber with the TN, here the calling party, more rarely the called par= ty; and=20 b) it implies that the primary piece of information with which you identify= the user is indeed the TN, whereas as a rule, [not all but] a large number= of networks (SIP-based and others) generally try and separate what you ide= ntify/authenticate users with and what other users employ (the TNs) to set = up a session/call with them - ie precisely try and not use TNs for the purp= ose of identification/authentication.=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: Monday, July 15, 2013 9:21 PM To: 'Michael Hammer' Cc: stir@ietf.org Subject: Re: [stir] Draft STIR Charter I think the classical terms of "authentication" and "authorization" don't q= uite apply here, as we're trying to ascertain the right to use an identifie= r, not authenticate to a service (establish identity) or be authorized to u= se a service (establish capability). In some cases, the caller may well aut= henticate to the provider or the carrier may authenticate to the number adm= inistrator and be authorized to retrieve a public key or certificate, but t= hat's a separate component. One way to phrase this is to state simply "is the caller entitled to use th= e telephone number in the callerID information", avoiding the a*e vs. a*o d= ebate altogether and, I think, stating the goal reasonably accurately. One indication that this is different is that none of us have been talking = about using RADIUS/DIAMETER or 802.1.x or Kerberos for this - not just as a= specific protocol, but as a model. I'm guessing that neither DKIM or SPF c= onsider that authorization. (A quick check of RFC 4871 shows only 3 uses of= the term authorize, and they seem to relate to authorization to use an out= going mail server. The term "authentication" appears more frequently, if lo= osely, mostly as "authenticated email" or "authenticity".) -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Mic= hael Hammer Sent: Monday, July 15, 2013 2:56 PM To: hadriel.kaplan@oracle.com; dcrocker@bbiw.net Cc: stir@ietf.org; housley@vigilsec.com Subject: Re: [stir] Draft STIR Charter Would you want to say: "to verify the *authenticated* originator" Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Had= riel Kaplan Sent: Monday, July 15, 2013 2:43 PM To: dcrocker@bbiw.net Cc: IETF STIR Mail List; Russ Housley Subject: Re: [stir] Draft STIR Charter On Jul 12, 2013, at 7:43 PM, Dave Crocker wrote: > Meta-point: >=20 > The text is only about authentication, but the discussion has been about authorization. For example one might have an authenticated originato= r value that is not the string displayed as Caller-ID.[*] I understood the= purpose of the wg to be ensuring that the displayed string was authorized = by its assignee. >=20 > If no one cares about this distinction and everyone feels that "authenticate the originator" is sufficiently precise and accurate, fine, b= ut I thought it worth making sure. It took me a while to grok what you mean, because from my perspective STIR = is about verifying the received Caller-ID is authentic for a given call req= uest, and authenticating it to be so - not that STIR is authorizing the ori= ginator to make a call. But really what you mean is STIR is about verifyin= g the originator of the call request is authorized to use the claimed calle= r-id. How about this: As its first work item, the working group will specify a SIP=20 header-field-based mechanism to verify the originator of a=20 SIP session is authorized to use the claimed source identifier,=20 where the identity is a telephone number and the session is=20 established with SIP end to end. -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 ___________________________________________________________________________= ______________________________________________ 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 Tue Jul 16 05:54: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 1CF2B11E80E0 for ; Tue, 16 Jul 2013 05:54:55 -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.130, 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 ZgtuVpADnqps for ; Tue, 16 Jul 2013 05:54:50 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id E774021F9DBB for ; Tue, 16 Jul 2013 05:54:48 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 117B32646A6; Tue, 16 Jul 2013 14:54:45 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id E123227C05B; Tue, 16 Jul 2013 14:54:44 +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, 16 Jul 2013 14:54:44 +0200 From: To: Hadriel Kaplan , Brian Rosen Thread-Topic: Rollout timeframe (was: RE: [stir] Draft STIR Charter) Thread-Index: AQHOgiOkCKZGaMqFiU2W26+FbDAtBg== Date: Tue, 16 Jul 2013 12:54:43 +0000 Message-ID: <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.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.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.16.121521 Cc: IETF STIR Mail List , Henning Schulzrinne Subject: [stir] Rollout timeframe (was: RE: Draft STIR Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 12:54:55 -0000 I'll use Hadriel's aside note (or was it?) as an opportunity to point out t= hat in addition to the timeframe related to the introduction of the stir te= chnology itself in the network elements, endpoints etc (which I don't disag= ree with), the 'administrative' part of that effort must also be considered= /added: apologies if I'm stating the obvious or completely missed the purpo= se of all this, but it seems to me that it all relies on credentials being = issued directly or indirectly by the "numbering plan authority/administrato= r". This 'administrative' part could indeed be done in parallel and I appreciat= e that this effort may be more focused on some numbering plans than others,= which may speed up the work for those, but=20 a) it is to me quite as much on the critical path as the pure implementatio= n part, which would be pointless without it,=20 b) contrary to technology deployment, incremental/gradual introduction of s= uch a framework under a given CC doesn't really make sense, it's pretty muc= h on/off and=20 c) it will be far from trivial for a lot of numbering plans and may take co= nsiderable effort and education.=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: Tuesday, July 16, 2013 2:08 AM To: Brian Rosen Cc: IETF STIR Mail List; Henning Schulzrinne Subject: Re: [stir] Draft STIR Charter [snip] And it's not a "couple years". It will take us longer than that just to ge= t an out-of-band solution published as an RFC, let alone the timeframe need= ed for it to be deployed and a Tier-2 CLEC or its customers to use it. Let's say it takes 2 years to get an out-of-band into an RFC. After that m= ore time for the vendors implement it, getting tested in carriers, etc. Ev= en 3 years altogether would be a minor miracle. Meanwhile, how long do you= think before a significant majority of the carriers in North America inter= connect using SIP? 5 years? Let's say it's 7 years. The time difference = between the 3 years to get out-of-band and 7 years for in-band would be 4 y= ears. We'd do all that work, carriers would spend all that time and money,= all for a 4-year lifespan for 15% caller-id coverage?!? How does that mak= e any sense? -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, 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 michael.hammer@yaanatech.com Tue Jul 16 06:11: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 45AC411E80E9 for ; Tue, 16 Jul 2013 06:11:41 -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 Aw3BdLXADUqL for ; Tue, 16 Jul 2013 06:11: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 95FB811E810E for ; Tue, 16 Jul 2013 06:11: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; Tue, 16 Jul 2013 06:11:31 -0700 From: Michael Hammer To: "philippe.fouquart@orange.com" , "hadriel.kaplan@oracle.com" , "br@brianrosen.net" Thread-Topic: [stir] Rollout timeframe (was: RE: Draft STIR Charter) Thread-Index: AQHOgiOuTJJOkkJ/sEer6i+4AYu/P5lnRIJA Date: Tue, 16 Jul 2013 13:11:30 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@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: [10.17.100.87] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_006F_01CE8204.74CC9E10" MIME-Version: 1.0 Cc: "stir@ietf.org" , "Henning.Schulzrinne@fcc.gov" Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 13:11:41 -0000 ------=_NextPart_000_006F_01CE8204.74CC9E10 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Philippe, If the solution is kept simple, the education part should not require much effort. I don't see why the numbering plan would have any effect on how trivial it might be, since asking the question what is your E.164 number should be easy to answer. Yes, it is possible to make administrative aspects complicated, but if that is painful, don't go there. Could you elaborate more on that? For example, if ultimately what is needed is a cert that binds a private key with an E.164 number, it could be made more complicated by also including the chain of service providers through which the key is delegated, but that conflation of delegation complexity with the act of knowing a private key matches with an E.164 number may be an act of shooting oneself in the foot. I still like Occam's Razor and think that would be very useful here. Thanks, Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of philippe.fouquart@orange.com Sent: Tuesday, July 16, 2013 8:55 AM To: Hadriel Kaplan; Brian Rosen Cc: IETF STIR Mail List; Henning Schulzrinne Subject: [stir] Rollout timeframe (was: RE: Draft STIR Charter) I'll use Hadriel's aside note (or was it?) as an opportunity to point out that in addition to the timeframe related to the introduction of the stir technology itself in the network elements, endpoints etc (which I don't disagree with), the 'administrative' part of that effort must also be considered/added: apologies if I'm stating the obvious or completely missed the purpose of all this, but it seems to me that it all relies on credentials being issued directly or indirectly by the "numbering plan authority/administrator". This 'administrative' part could indeed be done in parallel and I appreciate that this effort may be more focused on some numbering plans than others, which may speed up the work for those, but a) it is to me quite as much on the critical path as the pure implementation part, which would be pointless without it, b) contrary to technology deployment, incremental/gradual introduction of such a framework under a given CC doesn't really make sense, it's pretty much on/off and c) it will be far from trivial for a lot of numbering plans and may take considerable effort and education. 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: Tuesday, July 16, 2013 2:08 AM To: Brian Rosen Cc: IETF STIR Mail List; Henning Schulzrinne Subject: Re: [stir] Draft STIR Charter [snip] And it's not a "couple years". It will take us longer than that just to get an out-of-band solution published as an RFC, let alone the timeframe needed for it to be deployed and a Tier-2 CLEC or its customers to use it. Let's say it takes 2 years to get an out-of-band into an RFC. After that more time for the vendors implement it, getting tested in carriers, etc. Even 3 years altogether would be a minor miracle. Meanwhile, how long do you think before a significant majority of the carriers in North America interconnect using SIP? 5 years? Let's say it's 7 years. The time difference between the 3 years to get out-of-band and 7 years for in-band would be 4 years. We'd do all that work, carriers would spend all that time and money, all for a 4-year lifespan for 15% caller-id coverage?!? How does that make any sense? -hadriel _______________________________________________ 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_006F_01CE8204.74CC9E10 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NjEzMTEyOVowIwYJKoZIhvcNAQkEMRYEFAq/HNGgjgj2zAGKX0TmLC/MNVFHMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAcXgl4dRK192L+FUgCgwB3hMGf0PCdIr+4mZAVP9S soyFXsXMYgy7hWYLqW16NaQc1nIhQleXxmblUoCtOM83L+yZPuaqH4Pr6Ri+gPAqfJJ4bpocUNBT 2Dhxk0ElJq+8juLFQJX/szITCUeWQpjLVtATbX6tCHEGws1t0I+RUKWaPLFuaLLI6oU9+ec1poPH vWkaox7BMmLVeAOzCVcDEtGtkA5bVQ80HgicjkPcUTKtqkphExGETl7sTeFa2+nY503PkHf/wpJN p1hZ8zgPRVspzNg/rd+IkcJsZUZYrPgxwA/XgPkme/+aOS2rLm9gr05C/4Cb3uccnnLbT/jEyQAA AAAAAA== ------=_NextPart_000_006F_01CE8204.74CC9E10-- From br@brianrosen.net Tue Jul 16 06:17: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 50E7321F9B5D for ; Tue, 16 Jul 2013 06:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.243 X-Spam-Level: X-Spam-Status: No, score=-100.243 tagged_above=-999 required=5 tests=[AWL=0.194, 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 NYmpgu+VkkGh for ; Tue, 16 Jul 2013 06:17:16 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 45D4E21E8093 for ; Tue, 16 Jul 2013 06:17:14 -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=5KtFIqP/kSx20DgtIlWrl/uZaGSk3okbzEMPR/lfJ0w=; b=FlNPBvNzkF+Qaxzjx7utz7cH0oLTlzCHcKdreGfW9GZVgmsiP4HfIYjSsKhtvAyUG06AKSJw8Pg+q/xcX9cQ2aHNsoopjEjJ2Q5q5LtM9jodXnY5StKcTa5prcNtNmVqQ0WnqzNcSkJ8HG3pPiRMA8NWYqahTVpm8tlpH69/O+k=; Received: from neustargw.va.neustar.com ([209.173.53.233]:46249 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1Uz57w-000077-5Y; Tue, 16 Jul 2013 09:17:12 -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: <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Tue, 16 Jul 2013 09:16:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <80F50A9C-852B-45C8-9637-83DB1A718888@brianrosen.net> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> To: philippe.fouquart@orange.com 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: IETF STIR Mail List , Hadriel Kaplan , Henning Schulzrinne Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 13:17:20 -0000 This is an important point, and it's not something the IETF does = particularly well, especially the "take considerable effort and = education" part. =20 The IETF has been paying more attention to relationships with = governments and regulators lately, and I hope we will be able to = leverage that effort. Brian On Jul 16, 2013, at 8:54 AM, philippe.fouquart@orange.com wrote: > I'll use Hadriel's aside note (or was it?) as an opportunity to point = out that in addition to the timeframe related to the introduction of the = stir technology itself in the network elements, endpoints etc (which I = don't disagree with), the 'administrative' part of that effort must also = be considered/added: apologies if I'm stating the obvious or completely = missed the purpose of all this, but it seems to me that it all relies on = credentials being issued directly or indirectly by the "numbering plan = authority/administrator". >=20 > This 'administrative' part could indeed be done in parallel and I = appreciate that this effort may be more focused on some numbering plans = than others, which may speed up the work for those, but=20 > a) it is to me quite as much on the critical path as the pure = implementation part, which would be pointless without it,=20 > b) contrary to technology deployment, incremental/gradual introduction = of such a framework under a given CC doesn't really make sense, it's = pretty much on/off and=20 > c) it will be far from trivial for a lot of numbering plans and may = take considerable effort and education.=20 >=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 Hadriel Kaplan > Sent: Tuesday, July 16, 2013 2:08 AM > To: Brian Rosen > Cc: IETF STIR Mail List; Henning Schulzrinne > Subject: Re: [stir] Draft STIR Charter >=20 >=20 > [snip] >=20 > And it's not a "couple years". It will take us longer than that just = to get an out-of-band solution published as an RFC, let alone the = timeframe needed for it to be deployed and a Tier-2 CLEC or its = customers to use it. >=20 > Let's say it takes 2 years to get an out-of-band into an RFC. After = that more time for the vendors implement it, getting tested in carriers, = etc. Even 3 years altogether would be a minor miracle. Meanwhile, how = long do you think before a significant majority of the carriers in North = America interconnect using SIP? 5 years? Let's say it's 7 years. The = time difference between the 3 years to get out-of-band and 7 years for = in-band would be 4 years. We'd do all that work, carriers would spend = all that time and money, all for a 4-year lifespan for 15% caller-id = coverage?!? How does that make any sense? >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Tue Jul 16 06: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 DB14E21F9D30 for ; Tue, 16 Jul 2013 06:18:39 -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 VaS8S6I+RPNT for ; Tue, 16 Jul 2013 06:18:33 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 516D921E8090 for ; Tue, 16 Jul 2013 06:18:33 -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 r6GDIVVv006243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Jul 2013 13:18:32 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 r6GDIUJv028888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 13:18:31 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 r6GDIUT1012539; Tue, 16 Jul 2013 13:18:30 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 16 Jul 2013 06:18:30 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Tue, 16 Jul 2013 09:18:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <08F1C268-8FBF-4520-84EF-5B325D085119@oracle.com> References: To: "Peterson, Jon" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: IETF STIR Mail List Subject: Re: [stir] Out-of-bound STIR (was: Re: Draft STIR Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 13:18:40 -0000 On Jul 15, 2013, at 6:39 PM, "Peterson, Jon" = wrote: > There are some smartphone operating system vendors participating = pretty > actively in the IETF. Some of the things we're thinking about might be > things it would be better for operating system vendors to address. Just because someone from Google, Apple, Microsoft, or RIM attend the = IETF doesn't mean much. The IETF is a big place, and operating system = vendors do a lot of other things. It's like saying the DIME Working = Group could work on a SQL-based backend API description, because I = happen to also attend the IETF and my employer does a lot of SQL stuff. = I know nothing about the SQL world, and I don't attend DIME. :) > Perhaps more materially, the scope of out-of-band isn't limited to = smart > phones. It includes things like IP PBX makers. At least one IP PBX = maker > has previously come to the IETF with an interest in working on an > out-of-band mechanism here. I would like to talk to them. I am not an expert in their area at all, = but as I understand it most IP PBXs offer a scripting/plugin model = capability for third-parties/partners to write plugins, with an internal = API to access call data and make call control decisions, and with = external protocol access such as HTTP or LDAP or whatever. I have = looked at three big PBX vendors, and they all seem to have that model. = (heck, even my employer's SBCs offer that now, and plugins are much less = applicable to us than to a PBX vendor) The reason I mention it is because out-of-band STIR stuff is an obvious = application for such a plugin model. You deploy a database service, you = partner with (pay) the 3 or 4 big PBX vendors and write plugins for = their PBXs to talk to your database, and you write smartphone apps to = talk to your database and give the app out for free. You then could, = for example, offer caller-id verification service for free, but charge = money to Enterprises or consumers for putting additional related data = into the database/call, such as business-card type information, company = logo icon, etc. Or you resell that type of service through the = carriers, letting them sell the service to Enterprises for a cut of the = revenue. That's why I keep saying I don't understand why a smartphone-app-based = solution provider would want to come to the IETF. They shouldn't need a = standardized spec to follow, shouldn't want to be constrained to what = such a spec would make them do, and shouldn't want to wait for one to be = produced by the IETF. If anything, they might be helped by standardizing the plugin APIs used = for call data and control, in the smartphones and PBXs - but that's not = really possible or practical, for obvious reasons. -hadriel From br@brianrosen.net Tue Jul 16 06:23: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 8E50111E80E6 for ; Tue, 16 Jul 2013 06:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.251 X-Spam-Level: X-Spam-Status: No, score=-100.251 tagged_above=-999 required=5 tests=[AWL=0.186, 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 hDUzOjdNOoBz for ; Tue, 16 Jul 2013 06:23:05 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 012AF21F9D4A for ; Tue, 16 Jul 2013 06:23: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=44J0fjyuArCXKoH3+FVrlGZ3VHau7edg4gRcpnGcVgw=; b=XIi55q1UFaQmT3vnakFDC2zc7PK8JZYOYlD9kHW2PCTQpLKNLTDNG4kU9WeKhPuiByQLv5ZaOjqJO6Diya7mkXzXhfkyBLoaNH5K6tMGKzjo2ETZEwPrA1NV2DG35iyzSd8eTZ1miwMaQiPPCXQ5F8eAcnjjuLmAR511rcyPfpQ=; Received: from neustargw.va.neustar.com ([209.173.53.233]:45372 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1Uz5Da-0001Fd-3u; Tue, 16 Jul 2013 09:23:02 -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: <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> Date: Tue, 16 Jul 2013 09:23:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> To: Michael Hammer 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: "philippe.fouquart@orange.com" , "Henning.Schulzrinne@fcc.gov" , "hadriel.kaplan@oracle.com" , "stir@ietf.org" Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 13:23:19 -0000 There are a couple of aspects: 1. The number plan administrator has to create a credential issuing = mechanism mirroring its number delegation processes. That admin may not = have any knowledge of how to do that, and we need it done well to avoid = DigiNotar problems 2. The service providers have to create processes to handle the = credentials issued by the number plan administrator and issue = credentials to its customers 3. Some Tier 2/3 service providers in places where number resell is = permitted have to develop processes with their number suppliers to = handle credentials 4. We want to avoid having to chase a chain of credentials (each with = OSCP or equivalent checks) at verification time. This has some = implications on how the above mechanisms work. Brian On Jul 16, 2013, at 9:11 AM, Michael Hammer = wrote: > Philippe, >=20 > If the solution is kept simple, the education part should not require = much > effort. >=20 > I don't see why the numbering plan would have any effect on how = trivial it > might be, since asking the question what is your E.164 number should = be easy > to answer. > Yes, it is possible to make administrative aspects complicated, but = if that > is painful, don't go there. Could you elaborate more on that? >=20 > For example, if ultimately what is needed is a cert that binds a = private key > with an E.164 number, it could be made more complicated by also = including > the chain of service providers through which the key is delegated, but = that > conflation of delegation complexity with the act of knowing a private = key > matches with an E.164 number may be an act of shooting oneself in the = foot. >=20 > I still like Occam's Razor and think that would be very useful here. >=20 > Thanks, > Mike >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of > philippe.fouquart@orange.com > Sent: Tuesday, July 16, 2013 8:55 AM > To: Hadriel Kaplan; Brian Rosen > Cc: IETF STIR Mail List; Henning Schulzrinne > Subject: [stir] Rollout timeframe (was: RE: Draft STIR Charter) >=20 > I'll use Hadriel's aside note (or was it?) as an opportunity to point = out > that in addition to the timeframe related to the introduction of the = stir > technology itself in the network elements, endpoints etc (which I = don't > disagree with), the 'administrative' part of that effort must also be > considered/added: apologies if I'm stating the obvious or completely = missed > the purpose of all this, but it seems to me that it all relies on > credentials being issued directly or indirectly by the "numbering plan > authority/administrator". >=20 > This 'administrative' part could indeed be done in parallel and I = appreciate > that this effort may be more focused on some numbering plans than = others, > which may speed up the work for those, but > a) it is to me quite as much on the critical path as the pure = implementation > part, which would be pointless without it, > b) contrary to technology deployment, incremental/gradual introduction = of > such a framework under a given CC doesn't really make sense, it's = pretty > much on/off and > c) it will be far from trivial for a lot of numbering plans and may = take > considerable effort and education.=20 >=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 > Hadriel Kaplan > Sent: Tuesday, July 16, 2013 2:08 AM > To: Brian Rosen > Cc: IETF STIR Mail List; Henning Schulzrinne > Subject: Re: [stir] Draft STIR Charter >=20 >=20 > [snip] >=20 > And it's not a "couple years". It will take us longer than that just = to get > an out-of-band solution published as an RFC, let alone the timeframe = needed > for it to be deployed and a Tier-2 CLEC or its customers to use it. >=20 > Let's say it takes 2 years to get an out-of-band into an RFC. After = that > more time for the vendors implement it, getting tested in carriers, = etc. > Even 3 years altogether would be a minor miracle. Meanwhile, how long = do > you think before a significant majority of the carriers in North = America > interconnect using SIP? 5 years? Let's say it's 7 years. The time > difference between the 3 years to get out-of-band and 7 years for = in-band > would be 4 years. We'd do all that work, carriers would spend all = that time > and money, all for a 4-year lifespan for 15% caller-id coverage?!? = How does > that make any sense? >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > = __________________________________________________________________________= __ > _____________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message = par > erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les > pieces jointes. Les messages electroniques etant susceptibles = d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou > falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged > information that may be protected by law; they should not be = distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been > modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From richard@shockey.us Tue Jul 16 06:36: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 717C721E809A for ; Tue, 16 Jul 2013 06:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.893 X-Spam-Level: X-Spam-Status: No, score=-101.893 tagged_above=-999 required=5 tests=[AWL=0.372, 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 sAw4xOhrXaWw for ; Tue, 16 Jul 2013 06:36:20 -0700 (PDT) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 9101A11E80FC for ; Tue, 16 Jul 2013 06:36:20 -0700 (PDT) Received: (qmail 31685 invoked by uid 0); 16 Jul 2013 13:35:56 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy13.unifiedlayer.com with SMTP; 16 Jul 2013 13:35: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:Cc:To:From; bh=1l9Ntg+6wsi+YmU7szh5e28joWkIThqEOe5G3A9gEw0=; b=Zwbfu5f6kf+frkJfX+UmTpArkl+u7Q/v+2bag+swoL968VaPzfguBAVgExqtxa9/vPNC6lehtj27fvBzpMWRI8vsIhz1AOwr4uZfYzSvUTsM3PK75QlAen5oLnlsTzyc; Received: from [72.66.111.124] (port=49393 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Uz5Q2-0003JR-IQ; Tue, 16 Jul 2013 07:35:54 -0600 From: "Richard Shockey" To: , "'Hadriel Kaplan'" , "'Brian Rosen'" References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Tue, 16 Jul 2013 09:35:51 -0400 Message-ID: <009f01ce8229$6509e3a0$2f1daae0$@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: AQL/BCbN34pvssG/zmP8Y9dsYJE+5AHGECHJAXjKTQcCVaaUMAHzMIkXAW9TyhQCEOZjQADGdqIolqfSDqA= 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: 'IETF STIR Mail List' , 'Henning Schulzrinne' Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 13:36:25 -0000 Well remember you are perilously close to the precipice of dealing with National Regulatory Authorities on Numbering. It is a history that some of us have ugly memories of. I of course, mean ENUM and e164.arpa. This has not reached the radar screen beyond the North American context..yet. That said the problem clearly has reached some level of pain where legislative/regulatory action may be required. I would certainly like to see some study done by someone on the scope of the problem in other jurisdictions. The data here is very thin. The good news is, current religious arguments aside, we may have a general view of how the problem can be addressed. If we could understand the structure of the SIP headers in some revision of 4474 and some mechanism such as CIDER/DNS. Deploying a trial would not be unreasonable as proof of concept. Trials BTW are very popular at the FCC these days. :-) I have very little confidence that this can be flash cut into the existing network. Proposing a technical solution will not make sense if regulatory framework does not exist to support it and that really takes some time. The key is enforcement. Can/should service providers be required to implement a STIR solution or do they believe it is in their economic best interests to comply if for no other reason than the reduction in consumer complaints. FYI part of the reason US carriers deployed an ENUM/MMS solutions was to reduce consumer complaints on lack of interoperability. I actually believe INSIPID is equally important to the overall task since it is the track and trace elements of this that can ultimately enable some enforcement. I wish there was some more discussion on how the mechanisms would work at the edge SIP/SS7 network gateways since that clearly has been the center of most of the reported problems. I still think something needs to be done to police that traffic but that is still ultimately a regulatory effort. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of philippe.fouquart@orange.com Sent: Tuesday, July 16, 2013 8:55 AM To: Hadriel Kaplan; Brian Rosen Cc: IETF STIR Mail List; Henning Schulzrinne Subject: [stir] Rollout timeframe (was: RE: Draft STIR Charter) I'll use Hadriel's aside note (or was it?) as an opportunity to point out that in addition to the timeframe related to the introduction of the stir technology itself in the network elements, endpoints etc (which I don't disagree with), the 'administrative' part of that effort must also be considered/added: apologies if I'm stating the obvious or completely missed the purpose of all this, but it seems to me that it all relies on credentials being issued directly or indirectly by the "numbering plan authority/administrator". This 'administrative' part could indeed be done in parallel and I appreciate that this effort may be more focused on some numbering plans than others, which may speed up the work for those, but a) it is to me quite as much on the critical path as the pure implementation part, which would be pointless without it, b) contrary to technology deployment, incremental/gradual introduction of such a framework under a given CC doesn't really make sense, it's pretty much on/off and c) it will be far from trivial for a lot of numbering plans and may take considerable effort and education. 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: Tuesday, July 16, 2013 2:08 AM To: Brian Rosen Cc: IETF STIR Mail List; Henning Schulzrinne Subject: Re: [stir] Draft STIR Charter [snip] And it's not a "couple years". It will take us longer than that just to get an out-of-band solution published as an RFC, let alone the timeframe needed for it to be deployed and a Tier-2 CLEC or its customers to use it. Let's say it takes 2 years to get an out-of-band into an RFC. After that more time for the vendors implement it, getting tested in carriers, etc. Even 3 years altogether would be a minor miracle. Meanwhile, how long do you think before a significant majority of the carriers in North America interconnect using SIP? 5 years? Let's say it's 7 years. The time difference between the 3 years to get out-of-band and 7 years for in-band would be 4 years. We'd do all that work, carriers would spend all that time and money, all for a 4-year lifespan for 15% caller-id coverage?!? How does that make any sense? -hadriel _______________________________________________ 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 From hadriel.kaplan@oracle.com Tue Jul 16 07: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 2282721E8086 for ; Tue, 16 Jul 2013 07:06:20 -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 Fhvhf5rbw8KQ for ; Tue, 16 Jul 2013 07:06:14 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 719B021F9C88 for ; Tue, 16 Jul 2013 07:06:14 -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 r6GE6Bff031103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Jul 2013 14:06:12 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 r6GE68VZ001208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 14:06:09 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 r6GE68Gd018039; Tue, 16 Jul 2013 14:06:08 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 16 Jul 2013 07:06:08 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <80F50A9C-852B-45C8-9637-83DB1A718888@brianrosen.net> Date: Tue, 16 Jul 2013 10:06:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <80F50A9C-852B-45C8-9637-83DB1A718888@brianrosen.net> To: Brian Rosen , "philippe.fouquart@orange.com" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: IETF STIR Mail List , Dan York Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 14:06:20 -0000 +1. I think Philippe's point is more critical to ultimate success than the = rest of the stuff we've been arguing about. But we don't need the official number authorities to be involved to = start this thing and get it useful. We can start "trials" by just using = a commonly-agreed-upon anchor or two in a given country. Even if the = trials grow to include multiple countries with different anchors for = each country, it will still be manageable. In fact, all ~160 = country-codes could each define their own anchor and it would still be = manageable. Even for the +1 country-code, which is probably the most = complicated in terms of numbering plan, authorities, and number of = carriers - even for that we'd only really need a handful of the bigger = carriers in a country-code to do it, and the rest would join up soon = enough. Ultimately, in some future time, we would likely want/need the numbering = authorities to be involved. But as Brian said, it's not something the = IETF does particularly well. We're an engineering organization mostly. = And as far as I can tell, much of our regulatory contact seems to be = North American. (though I could easily be wrong about that) For = European regulators I would expect 3GPP and ETSI might help us out some = on this issue. For Asia, South America, Middle East, and Africa, we = could wait for this to percolate, or 3GPP might be able to help with = them too. I assume that the IETF does have formal or informal liaisons with at = least the RIRs, and they might be able to make contact with the = telephone numbering authorities in various countries. Also, I've been = told ISOC tries to help with IETF-related education/evangelism around = the world too, but I'm not sure about dealing with regulators. (Dan: do = you know?) -hadriel On Jul 16, 2013, at 9:16 AM, Brian Rosen wrote: > This is an important point, and it's not something the IETF does = particularly well, especially the "take considerable effort and = education" part. =20 > The IETF has been paying more attention to relationships with = governments and regulators lately, and I hope we will be able to = leverage that effort. >=20 > Brian >=20 > On Jul 16, 2013, at 8:54 AM, philippe.fouquart@orange.com wrote: >=20 >> I'll use Hadriel's aside note (or was it?) as an opportunity to point = out that in addition to the timeframe related to the introduction of the = stir technology itself in the network elements, endpoints etc (which I = don't disagree with), the 'administrative' part of that effort must also = be considered/added: apologies if I'm stating the obvious or completely = missed the purpose of all this, but it seems to me that it all relies on = credentials being issued directly or indirectly by the "numbering plan = authority/administrator". >>=20 >> This 'administrative' part could indeed be done in parallel and I = appreciate that this effort may be more focused on some numbering plans = than others, which may speed up the work for those, but=20 >> a) it is to me quite as much on the critical path as the pure = implementation part, which would be pointless without it,=20 >> b) contrary to technology deployment, incremental/gradual = introduction of such a framework under a given CC doesn't really make = sense, it's pretty much on/off and=20 >> c) it will be far from trivial for a lot of numbering plans and may = take considerable effort and education.=20 >>=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 Hadriel Kaplan >> Sent: Tuesday, July 16, 2013 2:08 AM >> To: Brian Rosen >> Cc: IETF STIR Mail List; Henning Schulzrinne >> Subject: Re: [stir] Draft STIR Charter >>=20 >>=20 >> [snip] >>=20 >> And it's not a "couple years". It will take us longer than that just = to get an out-of-band solution published as an RFC, let alone the = timeframe needed for it to be deployed and a Tier-2 CLEC or its = customers to use it. >>=20 >> Let's say it takes 2 years to get an out-of-band into an RFC. After = that more time for the vendors implement it, getting tested in carriers, = etc. Even 3 years altogether would be a minor miracle. Meanwhile, how = long do you think before a significant majority of the carriers in North = America interconnect using SIP? 5 years? Let's say it's 7 years. The = time difference between the 3 years to get out-of-band and 7 years for = in-band would be 4 years. We'd do all that work, carriers would spend = all that time and money, all for a 4-year lifespan for 15% caller-id = coverage?!? How does that make any sense? >>=20 >> -hadriel >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or = privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 From philippe.fouquart@orange.com Tue Jul 16 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 5DF3521F9B07 for ; Tue, 16 Jul 2013 07:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.118, 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 X4c4Tq4pEdBS for ; Tue, 16 Jul 2013 07:12:19 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 99C2421F84A8 for ; Tue, 16 Jul 2013 07:12:18 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 65DB43B41FE; Tue, 16 Jul 2013 16:12:17 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 35C2227C057; Tue, 16 Jul 2013 16:12:17 +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, 16 Jul 2013 16:12:16 +0200 From: To: Michael Hammer , "hadriel.kaplan@oracle.com" , "br@brianrosen.net" Thread-Topic: [stir] Rollout timeframe (was: RE: Draft STIR Charter) Thread-Index: AQHOgiOujxsZp4KoeEiI6Qk9o3LNdplnJioAgAAjV1A= Date: Tue, 16 Jul 2013 14:12:16 +0000 Message-ID: References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_000F_01CE823E.D93D2790" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.1.45418 Cc: "stir@ietf.org" , "Henning.Schulzrinne@fcc.gov" Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 14:12:23 -0000 ------=_NextPart_000_000F_01CE823E.D93D2790 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Mike, I wasn't referring to the _structure_ of the numbering plan, sorry. I agree it's pretty much orthogonal to the difficulty of that part of the task. Along the same line as Brian's post, I was referring to the time that would be necessary for putting in place procedures and an operational framework whereby when a decision is made by and under the control of the administrator of assigning a range/number/... to... anyone say, the corresponding credentials are issued; when ranges are reclaimed, credentials are revoked; when assignment rulings are renewed by that administrator, they're consistently renewed; what it all means when number ranges are transferred between assignees, when they're suballocated to third parties if it's permitted by the national policies, prohibited if it's not; what it means when numbers are ported if portability applies etc.... Yes, maybe I'm overcomplicating things or being too pragmatic, I'm just trying to see how that fits in the real life of a national numbering plan in fact (given that there are national variations and that the generally people in charge wouldn't contemplate applying for a security area AD position, no more than I would, considering...) and how that translates into an infrastructure upon which the mechanisms this group develops can rely. Not that I think the group could have some leverage on this administrative part (and I agree with Richard that that part is indeed leaning towards regulatory issues) other than making sure the documents that are developed here are accessible to the layman, I was merely observing that it could take... "quite some time". Regards, Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Tuesday, July 16, 2013 3:12 PM To: FOUQUART Philippe OLNC/OLN; hadriel.kaplan@oracle.com; br@brianrosen.net Cc: stir@ietf.org; Henning.Schulzrinne@fcc.gov Subject: RE: [stir] Rollout timeframe (was: RE: Draft STIR Charter) Philippe, If the solution is kept simple, the education part should not require much effort. I don't see why the numbering plan would have any effect on how trivial it might be, since asking the question what is your E.164 number should be easy to answer. Yes, it is possible to make administrative aspects complicated, but if that is painful, don't go there. Could you elaborate more on that? For example, if ultimately what is needed is a cert that binds a private key with an E.164 number, it could be made more complicated by also including the chain of service providers through which the key is delegated, but that conflation of delegation complexity with the act of knowing a private key matches with an E.164 number may be an act of shooting oneself in the foot. I still like Occam's Razor and think that would be very useful here. Thanks, Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of philippe.fouquart@orange.com Sent: Tuesday, July 16, 2013 8:55 AM To: Hadriel Kaplan; Brian Rosen Cc: IETF STIR Mail List; Henning Schulzrinne Subject: [stir] Rollout timeframe (was: RE: Draft STIR Charter) I'll use Hadriel's aside note (or was it?) as an opportunity to point out that in addition to the timeframe related to the introduction of the stir technology itself in the network elements, endpoints etc (which I don't disagree with), the 'administrative' part of that effort must also be considered/added: apologies if I'm stating the obvious or completely missed the purpose of all this, but it seems to me that it all relies on credentials being issued directly or indirectly by the "numbering plan authority/administrator". This 'administrative' part could indeed be done in parallel and I appreciate that this effort may be more focused on some numbering plans than others, which may speed up the work for those, but a) it is to me quite as much on the critical path as the pure implementation part, which would be pointless without it, b) contrary to technology deployment, incremental/gradual introduction of such a framework under a given CC doesn't really make sense, it's pretty much on/off and c) it will be far from trivial for a lot of numbering plans and may take considerable effort and education. 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: Tuesday, July 16, 2013 2:08 AM To: Brian Rosen Cc: IETF STIR Mail List; Henning Schulzrinne Subject: Re: [stir] Draft STIR Charter [snip] And it's not a "couple years". It will take us longer than that just to get an out-of-band solution published as an RFC, let alone the timeframe needed for it to be deployed and a Tier-2 CLEC or its customers to use it. Let's say it takes 2 years to get an out-of-band into an RFC. After that more time for the vendors implement it, getting tested in carriers, etc. Even 3 years altogether would be a minor miracle. Meanwhile, how long do you think before a significant majority of the carriers in North America interconnect using SIP? 5 years? Let's say it's 7 years. The time difference between the 3 years to get out-of-band and 7 years for in-band would be 4 years. We'd do all that work, carriers would spend all that time and money, all for a 4-year lifespan for 15% caller-id coverage?!? How does that make any sense? -hadriel _______________________________________________ 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_000F_01CE823E.D93D2790 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIZEjCCBggw ggPwoAMCAQICAwC2aDANBgkqhkiG9w0BAQUFADBMMRwwGgYDVQQDExNPcmFuZ2UgTGFicyBVc2Vy IENBMQ4wDAYDVQQLEwVBc3BpYzEPMA0GA1UEChMGT3JhbmdlMQswCQYDVQQGEwJGUjAeFw0xMjA3 MDQxMzI0MDBaFw0xNzA3MDMxMzI0MDBaMIGRMQswCQYDVQQGEwJGUjEPMA0GA1UEChMGT3Jhbmdl MQ4wDAYDVQQLEwVBU1BJQzEaMBgGA1UEAxMRUGhpbGlwcGUgRk9VUVVBUlQxGDAWBgoJkiaJk/Is ZAEBEwhQT0VGNzI3NjErMCkGCSqGSIb3DQEJARYccGhpbGlwcGUuZm91cXVhcnRAb3JhbmdlLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIFSiICROl6Hvr4dMb1OP+B49gLMYpR/ gNVzJk83HORYgraCw8Za8LUg/aM0f3zNWuGBW5nsEueCYJb4jZmE3YWCm95FNI+V2by0PUM+WNph U7y2U8DiyV6HDJ5F75yDuZ6ep+mrFAwI4LvE/oCrKQVMJtVyrpFOpqcX/nkDLSO/17pTM15N9Q37 UdaMgUWSos2VAELaFUqQpmOyH02iqz6XrjYNnl4yLKb5Vu3QZJx/jtLCByNi/6gR7xYyJ7xZ46bu r4Tx9BjkgvBFOZXaQCTVcdzCNEOG9BhBmtaSC1l1TBklFsFXZkFXHzP4e+PzyJDz9N2Q6P83Bkfp 33jXJ2cCAwEAAaOCAaswggGnMA8GA1UdDwEB/wQFAwMHMAAwEwYDVR0lBAwwCgYIKwYBBQUHAwQw HQYDVR0OBBYEFPNR00lqFB2M3rKi/TIoSKAxQew5MFUGA1UdIwROMEyAFGOOJTfswgeGFNSOgaMf YRkBfyswoS+BLUNOPU9yYW5nZSBMYWJzIFVzZXIgQ0EsT1U9QXNwaWMsTz1PcmFuZ2UsQz1GUoID AJUxMIGmBgNVHR8EgZ4wgZswMqAwoC6GLGh0dHA6Ly9wLXBraS5yZC5mcmFuY2V0ZWxlY29tLmZy L3VzZXJjcmwuY3JsMDKgMKAuhixodHRwOi8vbC1wa2kucmQuZnJhbmNldGVsZWNvbS5mci91c2Vy Y3JsLmNybDAxoC+gLYYraHR0cDovL3BraS5yZC5mcmFuY2V0ZWxlY29tLmNvbS91c2VyY3JsLmNy bDARBglghkgBhvhCAQEEBAMCBSAwTQYDVR0RBEYwRIEccGhpbGlwcGUuZm91cXVhcnRAb3Jhbmdl LmNvbYEkcGhpbGlwcGUuZm91cXVhcnRAb3JhbmdlLWZ0Z3JvdXAuY29tMA0GCSqGSIb3DQEBBQUA A4ICAQBtevXaKlI6xQpSf+bdLPLE+TMvcP0VF595xB8LIediXgEy/F9kyHYEGljJcPXF2ym4U0Uu zo7pthID0Ov75JL6p4vUcMWqxIuFyFSJ5WJaezt+LXRXl3Pvkgi4p3tkYJqDVXt2DwD0Yb13CXuR KVHRtqLfDHpwP7RQ4lDkowv+fW9MKPXbYacdqglPv0WoTe9AweyGrbSaSYuX+TFI6+RlaOP8kbA7 zDqjWjGTZqMh0nG7znE4V0JqbHq4G+6Ds+jpkJVdlKnzfQJhgVAiX1D2xGVR3wK+kfwE8ygA47f1 kqg1Q+EIU1U+lml3KAeVgS8tjSWE7hjRYjVavESDGtOHPH8XjF7cQ1/l+T04xQkSMk22bxRBJ9pV yClfMgoUW1/Iz45D5xII1M0h4Wy6AIgvmce4tDMPfmjNPHV5rGdygFGwVxCaa50NQ079lFF3F+Yi SF3oA3E6jNfkt8Zv2zhEoAH6M6lhWteDFltCSPIDo/OdD1BTwvKkOvIk01gvw8qO49eIIeXT2uCj nm0lHDq+JzgQW6Rp6kHIa0mOrqa7xyrqLJSRDKgXED7LzBgwxLY/BK4mbSWfIYw+aZat94mWtTYH wPiDFmPB6+XRgjO4um1g94YBb6TLvt5clcrQ9hrd51EYuSAZqLLqsa8kuH/cvhYcXQCSheV9Gxhz 1wy4YDCCBjwwggQkoAMCAQICAwCVMDANBgkqhkiG9w0BAQUFADBMMQswCQYDVQQGEwJGUjEcMBoG A1UEAxMTT3JhbmdlIExhYnMgUm9vdCBDQTEPMA0GA1UEChMGT3JhbmdlMQ4wDAYDVQQLEwVBc3Bp YzAeFw0xMTA3MDgxMzE2MjFaFw0yNjA3MDQxMzE2MjFaMEwxCzAJBgNVBAYTAkZSMRwwGgYDVQQD ExNPcmFuZ2UgTGFicyBSb290IENBMQ8wDQYDVQQKEwZPcmFuZ2UxDjAMBgNVBAsTBUFzcGljMIIC IjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAxDxdlZmLRPMYS8Ii414DHVq39nfO5CSRO9cg Vlu+nuXLGv1/KByqfxTFpXLOYILhTNmlUuJ4CVzRTp7/D+GpNxCZ4tclUS7DjE0CKvphvsxxQdx6 8pYP1EUV4wUDF09Te+VMQlHGBTrWxV2q3E6F3Ksj1yXhYsR5QmPThNi5kYDH1qi5amAU1bgWoHh+ 7y/fHpzAGOTI5Om/nIg0+agWJONnDfKNWnaT4v5Pyv1ytj1aWCz0VYv1M/DpPH/Sl8rcI3AZ+zZR OrcnNO09BWPsyU+gOeqtZe6nAt6h2mj8vimrnwNkJBUMlMc96do+PJy6WctJaWxwg+Tu2BtTBJa7 k89syJVPXdFb9yH1tnyqYDCjG3zKzCKyfnpOIA/gZrjzRNJDxJRScfEpyX4BenF6zuCgVONofKwz MtL2oyNjXhUD/ivUbKe+NMOfTkCrvCMkogxbM2mzOKHTbntG3cYsprzhMF+aNKu7HPBPuXbmZdC/ AV9Wj/UpehN35K/rLalsEcnrsclbVJ0S+I1ZsCqjJoIQVgUxiLcQs5Hv0LxyDxkDtlaR21jxJtkh XnZm+4YOsjPz7AXseLgKLT0o0HkPQiSV9Da5EIWyislYDmKYdgpSajAh3M2Mo64arjyBiuiz1V64 YwIcw+aLzeN3QcopBoFtqr3pkkY6jbtBtBmiInsCAwEAAaOCASUwggEhMBIGA1UdEwEB/wQIMAYB Af8CAQEwDwYDVR0PAQH/BAUDAwcGADAdBgNVHQ4EFgQUVlvqwX4luyGOma/ubx1FjCuYQ7swHwYD VR0jBBgwFoAUVlvqwX4luyGOma/ubx1FjCuYQ7swgaYGA1UdHwSBnjCBmzAyoDCgLoYsaHR0cDov L3AtcGtpLnJkLmZyYW5jZXRlbGVjb20uZnIvcm9vdGNybC5jcmwwMqAwoC6GLGh0dHA6Ly9sLXBr aS5yZC5mcmFuY2V0ZWxlY29tLmZyL3Jvb3RjcmwuY3JsMDGgL6AthitodHRwOi8vcGtpLnJkLmZy YW5jZXRlbGVjb20uY29tL3Jvb3RjcmwuY3JsMBEGCWCGSAGG+EIBAQQEAwIBFjANBgkqhkiG9w0B AQUFAAOCAgEAMnuCSthwtwJsiI5oXsGsCp1qQDFNWprQKFNE2GwkMIi/bxxEx+4mzkbG6+3rnyLg oUPW1QTpTEVOk4DUL9oOxEkolka5LSmSVKXLZTvfJLy03AJno3waGkCAkhYFnBjVToWSoivQM45E +BNg+cWBOvpICq377zpinWvsUEBvelyjLAFxZa1m+Nth3cUTUdyjO4CpOM/osjTBQ5YjxQ7g7d4g fo/+rJyWS8kC1qGbRIX4khd45Fh8ysZTldK6ScHm76rGZNxMbeHDY5EvZ87Xrn95j4AU9pPO4uhd xp18066gutf1O9eYi/SvtB4C7mTYD/AmIDnPzcyNSOGxxyISnUSkqaGAj74bhdx3f5ceIJ1FsO0M onNTge+QACEZkftvjAhY0bH7ro3stzKD9Kts+cbIfADDqzmtlAmIGhvUN9mhEgBezWdIiIi2RtG0 R9MtLDk33dOSj3XaOW6w5bYxB05uQXwssAYwvJ0Fu3pCUVwNMswutwA46jQLduXH269WfN5e/iNT f8KBgU0CCH6Xhvqs78bCRJ7JRzbA3sSPNTQHz+au99I2E193EnByws44VvLiIXkOyLKoin1eb0uX g/hL5bEUONIgw8D48fIKXHLYFSrTHIC27KQpf5Td5OxfPdSmT1jSPSsgGRblHzpQpI58U2zxxdCQ +1/yq6kDCeUwggZMMIIENKADAgECAgMAtmcwDQYJKoZIhvcNAQEFBQAwTDEcMBoGA1UEAxMTT3Jh bmdlIExhYnMgVXNlciBDQTEOMAwGA1UECxMFQXNwaWMxDzANBgNVBAoTBk9yYW5nZTELMAkGA1UE BhMCRlIwHhcNMTIwNzA0MTMyNDAwWhcNMTcwNzAzMTMyNDAwWjCBkTELMAkGA1UEBhMCRlIxDzAN BgNVBAoTBk9yYW5nZTEOMAwGA1UECxMFQVNQSUMxGjAYBgNVBAMTEVBoaWxpcHBlIEZPVVFVQVJU MRgwFgYKCZImiZPyLGQBARMIUE9FRjcyNzYxKzApBgkqhkiG9w0BCQEWHHBoaWxpcHBlLmZvdXF1 YXJ0QG9yYW5nZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCgRFseJ7uM8gOg ObVkzreZ+G9NZS/uTGUHcClc8xfXETbTnDFFvPFmSUY3S5DKfe7LUeAflZ+5vtqO55ThRbL7wNMr ZFAMVuiA7n0TDGA5/h4bijxXWYU2PMCuxICPO6MagPcnJ2mlKP3gAFJV2UkqBQ8qmrq0ERFkXdwM Ie5qY1ybcpGoLufbAcXXvhOjyjbVD8/qUtedtbJcfkuD/sS3oaWknQ8jGuu7t8iSgeL98lvSxNiY OaTzwUUU4sjREtceBw4YRJZa0+smhxvllNxRMOBBJ+PSk3I1eqZJT0kh4QmdFQZydybCFAMg2ulm 9AC95hgzb5R3aXpaTU3x+83fAgMBAAGjggHvMIIB6zAPBgNVHQ8BAf8EBQMDB8AAMCkGA1UdJQQi MCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUHc2Bl2dtNqLS+2Q4 sZ8GppXBBwowVQYDVR0jBE4wTIAUY44lN+zCB4YU1I6Box9hGQF/KzChL4EtQ049T3JhbmdlIExh YnMgVXNlciBDQSxPVT1Bc3BpYyxPPU9yYW5nZSxDPUZSggMAlTEwgaYGA1UdHwSBnjCBmzAyoDCg LoYsaHR0cDovL3AtcGtpLnJkLmZyYW5jZXRlbGVjb20uZnIvdXNlcmNybC5jcmwwMqAwoC6GLGh0 dHA6Ly9sLXBraS5yZC5mcmFuY2V0ZWxlY29tLmZyL3VzZXJjcmwuY3JsMDGgL6AthitodHRwOi8v cGtpLnJkLmZyYW5jZXRlbGVjb20uY29tL3VzZXJjcmwuY3JsMBEGCWCGSAGG+EIBAQQEAwIFoDB7 BgNVHREEdDByoCwGCisGAQQBgjcUAgOgHgwccG9lZjcyNzZAcmQuZnJhbmNldGVsZWNvbS5mcoEc cGhpbGlwcGUuZm91cXVhcnRAb3JhbmdlLmNvbYEkcGhpbGlwcGUuZm91cXVhcnRAb3JhbmdlLWZ0 Z3JvdXAuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQBzEhcPXwTuNTbKDor4PtKxB/0PQ1jAWmOhRsNx g93/h8KtblWN42xW4A2elGGHbueDg6e47nAxsXRY1IQQ0jJ9pBv1Hey/k5iEVUcSnv27DR6dFW0H kxYX/0W6wAbx4cEPLPViMwDPo2UbYnKt+z/JKilvydSSUe7XBFYre4xBL7pJSKfxM6XZS4u5HQxU ZaIjgBfpleOO3UVHXSepxw9xIS3yh2zbGrtXp725hVmx9jZ5h6FOJu3EAeYmIUJMzkZgOhlW46lZ s7020LiGPlCtCVyyckOLxWzoe8k/MkzDWm1X5Ph/Vf+oQVleq+29/7vXfZPGXHeSiBmBhbAcHrf8 nwHny33aRTyHpQQ+npY5Na0uPndlg5/s2T6DzXrANXAh+q5FCHppVpWDR22r5a2S2e3Ivlbzo2JZ wkkvIBKj1ESlB+hinaDzeIuC/UICgRRjVh3JwbbpS7fs1mN9Bvgxdr6a3CnXcApafcHKv+/DFLQE ywW95lsVmD3q3x2rRTNablMoTfu63Tr87L67IDd5QXKhAP9RhKdzZUGheDn81lvMoK6KhWp42o1V hUi3UzHTmV2rdM9F982IHQLgTSt/JHb+CknvtF5i0RxPFOf9HW1S+eyxVqwWllH93iJP7yT3wmLK mahoFq96fUc5wbogjBW1KkDgL/t7RhbsLi7E2DCCBnIwggRaoAMCAQICAwCVMTANBgkqhkiG9w0B AQUFADBMMQswCQYDVQQGEwJGUjEcMBoGA1UEAxMTT3JhbmdlIExhYnMgUm9vdCBDQTEPMA0GA1UE ChMGT3JhbmdlMQ4wDAYDVQQLEwVBc3BpYzAeFw0xMTA3MDgxMzMwMDBaFw0yNjA2MjkxMzMwMDBa MEwxHDAaBgNVBAMTE09yYW5nZSBMYWJzIFVzZXIgQ0ExDjAMBgNVBAsTBUFzcGljMQ8wDQYDVQQK EwZPcmFuZ2UxCzAJBgNVBAYTAkZSMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAjPMm HtccQ+z0QWkL1O2HgtJfqklqw0vvUAF8zkku6Aw6aDzRq7uI9OFuZEIeAgHGIVpH0yOkKAoExazi /q6B8brLuAs0oNiZq6gtPm5C+UnV1/sEuJSWC4MuiActRAMXpOEXuI3VnTDz+s8d6N/Bn45cevbS vM6+ygLH0o2Nn2zVEHyN4zvRdriQv1VDUfqAo7uVjxtbzTvr4NLAIJXUeHdAvop/Lqa1Bd4hUWyB zse8HUTV6zD84baxO7nJb7pBBeFUyhkNRmGyMg/wZJ7LeD2BLSIZ9zY/2T7yMhc0eU+kXDePOxdN 6m83P4W8TXBLFQPM7ZNz7K1YWD/XciF6ZRTExDoUsZ73GYajPVjPgoaVQQcc7HkzfTE+YTLagIjL 4BRbgq/nBUwexPoYEChQ132QFfIBkHjJz3yVzXFGawPGeG+wYGkE+JTsrg1BlXPm6iUCtdVCIovK T2YElcV3Cm5DCI//Ccx/G1+Zu0uCjPzXvzsSAarlhOlP/D9CohA0AIY2xkPNHWZqdeQJ5/DQxzH8 9D5jx9bsfPJONLQvzNSGQbjFYVyb3gf1pBL/BtzoXOJjXetUWt3Hu0nPcMF2r8KgTs7ZcuyPbUiF PmFiWmb16ry+Ls1+w8Q1IGLNZNb695VHEBFQA0icw8rA4zDmozPIK6E1Fi3xyZixByXIbxUCAwEA AaOCAVswggFXMBIGA1UdEwEB/wQIMAYBAf8CAQAwDwYDVR0PAQH/BAUDAwcGADAdBgNVHQ4EFgQU Y44lN+zCB4YU1I6Box9hGQF/KzAwVQYDVR0jBE4wTIAUVlvqwX4luyGOma/ubx1FjCuYQ7uhL4Et Qz1GUixDTj1PcmFuZ2UgTGFicyBSb290IENBLE89T3JhbmdlLE9VPUFzcGljggMAlTAwgaYGA1Ud HwSBnjCBmzAyoDCgLoYsaHR0cDovL3AtcGtpLnJkLmZyYW5jZXRlbGVjb20uZnIvcm9vdGNybC5j cmwwMqAwoC6GLGh0dHA6Ly9sLXBraS5yZC5mcmFuY2V0ZWxlY29tLmZyL3Jvb3RjcmwuY3JsMDGg L6AthitodHRwOi8vcGtpLnJkLmZyYW5jZXRlbGVjb20uY29tL3Jvb3RjcmwuY3JsMBEGCWCGSAGG +EIBAQQEAwIABzANBgkqhkiG9w0BAQUFAAOCAgEASDhiLXUUbhFNYUcKznQeXbsOF73KHfjvpt4G 16yWnq9lhRnBpCwFoe1VsBdyHNQhTNaaC15rdgCJWIj3sTmfGw1/gtBZ8UmT2czrpYTsY5HQ4GVy bq2Ra3N9tnjgOZFUQGtoezSjFbmjAI2MXMFYrHF+s2sKPyssEjuiuylTNyvFB4c0lOF9/zTwZcJ1 rPepcE9a0cFq70JhZYOVmIHMrPKaMnbaLkkuZWex2AKGkt8pXL2I95JMJ1qqB9kOCE+cwCnCJn/G 7CVnLYgZfqF+tptYUom1+QhYj/xZOmr2xBFM3CQDFMUuj15+MzdEHkUC/CplnMloC8EsYZlB5t6o FgTgAvsjdTAzMMGGqusjg5ImbA5Er7p/XxDVuEooWyi6ogaYQuUiRTOr+3xd+173Thb0C7eMRozi hFpcddGhhvD6m819Nuv1SIf22Qr5M4jVQrcBS7rixUuqb4E8wJfFaoCAItHcMK2/ZibXqGe/GXGz R8bZrY4/joXVdPr7vEn+EGQN15zbwS/PKazE2E86ghqFNaSLPA44jNbRH91RRTIszHEoPfc/tyJQ mgGav/7BN4fXrx0rNr+xyzx/eLOvGqCTzJq7m0M5lM3BqAAhhWrLrviNkMbzg6pWzVvw5ThKDZJV yU0COrW7SNpuyoKscNbclhI3TaLsgpYyH38FoSExggMOMIIDCgIBATBTMEwxHDAaBgNVBAMTE09y YW5nZSBMYWJzIFVzZXIgQ0ExDjAMBgNVBAsTBUFzcGljMQ8wDQYDVQQKEwZPcmFuZ2UxCzAJBgNV BAYTAkZSAgMAtmcwCQYFKw4DAhoFAKCCAZAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTMwNzE2MTQwOTI4WjAjBgkqhkiG9w0BCQQxFgQUV6eeklJmHK/9UldjpMvp mUW38H4wYgYJKwYBBAGCNxAEMVUwUzBMMRwwGgYDVQQDExNPcmFuZ2UgTGFicyBVc2VyIENBMQ4w DAYDVQQLEwVBc3BpYzEPMA0GA1UEChMGT3JhbmdlMQswCQYDVQQGEwJGUgIDALZoMGQGCyqGSIb3 DQEJEAILMVWgUzBMMRwwGgYDVQQDExNPcmFuZ2UgTGFicyBVc2VyIENBMQ4wDAYDVQQLEwVBc3Bp YzEPMA0GA1UEChMGT3JhbmdlMQswCQYDVQQGEwJGUgIDALZoMGcGCSqGSIb3DQEJDzFaMFgwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAIE5A4Ryesn6kzxH emQCnFgWPQFq5anVc8SWXbvHkBYHGNkMsddgJos6i6R1XVSlaiacJ/DricBExxcdEmbg9e/PSuHk rP0gaJ2HhC/WlO4cBixMVux8koaeTF9z/dbwTmOWfy6N+Z4UxTWX4kTJ8zE6lxhSL82ZXqiR3jDL qsSo6bD4vzsKz6aWBu4/jDgebJFKUu8rXZOL42AM78GVDLPuGsLIfZe8LG/DeKjvuJ5uSiRwzNZ6 W1pwhnaJgG3JBMhUtSySOPYkMC5ExfajovdlK6u6CW+K5xCJDTK3e3SYkbgTyNV73KaqPmpaOVLb +ufIRcI0Qda+RlwSnnDFe7oAAAAAAAA= ------=_NextPart_000_000F_01CE823E.D93D2790-- From hadriel.kaplan@oracle.com Tue Jul 16 07:21: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 8349C11E80F2 for ; Tue, 16 Jul 2013 07:21:36 -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 KpdYeGtKcU2U for ; Tue, 16 Jul 2013 07:21:29 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1B87E11E80C5 for ; Tue, 16 Jul 2013 07:21: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 r6GELGvD005486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Jul 2013 14:21:16 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 r6GELEwS025042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 14:21:15 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6GELEMb012847; Tue, 16 Jul 2013 14:21:14 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 16 Jul 2013 07:21: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: <009f01ce8229$6509e3a0$2f1daae0$@shockey.us> Date: Tue, 16 Jul 2013 10:21:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <27376377-8220-4AEC-97A2-A1D59DAA54DA@oracle.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <009f01ce8229$6509e3a0$2f1daae0$@shockey.us> To: "Richard Shockey" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: IETF STIR Mail List Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 14:21:36 -0000 On Jul 16, 2013, at 9:35 AM, "Richard Shockey" = wrote: > I actually believe INSIPID is equally important to the overall task = since it > is the track and trace elements of this that can ultimately enable = some > enforcement. I wish there was some more discussion on how the = mechanisms > would work at the edge SIP/SS7 network gateways since that clearly has = been > the center of most of the reported problems. I still think something = needs > to be done to police that traffic but that is still ultimately a = regulatory > effort. I agree we need a tracking/tracing mechanism, but in my opinion we = cannot and should not rely on INSIPID Session-ID at all for that. They = have gone beyond benign troubleshooting-type purposes now, which means = there is absolutely no guarantee the Session-ID will make it intact = across service providers in all cases. In fact, my hunch is it won't. Regardless, the Session-ID isn't what we really need for tracing a bad = caller-id call. Even without Session-ID, the service provider's CDRs or = logs can be used to trace it back to the peering connection and peer = upstream provider the call came in from. What we also need is a list of = SPIDs the call request has crossed through, so we can trace it back = further upstream. Kinda like a Via header, but with very different = properties and purpose. We've talked about doing that before, back when = there was talk about creating a registry of SPIDs. What ever happened = to having a registry of SPIDs? -hadriel From br@brianrosen.net Tue Jul 16 07:45: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 7159C11E80D7 for ; Tue, 16 Jul 2013 07:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.259 X-Spam-Level: X-Spam-Status: No, score=-100.259 tagged_above=-999 required=5 tests=[AWL=0.178, 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 7h7EPWNzSs4i for ; Tue, 16 Jul 2013 07:45:16 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id EF1D011E80D5 for ; Tue, 16 Jul 2013 07:45: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=ZozuyBipYXo2hb8GNe8Z0cIZg1SFaRZXgX0Tx/6a4AY=; b=cW1QqdiNSVjSOjkL7wVzv+3/dLHE5lZsk9ewov2KJKPtm39GpUKEzTvEDWxrIc/l0e0Z+5jiUQr3mgiWFU6r/pQZZk4qBulKe4NvXHeN5SE9/m/3Py59xSBQpXqyhV2l/hM3GV1fRfug2WZmMxGl+BvtwhsJDt3ynuqr3r7M4zY=; Received: from neustargw.va.neustar.com ([209.173.53.233]:46532 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1Uz6Uw-0005KU-Jh; Tue, 16 Jul 2013 10:45:02 -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: <27376377-8220-4AEC-97A2-A1D59DAA54DA@oracle.com> Date: Tue, 16 Jul 2013 10:45:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7A9C6940-5BC1-4A22-A4C8-85EF5495D4EC@brianrosen.net> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <009f01ce8229$6509e3a0$2f1daae0$@shockey.us> <27376377-8220-4AEC-97A2-A1D59DAA54DA@oracle.com> 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: IETF STIR Mail List , Richard Shockey Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 14:45:20 -0000 If INSIPID's session ID won't survive end to end, what do you suggest we = use here to avoid replay? Brian On Jul 16, 2013, at 10:21 AM, Hadriel Kaplan = wrote: >=20 > On Jul 16, 2013, at 9:35 AM, "Richard Shockey" = wrote: >=20 >> I actually believe INSIPID is equally important to the overall task = since it >> is the track and trace elements of this that can ultimately enable = some >> enforcement. I wish there was some more discussion on how the = mechanisms >> would work at the edge SIP/SS7 network gateways since that clearly = has been >> the center of most of the reported problems. I still think something = needs >> to be done to police that traffic but that is still ultimately a = regulatory >> effort. >=20 > I agree we need a tracking/tracing mechanism, but in my opinion we = cannot and should not rely on INSIPID Session-ID at all for that. They = have gone beyond benign troubleshooting-type purposes now, which means = there is absolutely no guarantee the Session-ID will make it intact = across service providers in all cases. In fact, my hunch is it won't. >=20 > Regardless, the Session-ID isn't what we really need for tracing a bad = caller-id call. Even without Session-ID, the service provider's CDRs or = logs can be used to trace it back to the peering connection and peer = upstream provider the call came in from. What we also need is a list of = SPIDs the call request has crossed through, so we can trace it back = further upstream. Kinda like a Via header, but with very different = properties and purpose. We've talked about doing that before, back when = there was talk about creating a registry of SPIDs. What ever happened = to having a registry of SPIDs? >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From br@brianrosen.net Tue Jul 16 07: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 8B7D021E808E for ; Tue, 16 Jul 2013 07:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.266 X-Spam-Level: X-Spam-Status: No, score=-100.266 tagged_above=-999 required=5 tests=[AWL=0.171, 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 hljBeV4lFSDE for ; Tue, 16 Jul 2013 07:48:54 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 0E34811E80D3 for ; Tue, 16 Jul 2013 07:48:54 -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=5Z6lpG8W6cQjJu8APy+Uw8BnX7FSVvnQadQ86bsQq/M=; b=YcCcd7cmshFQq1MEQ3dk9wGESIOial1gThaWPm/riwlfALn+OW5dbxbmmhzfdi4mSsBy1z511lUl9BpbqCjahpqdlF7kYSlP5Z3YzJ0wdbhMohXhr8a+2mqCQpvaiJCLfR24LGv55CYegG5kSLE7Ambq7jkPdjvhrHKBO6sPIog=; Received: from neustargw.va.neustar.com ([209.173.53.233]:58108 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1Uz6Yf-000648-5X; Tue, 16 Jul 2013 10:48:53 -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: <7A9C6940-5BC1-4A22-A4C8-85EF5495D4EC@brianrosen.net> Date: Tue, 16 Jul 2013 10:48:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5FAF3880-6C89-4DEC-AC19-3AB93CAB0CEE@brianrosen.net> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <009f01ce8229$6509e3a0$2f1daae0$@shockey.us> <27376377-8220-4AEC-97A2-A1D59DAA54DA@oracle.com> <7A9C6940-5BC1-4A22-A4C8-85EF5495D4EC@brianrosen.net> 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: IETF STIR Mail List , Richard Shockey Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 14:48:58 -0000 Agree The LoST notion of a Forest Guide may be useful here - the basic = applicable notion is that there is some entity trusted by most/all = providers in a country to refer queries not understood locally to the = right service. The forest guides cooperate with one another without a = golden root. They use administrative processes to determine who they = should trust, and develop their own, small database of places to refer = out of country requests to. This has a very good chance of working = here. Brian On Jul 16, 2013, at 10:45 AM, Brian Rosen wrote: > If INSIPID's session ID won't survive end to end, what do you suggest = we use here to avoid replay? >=20 > Brian >=20 > On Jul 16, 2013, at 10:21 AM, Hadriel Kaplan = wrote: >=20 >>=20 >> On Jul 16, 2013, at 9:35 AM, "Richard Shockey" = wrote: >>=20 >>> I actually believe INSIPID is equally important to the overall task = since it >>> is the track and trace elements of this that can ultimately enable = some >>> enforcement. I wish there was some more discussion on how the = mechanisms >>> would work at the edge SIP/SS7 network gateways since that clearly = has been >>> the center of most of the reported problems. I still think = something needs >>> to be done to police that traffic but that is still ultimately a = regulatory >>> effort. >>=20 >> I agree we need a tracking/tracing mechanism, but in my opinion we = cannot and should not rely on INSIPID Session-ID at all for that. They = have gone beyond benign troubleshooting-type purposes now, which means = there is absolutely no guarantee the Session-ID will make it intact = across service providers in all cases. In fact, my hunch is it won't. >>=20 >> Regardless, the Session-ID isn't what we really need for tracing a = bad caller-id call. Even without Session-ID, the service provider's = CDRs or logs can be used to trace it back to the peering connection and = peer upstream provider the call came in from. What we also need is a = list of SPIDs the call request has crossed through, so we can trace it = back further upstream. Kinda like a Via header, but with very different = properties and purpose. We've talked about doing that before, back when = there was talk about creating a registry of SPIDs. What ever happened = to having a registry of SPIDs? >>=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 dhc@dcrocker.net Tue Jul 16 07:58: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 7D8AD21F9B8C for ; Tue, 16 Jul 2013 07:58:13 -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 0QpEjSpZUAtB for ; Tue, 16 Jul 2013 07:58:08 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3B21321F9B2F for ; Tue, 16 Jul 2013 07:57:40 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r6GEvaJZ023596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 16 Jul 2013 07:57:39 -0700 Message-ID: <51E55F3E.8090205@dcrocker.net> Date: Tue, 16 Jul 2013 07:57:02 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: IETF STIR Mail List References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <009f01ce8229$6509e3a0$2f1daae0$@shockey.us> <27376377-8220-4AEC-97A2-A1D59DAA54DA@oracle.com> <7A9C6940-5BC1-4A22-A4C8-85EF5495D4EC@brianrosen.net> In-Reply-To: <7A9C6940-5BC1-4A22-A4C8-85EF5495D4EC@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, 16 Jul 2013 07:57:40 -0700 (PDT) Subject: Re: [stir] Rollout timeframe 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, 16 Jul 2013 14:58:13 -0000 > If INSIPID's session ID won't survive end to end, what do you suggest we use here to avoid replay? Folks, Question to the group: There are a number of different styles of replay attack, with different likelihoods and different effects (nature/degree of damage). What specific replay scenarios does the group deem it essential to prevent and why? I've seen situations in which it was deemed acceptable to allow some types of potential replay attacks, because the potential for its occurrence and/or damage it would do were not a serious concern. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From kent@bbn.com Tue Jul 16 08:01: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 933F911E80D3 for ; Tue, 16 Jul 2013 08:01:22 -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 XynBHnAogAyK for ; Tue, 16 Jul 2013 08:01:16 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id C05EC21F9BF3 for ; Tue, 16 Jul 2013 08:01:16 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:54898) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Uz6kd-000FDr-SV for stir@ietf.org; Tue, 16 Jul 2013 11:01:15 -0400 Message-ID: <51E5603C.6010904@bbn.com> Date: Tue, 16 Jul 2013 11:01:16 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: stir@ietf.org References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> <3145728A-87FA-4217-9B93-E14A01307784@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC16DAD@EX2K10MB1.corp.yaanatech.com> <21393_1373964969_51E50AA9_21393_2845_1_B5939C6860701C49AA39C5DA5189448B0B4651@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <21393_1373964969_51E50AA9_21393_2845_1_B5939C6860701C49AA39C5DA5189448B0B4651@PEXCVZYM12.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 15:01:22 -0000 Phillipe, > Charter-wise I would also prefer this phrasing than referring to authentication or "authenticate the originator of a SIP session". From a security terminology perspective, authentication is an appropriate term. For example, RFC 4949 (Internet Security Glossary, v2) defines the term as follows: authenticate (I) Verify (i.e., establish the truth of) an attribute value claimed by or for a system entity or system resource. So, in this context, verifying that the TN asserted by a caller is accurate is a reasonable use of the term. >> "is the caller entitled to use the telephone number in the callerID information" > Given the context, however, I'm with Dave's "meta point" on this. Using authentication would be confusing for me (mostly because of what the term conveys with regard to the network the sip user is registered with): > a) such authentication is generally carried out to provide a service to the subscriber with the TN, here the calling party, more rarely the called party; and > b) it implies that the primary piece of information with which you identify the user is indeed the TN, whereas as a rule, [not all but] a large number of networks (SIP-based and others) generally try and separate what you identify/authenticate users with and what other users employ (the TNs) to set up a session/call with them - ie precisely try and not use TNs for the purpose of identification/authentication. > Whether a TN or some other form of identifier may be authenticated in the proposed system has a lot to do with who is providing the assertion about the ID. If there is one thing we have learned from the browser trust anchor mess, it's that allowing a third party to make assertions about identities for which it is not authoritative, is a very, very bad idea. That's why. in the RPKI context, the certs are issued only by entities that are authoritative for the resources for which they vouch, and the names that appear in these certs are, intentionally, not human meaningful. Steve From richard@shockey.us Tue Jul 16 08: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 3F14521F9D02 for ; Tue, 16 Jul 2013 08:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.611 X-Spam-Level: X-Spam-Status: No, score=-101.611 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=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 jqYnZQzM519n for ; Tue, 16 Jul 2013 08:03:21 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 4D79221F9C38 for ; Tue, 16 Jul 2013 08:03:21 -0700 (PDT) Received: (qmail 1719 invoked by uid 0); 16 Jul 2013 15:02:58 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.bluehost.com with SMTP; 16 Jul 2013 15:02:58 -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=yddVeBpc3MLGbDj4yTshMnD1TkYauIw7bmXQ7V6qVRY=; b=mURkWn41YNSdRflPpBPgJlJLJwqfW2/pHsrSsReOJQ19jPPdF09eUKW03T3fGoIDIUJs12ER4DfUqw15wnX/KlkXEEBQau9TVwfFPVtzqEqHTTheUIdc/qlRGBuRiNHE; Received: from [72.66.111.124] (port=51267 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Uz6mI-0001ao-5L; Tue, 16 Jul 2013 09:02:58 -0600 From: "Richard Shockey" To: "'Hadriel Kaplan'" References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <009f01ce8229$6509e3a0$2f1daae0$@shockey.us> <27376377-8220-4AEC-97A2-A1D59DAA54DA@oracle.com> In-Reply-To: <27376377-8220-4AEC-97A2-A1D59DAA54DA@oracle.com> Date: Tue, 16 Jul 2013 11:02:56 -0400 Message-ID: <00db01ce8235$8e896690$ab9c33b0$@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: AQL/BCbN34pvssG/zmP8Y9dsYJE+5AHGECHJAXjKTQcCVaaUMAHzMIkXAW9TyhQCEOZjQADGdqIoAjwP+pcCB+b39JaFzC/w 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: 'IETF STIR Mail List' Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 15:03:26 -0000 Hadriel you are referring to the concept of a Global-SPID, which we have in the North American numbering databases as the SPID, Alt-SPID or the NECA OCN but are nonexistent on a global basis. This was an idea floated by some of the International Carriers within i3Forum which is the rough grouping of International interconnects to create the international equivalent of what we can do in NA which is determine who is the originating/terminating carrier of record from entries in the numbering databases. The running theory was a namespace could be created by IANA and populated by and run by the RIR's which cold issue the credentials for a nominal fee since IANA can't charge for registries and the Enterprise numbers and ITAD's are rather "polluted" name spaces. You could also create some WHOIS like mechanism as well. I spoke to some of the RIR about this and they were supportive but needed a full push from the International Carriers to participate in the RIR process but this was not forthcoming. Like so many things timing is critical and use cases change over time if a sufficiently large group of International carries wanted to do this I still think it could be done.. I'm sad to hear that INSIPID is not working out as planned. That said at least we are in some agreement that STIR is not a silver bullet but one of many mechanisms that need to be put in place. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Tuesday, July 16, 2013 10:21 AM To: Richard Shockey Cc: IETF STIR Mail List Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR Charter) On Jul 16, 2013, at 9:35 AM, "Richard Shockey" wrote: > I actually believe INSIPID is equally important to the overall task > since it is the track and trace elements of this that can ultimately > enable some enforcement. I wish there was some more discussion on how > the mechanisms would work at the edge SIP/SS7 network gateways since > that clearly has been the center of most of the reported problems. I > still think something needs to be done to police that traffic but that > is still ultimately a regulatory effort. I agree we need a tracking/tracing mechanism, but in my opinion we cannot and should not rely on INSIPID Session-ID at all for that. They have gone beyond benign troubleshooting-type purposes now, which means there is absolutely no guarantee the Session-ID will make it intact across service providers in all cases. In fact, my hunch is it won't. Regardless, the Session-ID isn't what we really need for tracing a bad caller-id call. Even without Session-ID, the service provider's CDRs or logs can be used to trace it back to the peering connection and peer upstream provider the call came in from. What we also need is a list of SPIDs the call request has crossed through, so we can trace it back further upstream. Kinda like a Via header, but with very different properties and purpose. We've talked about doing that before, back when there was talk about creating a registry of SPIDs. What ever happened to having a registry of SPIDs? -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From michael.hammer@yaanatech.com Tue Jul 16 08:07: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 18DC421F9E37 for ; Tue, 16 Jul 2013 08:07:52 -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 hdwHqgcaKjr1 for ; Tue, 16 Jul 2013 08:07: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 E82D221F9D39 for ; Tue, 16 Jul 2013 08:07: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; Tue, 16 Jul 2013 08:07:47 -0700 From: Michael Hammer To: "br@brianrosen.net" Thread-Topic: [stir] Rollout timeframe (was: RE: Draft STIR Charter) Thread-Index: AQHOgiOuTJJOkkJ/sEer6i+4AYu/P5lnRIJAgAB7vgD//6PPcA== Date: Tue, 16 Jul 2013 15:07:47 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> In-Reply-To: <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.87] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0094_01CE8214.B3AFE910" MIME-Version: 1.0 Cc: "philippe.fouquart@orange.com" , "Henning.Schulzrinne@fcc.gov" , "hadriel.kaplan@oracle.com" , "stir@ietf.org" Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 15:07:52 -0000 ------=_NextPart_000_0094_01CE8214.B3AFE910 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Brian, 1. The DigiNotar problem points out two problems: complexity of the delegation and lack of oversight to the distributed processes. It does not say they lost faith in the mathematics of the certificates, since they simply replaced the incompetent with other more competent administrators. In fact, the delegation process seems to be source of the weakness of the system. So, may be good to learnt he right lessons there. 2. Yes, there have to be processes for requesting an updated certificate for a number, generating the certificate, distributing the certificate. However, the distribution does not have to be tied to any hierarchy. DNS could do this via caching, but without the hierarchy complexity. The reason for updating a cert could be due to number portability, but the key trigger is just knowing that it has ported and who the new SP is so that the private key could be sent to the correct number-holder party. We don't need all the other complex routing trappings that NP already covers for routing, which is not the issue here. 3. The administrative chain and the cert distribution do not have to be the same. 4. By keeping the certificate validation NOT tied to a distribution hierarchy you can simplify the validation process and not require private systems such as CIDER suggests. 5. From a hacker attach surface consideration, I do not think it a good idea to make the DNS or some specific part of it a target more than it already is. Keeping this more about "information routing" and "how secure is the mathematics breakability" questions improves both security and deployability. I hope we start generating some requirements list, because I can think of some that might make things simpler. Mike -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, July 16, 2013 9:23 AM To: Michael Hammer Cc: philippe.fouquart@orange.com; hadriel.kaplan@oracle.com; stir@ietf.org; Henning.Schulzrinne@fcc.gov Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR Charter) There are a couple of aspects: 1. The number plan administrator has to create a credential issuing mechanism mirroring its number delegation processes. That admin may not have any knowledge of how to do that, and we need it done well to avoid DigiNotar problems 2. The service providers have to create processes to handle the credentials issued by the number plan administrator and issue credentials to its customers 3. Some Tier 2/3 service providers in places where number resell is permitted have to develop processes with their number suppliers to handle credentials 4. We want to avoid having to chase a chain of credentials (each with OSCP or equivalent checks) at verification time. This has some implications on how the above mechanisms work. Brian On Jul 16, 2013, at 9:11 AM, Michael Hammer wrote: > Philippe, > > If the solution is kept simple, the education part should not require > much effort. > > I don't see why the numbering plan would have any effect on how > trivial it might be, since asking the question what is your E.164 > number should be easy to answer. > Yes, it is possible to make administrative aspects complicated, but > if that is painful, don't go there. Could you elaborate more on that? > > For example, if ultimately what is needed is a cert that binds a > private key with an E.164 number, it could be made more complicated by > also including the chain of service providers through which the key is > delegated, but that conflation of delegation complexity with the act > of knowing a private key matches with an E.164 number may be an act of shooting oneself in the foot. > > I still like Occam's Razor and think that would be very useful here. > > Thanks, > Mike > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of philippe.fouquart@orange.com > Sent: Tuesday, July 16, 2013 8:55 AM > To: Hadriel Kaplan; Brian Rosen > Cc: IETF STIR Mail List; Henning Schulzrinne > Subject: [stir] Rollout timeframe (was: RE: Draft STIR Charter) > > I'll use Hadriel's aside note (or was it?) as an opportunity to point > out that in addition to the timeframe related to the introduction of > the stir technology itself in the network elements, endpoints etc > (which I don't disagree with), the 'administrative' part of that > effort must also be > considered/added: apologies if I'm stating the obvious or completely > missed the purpose of all this, but it seems to me that it all relies > on credentials being issued directly or indirectly by the "numbering > plan authority/administrator". > > This 'administrative' part could indeed be done in parallel and I > appreciate that this effort may be more focused on some numbering > plans than others, which may speed up the work for those, but > a) it is to me quite as much on the critical path as the pure > implementation part, which would be pointless without it, > b) contrary to technology deployment, incremental/gradual introduction > of such a framework under a given CC doesn't really make sense, it's > pretty much on/off and > c) it will be far from trivial for a lot of numbering plans and may > take considerable effort and education. > > 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: Tuesday, July 16, 2013 2:08 AM > To: Brian Rosen > Cc: IETF STIR Mail List; Henning Schulzrinne > Subject: Re: [stir] Draft STIR Charter > > > [snip] > > And it's not a "couple years". It will take us longer than that just > to get an out-of-band solution published as an RFC, let alone the > timeframe needed for it to be deployed and a Tier-2 CLEC or its customers to use it. > > Let's say it takes 2 years to get an out-of-band into an RFC. After > that more time for the vendors implement it, getting tested in carriers, etc. > Even 3 years altogether would be a minor miracle. Meanwhile, how long > do you think before a significant majority of the carriers in North > America interconnect using SIP? 5 years? Let's say it's 7 years. > The time difference between the 3 years to get out-of-band and 7 years > for in-band would be 4 years. We'd do all that work, carriers would > spend all that time and money, all for a 4-year lifespan for 15% > caller-id coverage?!? How does that make any sense? > > -hadriel > > _______________________________________________ > 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_0094_01CE8214.B3AFE910 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NjE1MDc0NlowIwYJKoZIhvcNAQkEMRYEFFtvWnzF5CAVHZoSK6UatsjjXz/5MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAaW44H8/jyB0h08jCpHEraADSTnKK3jgQaBA/osZh cD3rqI2nMdfORl0ItoEdiOY5AD2moRb9nds6gsZ6Wsj6JM6VzVMc9aUnfU8ARnt7HpJ9GXsnm+Vk 0HMxXJZH6NKFbbrYszn3nctkIAfYnyVo6QODDIPlS4vBvqGR3Juw2+kaZ1EV+XwWLf23rKh/JTd6 G+BBPjAQESKOPfYtHByx7qDaH6be535iF0v5G1sK3IrUpnYCfJEe2+1k9+DgqlaTo7MucEqs20zB 8YJYclxcw8HViNeQv8yXi0hR1X2dQ5xabD0IPZWp3VB7TfhGom/kAInTEOMJPkrstXcdBxQ2FgAA AAAAAA== ------=_NextPart_000_0094_01CE8214.B3AFE910-- From fluffy@iii.ca Mon Jul 15 14:57: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 52BCA11E81AD for ; Mon, 15 Jul 2013 14:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.611, 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 5oNuZbBtAF7W for ; Mon, 15 Jul 2013 14:57:17 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 51A5D21F9FBD for ; Mon, 15 Jul 2013 14:56:56 -0700 (PDT) Received: from sjc-vpn4-47.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 09B3322E1F3; Mon, 15 Jul 2013 17:56:48 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Cullen Jennings Date: Mon, 15 Jul 2013 14:56:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130715202002.22958.1748.idtracker@ietfa.amsl.com> To: "stir@ietf.org" X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Tue, 16 Jul 2013 08:08:44 -0700 Cc: Eric Rescorla , Jon Peterson Subject: [stir] draft-jennings-dispatch-rfc4474bis X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 15 Jul 2013 21:57:22 -0000 We submitted an update of the 4474bis draft.=20 This is just a preliminary sketch of what the changes to RFC4474 might = look like if we were going to use a bis of RFC4474 as a basis going = forward. This keeps a lot of the RFC4474 protocol machinery (headers, = response codes, UAC behavior) but changes the semantics of the Identity = header by reducing the scope of integrity protection, and the = Identity-Info header to describe certs that cover telephone numbers = instead of just domain names. Cullen Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: draft-jennings-dispatch-rfc4474bis-01.txt > Date: July 15, 2013 1:20:02 PM PDT > To: i-d-announce@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Authenticated Identity Management in the = Session Initiation Protocol (SIP) > Author(s) : Jon Peterson > Cullen Jennings > Eric Rescorla > Filename : draft-jennings-dispatch-rfc4474bis-01.txt > Pages : 44 > Date : 2013-07-15 >=20 > Abstract: > The baseline security mechanisms in the Session Initiation Protocol > (SIP) are inadequate for cryptographically assuring the identity of > the end users that originate SIP requests, especially in an > interdomain context. This document defines a mechanism for securely > identifying originators of SIP requests. It does so by defining new > SIP header fields for conveying a signature used for validating the > identity, and for conveying a reference to the credentials of the > signer. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-jennings-dispatch-rfc4474bis >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-jennings-dispatch-rfc4474bis-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-jennings-dispatch-rfc4474bis-01= >=20 From michael.hammer@yaanatech.com Tue Jul 16 08: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 89C7321E8094 for ; Tue, 16 Jul 2013 08:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 zPBT2fbvIuuY for ; Tue, 16 Jul 2013 08:11:59 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 6128321E8091 for ; Tue, 16 Jul 2013 08:11:59 -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, 16 Jul 2013 08:11:59 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" , "br@brianrosen.net" , "philippe.fouquart@orange.com" Thread-Topic: [stir] Rollout timeframe (was: RE: Draft STIR Charter) Thread-Index: AQHOgiOuTJJOkkJ/sEer6i+4AYu/P5lnvooAgAANwoD//5ypIA== Date: Tue, 16 Jul 2013 15:11:58 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC17E02@EX2K10MB1.corp.yaanatech.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <80F50A9C-852B-45C8-9637-83DB1A718888@brianrosen.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.87] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_00A4_01CE8215.4942ED10" MIME-Version: 1.0 Cc: "stir@ietf.org" , "dan-ietf@danyork.org" Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 15:12:03 -0000 ------=_NextPart_000_00A4_01CE8215.4942ED10 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit ++1 Administrative complexity counts. But, let us leverage existing painfully wrought systems such as number portability rather than reinvent them. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Tuesday, July 16, 2013 10:06 AM To: Brian Rosen; philippe.fouquart@orange.com Cc: IETF STIR Mail List; Dan York Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR Charter) +1. I think Philippe's point is more critical to ultimate success than the rest of the stuff we've been arguing about. But we don't need the official number authorities to be involved to start this thing and get it useful. We can start "trials" by just using a commonly-agreed-upon anchor or two in a given country. Even if the trials grow to include multiple countries with different anchors for each country, it will still be manageable. In fact, all ~160 country-codes could each define their own anchor and it would still be manageable. Even for the +1 country-code, which is probably the most complicated in terms of numbering plan, authorities, and number of carriers - even for that we'd only really need a handful of the bigger carriers in a country-code to do it, and the rest would join up soon enough. Ultimately, in some future time, we would likely want/need the numbering authorities to be involved. But as Brian said, it's not something the IETF does particularly well. We're an engineering organization mostly. And as far as I can tell, much of our regulatory contact seems to be North American. (though I could easily be wrong about that) For European regulators I would expect 3GPP and ETSI might help us out some on this issue. For Asia, South America, Middle East, and Africa, we could wait for this to percolate, or 3GPP might be able to help with them too. I assume that the IETF does have formal or informal liaisons with at least the RIRs, and they might be able to make contact with the telephone numbering authorities in various countries. Also, I've been told ISOC tries to help with IETF-related education/evangelism around the world too, but I'm not sure about dealing with regulators. (Dan: do you know?) -hadriel On Jul 16, 2013, at 9:16 AM, Brian Rosen wrote: > This is an important point, and it's not something the IETF does particularly well, especially the "take considerable effort and education" part. > The IETF has been paying more attention to relationships with governments and regulators lately, and I hope we will be able to leverage that effort. > > Brian > > On Jul 16, 2013, at 8:54 AM, philippe.fouquart@orange.com wrote: > >> I'll use Hadriel's aside note (or was it?) as an opportunity to point out that in addition to the timeframe related to the introduction of the stir technology itself in the network elements, endpoints etc (which I don't disagree with), the 'administrative' part of that effort must also be considered/added: apologies if I'm stating the obvious or completely missed the purpose of all this, but it seems to me that it all relies on credentials being issued directly or indirectly by the "numbering plan authority/administrator". >> >> This 'administrative' part could indeed be done in parallel and I >> appreciate that this effort may be more focused on some numbering >> plans than others, which may speed up the work for those, but >> a) it is to me quite as much on the critical path as the pure >> implementation part, which would be pointless without it, >> b) contrary to technology deployment, incremental/gradual >> introduction of such a framework under a given CC doesn't really make >> sense, it's pretty much on/off and >> c) it will be far from trivial for a lot of numbering plans and may take considerable effort and education. >> >> 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: Tuesday, July 16, 2013 2:08 AM >> To: Brian Rosen >> Cc: IETF STIR Mail List; Henning Schulzrinne >> Subject: Re: [stir] Draft STIR Charter >> >> >> [snip] >> >> And it's not a "couple years". It will take us longer than that just to get an out-of-band solution published as an RFC, let alone the timeframe needed for it to be deployed and a Tier-2 CLEC or its customers to use it. >> >> Let's say it takes 2 years to get an out-of-band into an RFC. After that more time for the vendors implement it, getting tested in carriers, etc. Even 3 years altogether would be a minor miracle. Meanwhile, how long do you think before a significant majority of the carriers in North America interconnect using SIP? 5 years? Let's say it's 7 years. The time difference between the 3 years to get out-of-band and 7 years for in-band would be 4 years. We'd do all that work, carriers would spend all that time and money, all for a 4-year lifespan for 15% caller-id coverage?!? How does that make any sense? >> >> -hadriel >> >> _______________________________________________ >> 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 > _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_00A4_01CE8215.4942ED10 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NjE1MTE1N1owIwYJKoZIhvcNAQkEMRYEFLAJIl5DG+OHecwo3s7I/cz8UwUUMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAMNeBd/T+OBl6Kg9Ygdy0hlpAOAWx4uAMsdgTW+JI y8+njT1ncdVihD4e4VQ/WeopfbbngxK/y6EnicqztjsZEFcU9ZyrJMuHv9N9cldo69HZl2+iFf1M i3wySxGOcz9PObsqXYfKm+L7bCfwaOuYfED90eL9KJe/fDBaVjweT4/YrMol0cIb1LjHNBzgiCcJ hAqvBvN+HJ9rVOuSSPqpmfgTuuzdA7JlZfHLw0juvO7w9lPDu0hZES6vgAA3JGvbzKaHKHhWllg2 /isuTVxvfx7ePGp0nWWGJkJiL9eLTr6jMUZriuMpDEpWWo2RKPaSwOo3tCUpcobp0JLabb4nuAAA AAAAAA== ------=_NextPart_000_00A4_01CE8215.4942ED10-- From michael.hammer@yaanatech.com Tue Jul 16 08:14:17 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3A91F0D3F for ; Tue, 16 Jul 2013 08:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 SgiYItkMDlPM for ; Tue, 16 Jul 2013 08:14: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 59E021F0D3E for ; Tue, 16 Jul 2013 08:14:13 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 16 Jul 2013 08:14:13 -0700 From: Michael Hammer To: "philippe.fouquart@orange.com" , "hadriel.kaplan@oracle.com" , "br@brianrosen.net" Thread-Topic: [stir] Rollout timeframe (was: RE: Draft STIR Charter) Thread-Index: AQHOgiOuTJJOkkJ/sEer6i+4AYu/P5lnRIJAgACJggD//5uuUA== Date: Tue, 16 Jul 2013 15:14:11 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC17E29@EX2K10MB1.corp.yaanatech.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.87] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_00AE_01CE8215.98F68560" MIME-Version: 1.0 Cc: "stir@ietf.org" , "Henning.Schulzrinne@fcc.gov" Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 15:14:17 -0000 ------=_NextPart_000_00AE_01CE8215.98F68560 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Phillippe, I agree wholeheartedly with your concerns. I just don't want to re-invent that wheel again. :) Mike -----Original Message----- From: philippe.fouquart@orange.com [mailto:philippe.fouquart@orange.com] Sent: Tuesday, July 16, 2013 10:12 AM To: Michael Hammer; hadriel.kaplan@oracle.com; br@brianrosen.net Cc: stir@ietf.org; Henning.Schulzrinne@fcc.gov Subject: RE: [stir] Rollout timeframe (was: RE: Draft STIR Charter) Mike, I wasn't referring to the _structure_ of the numbering plan, sorry. I agree it's pretty much orthogonal to the difficulty of that part of the task. Along the same line as Brian's post, I was referring to the time that would be necessary for putting in place procedures and an operational framework whereby when a decision is made by and under the control of the administrator of assigning a range/number/... to... anyone say, the corresponding credentials are issued; when ranges are reclaimed, credentials are revoked; when assignment rulings are renewed by that administrator, they're consistently renewed; what it all means when number ranges are transferred between assignees, when they're suballocated to third parties if it's permitted by the national policies, prohibited if it's not; what it means when numbers are ported if portability applies etc.... Yes, maybe I'm overcomplicating things or being too pragmatic, I'm just trying to see how that fits in the real life of a national numbering plan in fact (given that there are national variations and that the generally people in charge wouldn't contemplate applying for a security area AD position, no more than I would, considering...) and how that translates into an infrastructure upon which the mechanisms this group develops can rely. Not that I think the group could have some leverage on this administrative part (and I agree with Richard that that part is indeed leaning towards regulatory issues) other than making sure the documents that are developed here are accessible to the layman, I was merely observing that it could take... "quite some time". Regards, Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Tuesday, July 16, 2013 3:12 PM To: FOUQUART Philippe OLNC/OLN; hadriel.kaplan@oracle.com; br@brianrosen.net Cc: stir@ietf.org; Henning.Schulzrinne@fcc.gov Subject: RE: [stir] Rollout timeframe (was: RE: Draft STIR Charter) Philippe, If the solution is kept simple, the education part should not require much effort. I don't see why the numbering plan would have any effect on how trivial it might be, since asking the question what is your E.164 number should be easy to answer. Yes, it is possible to make administrative aspects complicated, but if that is painful, don't go there. Could you elaborate more on that? For example, if ultimately what is needed is a cert that binds a private key with an E.164 number, it could be made more complicated by also including the chain of service providers through which the key is delegated, but that conflation of delegation complexity with the act of knowing a private key matches with an E.164 number may be an act of shooting oneself in the foot. I still like Occam's Razor and think that would be very useful here. Thanks, Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of philippe.fouquart@orange.com Sent: Tuesday, July 16, 2013 8:55 AM To: Hadriel Kaplan; Brian Rosen Cc: IETF STIR Mail List; Henning Schulzrinne Subject: [stir] Rollout timeframe (was: RE: Draft STIR Charter) I'll use Hadriel's aside note (or was it?) as an opportunity to point out that in addition to the timeframe related to the introduction of the stir technology itself in the network elements, endpoints etc (which I don't disagree with), the 'administrative' part of that effort must also be considered/added: apologies if I'm stating the obvious or completely missed the purpose of all this, but it seems to me that it all relies on credentials being issued directly or indirectly by the "numbering plan authority/administrator". This 'administrative' part could indeed be done in parallel and I appreciate that this effort may be more focused on some numbering plans than others, which may speed up the work for those, but a) it is to me quite as much on the critical path as the pure implementation part, which would be pointless without it, b) contrary to technology deployment, incremental/gradual introduction of such a framework under a given CC doesn't really make sense, it's pretty much on/off and c) it will be far from trivial for a lot of numbering plans and may take considerable effort and education. 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: Tuesday, July 16, 2013 2:08 AM To: Brian Rosen Cc: IETF STIR Mail List; Henning Schulzrinne Subject: Re: [stir] Draft STIR Charter [snip] And it's not a "couple years". It will take us longer than that just to get an out-of-band solution published as an RFC, let alone the timeframe needed for it to be deployed and a Tier-2 CLEC or its customers to use it. Let's say it takes 2 years to get an out-of-band into an RFC. After that more time for the vendors implement it, getting tested in carriers, etc. Even 3 years altogether would be a minor miracle. Meanwhile, how long do you think before a significant majority of the carriers in North America interconnect using SIP? 5 years? Let's say it's 7 years. The time difference between the 3 years to get out-of-band and 7 years for in-band would be 4 years. We'd do all that work, carriers would spend all that time and money, all for a 4-year lifespan for 15% caller-id coverage?!? How does that make any sense? -hadriel _______________________________________________ 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_00AE_01CE8215.98F68560 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NjE1MTQxMVowIwYJKoZIhvcNAQkEMRYEFIC4WeuhbAI5O9yKusifR0GV1e+xMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEADTVhBZJVkoGUU4mj8zmwEGCosoWuPdu1O2GCSNAC XIBiksbAAm5oqNlznr0MAMZDNW2SwnAmupZpqTohNuAT3CzfbSdiQM+9kpV5tQghp0N7viqIexHy HAOpWbkXzo3Qt+1yXf6hiDCXNt+Vl/zObZelMMlTp35DQCvNkwPSodVF1YhKGmU0h7MJWSjxCrw8 OEOn5cht+2411KEtxZScwbtQueO27h4QU125RxihBngt8CPiTiVB5K7sLo6gaQFK1YdPIlXBzo42 X/I6ajQxWuQWMtakbcgfs/Xmcv/wtxQE/KXOISBCFRPrJu4BCjcklXxy2di20jHxD0yqr1wxlAAA AAAAAA== ------=_NextPart_000_00AE_01CE8215.98F68560-- From hadriel.kaplan@oracle.com Tue Jul 16 08:23: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 ACAC821F9AF5 for ; Tue, 16 Jul 2013 08:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.481 X-Spam-Level: X-Spam-Status: No, score=-6.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfR2fgmFQNDI for ; Tue, 16 Jul 2013 08:23:00 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 57B3F21F9B90 for ; Tue, 16 Jul 2013 08:22:59 -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 r6GFMuOg021584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Jul 2013 15:22:57 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 r6GFMt4A019808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 15:22:55 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 r6GFMt4U019801; Tue, 16 Jul 2013 15:22:55 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 16 Jul 2013 08:22:55 -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: <7A9C6940-5BC1-4A22-A4C8-85EF5495D4EC@brianrosen.net> Date: Tue, 16 Jul 2013 11:22:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <128B5434-F59B-4347-A7BB-AC8AF5412FC9@oracle.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <009f01ce8229$6509e3a0$2f1daae0$@shockey.us> <27376377-8220-4AEC-97A2-A1D59DAA54DA@oracle.com> <7A9C6940-5BC1-4A22-A4C8-85EF5495D4EC@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: IETF STIR Mail List , Richard Shockey Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 15:23:07 -0000 On Jul 16, 2013, at 10:45 AM, Brian Rosen wrote: > If INSIPID's session ID won't survive end to end, what do you suggest = we use here to avoid replay? We just need to put something into the new header we create for the = signature and other stuff. That's what both = draft-kaplan-sip-asserter-identity and draft-kaplan-stir-ikes-out-00 do. = RFC4474 used the Call-ID and Cseq number to prevent replay because they = were conveniently available, and because at a SIP layer getting the same = values would reject the message even due to normal SIP processing rules. = But we won't have the latter benefit even with Session-ID, and we = basically have to rely on only the verifier being the one to = detect/prevent replays. BTW, it doesn't have to be a random value, either - it could be a = sequential number. It just has to provide enough uniqueness within one = second of time, for the same source-dest E.164 pair, so that the signer = can successfully generate another message for the same source-dest pair = within the same second without the signer itself being detected as a = replay. As long as the verifier remembers there was a message from the = source-dest pair and its timestamp and its sequence number, for the ~15 = minutes a timestamp is valid for, then the verifier can prevent replays. = So I do that in the IKES mechanism, by requiring the verifier to = remember the IKES-IF string value for 20 minutes, and comparing future = request IKES-IF strings against it. (it doesn't need to be for a full = 20 minutes though - the draft needs to be tightened up some) -hadriel From kent@bbn.com Tue Jul 16 08:24: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 892BC21F9AF5 for ; Tue, 16 Jul 2013 08:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpY-pLsSylRw for ; Tue, 16 Jul 2013 08:24:19 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 42B9121F8617 for ; Tue, 16 Jul 2013 08:24:19 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:54934) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Uz76v-000Fpb-DD; Tue, 16 Jul 2013 11:24:17 -0400 Message-ID: <51E565A2.80806@bbn.com> Date: Tue, 16 Jul 2013 11:24:18 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: michael.hammer@yaanatech.com References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> Content-Type: multipart/alternative; boundary="------------000501030605010506070404" Cc: stir@ietf.org Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 15:24:34 -0000 This is a multi-part message in MIME format. --------------000501030605010506070404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mike, > If the solution is kept simple, the education part should not require much > effort. > > I don't see why the numbering plan would have any effect on how trivial it > might be, since asking the question what is your E.164 number should be easy > to answer. > Yes, it is possible to make administrative aspects complicated, but if that > is painful, don't go there. Could you elaborate more on that? > > For example, if ultimately what is needed is a cert that binds aPUBLIC key > with an E.164 number, it could be made more complicated by also including > the chain of service providers through which the key is delegated (probably not the right term), but that > conflation of delegation complexity with the act of knowing aPUBLIC key > matches with an E.164 number may be an act of shooting oneself in the foot. > Consistent with my earlier comment re who makes for a good CA, a called party need to be able to verify that the entity who asserts the binding between the public key and an E.164 number is authorized to do so. In the best case, that would call for the cert path (which is not "key delegation" per se) to match the phone number assignment/delegation path. Steve --------------000501030605010506070404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mike,

If the solution is kept simple, the education part should not require much
effort.

I don't see why the numbering plan would have any effect on how trivial it
might be, since asking the question what is your E.164 number should be easy
to answer.
Yes,  it is possible to make administrative aspects complicated, but if that
is painful, don't go there.  Could you elaborate more on that?

For example, if ultimately what is needed is a cert that binds a PUBLIC key
with an E.164 number, it could be made more complicated by also including
the chain of service providers through which the key is delegated (probably not the right term), but that
conflation of delegation complexity with the act of knowing a PUBLIC key
matches with an E.164 number may be an act of shooting oneself in the foot.
Consistent with my earlier comment re who makes for a good CA, a called
party need to be able to verify that the entity who asserts the binding
between the public key and an E.164 number is authorized to do so. In the
best case, that would call for the cert path (which is not "key delegation" per se)
to match the phone number assignment/delegation path.

Steve
--------------000501030605010506070404-- From michael.hammer@yaanatech.com Tue Jul 16 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 8C41521F85BB for ; Tue, 16 Jul 2013 08:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkuJfhdq-mme for ; Tue, 16 Jul 2013 08:43: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 0A74A11E80F2 for ; Tue, 16 Jul 2013 08:43:53 -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, 16 Jul 2013 08:43:52 -0700 From: Michael Hammer To: "kent@bbn.com" Thread-Topic: [stir] Rollout timeframe Thread-Index: AQHOgjiLZosA/DKyMEuxDpDhXheKTZlnbarw Date: Tue, 16 Jul 2013 15:43:51 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC17EE8@EX2K10MB1.corp.yaanatech.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <51E565A2.80806@bbn.com> In-Reply-To: <51E565A2.80806@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.87] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_00D0_01CE8219.BD8498A0" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 15:44:06 -0000 ------=_NextPart_000_00D0_01CE8219.BD8498A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00D1_01CE8219.BD8498A0" ------=_NextPart_001_00D1_01CE8219.BD8498A0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Why? The cert path can be very short and orthogonal to the delegation path. The authoritative cert signer can get the base cert passed up to it via secure means or it can create and sign the cert at the top. The only important aspect there is that the cert creator know definitively who to send the private key to. That does not need to be shared across the delegation path. Either way, the delegation path does not *need* to be in the cert. BTW, I would also not pollute the original caller ID with delegated caller assertions. There is no reason there could not be a secondary assertion that binds the "display number" with the "calling party number": - Verify the calling party ID: Authoritative cert - Verify the association of calling party ID with Display ID: Delegation signed by private key of authoritative cert for the "borrowed number" (e.g. office number) - Display the Display ID Mike From: Stephen Kent [mailto:kent@bbn.com] Sent: Tuesday, July 16, 2013 11:24 AM To: Michael Hammer Cc: stir@ietf.org Subject: Re: [stir] Rollout timeframe Mike, If the solution is kept simple, the education part should not require much effort. I don't see why the numbering plan would have any effect on how trivial it might be, since asking the question what is your E.164 number should be easy to answer. Yes, it is possible to make administrative aspects complicated, but if that is painful, don't go there. Could you elaborate more on that? For example, if ultimately what is needed is a cert that binds a PUBLIC key with an E.164 number, it could be made more complicated by also including the chain of service providers through which the key is delegated (probably not the right term), but that conflation of delegation complexity with the act of knowing a PUBLIC key matches with an E.164 number may be an act of shooting oneself in the foot. Consistent with my earlier comment re who makes for a good CA, a called party need to be able to verify that the entity who asserts the binding between the public key and an E.164 number is authorized to do so. In the best case, that would call for the cert path (which is not "key delegation" per se) to match the phone number assignment/delegation path. Steve ------=_NextPart_001_00D1_01CE8219.BD8498A0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Why? 

 

The cert path can be very short and orthogonal to the delegation = path.

The authoritative cert signer can get the base cert passed up to it = via secure means or it can create and sign the cert at the = top.

The only important aspect there is that the cert creator know = definitively who to send the private key to.

That does not need to be shared across the delegation = path.

 

Either way, the delegation path does not *need* to be in the = cert.

 

BTW, I would also not pollute the original caller ID with delegated = caller assertions. 

There is no reason there could not be a secondary assertion that = binds the “display number” with the “calling party = number”:

-          = Verify the calling party ID:  Authoritative = cert

-          = Verify the association of calling party ID with Display ID:  = Delegation signed by private key of authoritative cert for the = “borrowed number” (e.g. office = number)

-          = Display the Display ID

 

Mike

 

 

From: Stephen Kent [mailto:kent@bbn.com]
Sent: Tuesday, July = 16, 2013 11:24 AM
To: Michael Hammer
Cc: = stir@ietf.org
Subject: Re: [stir] Rollout = timeframe

 

Mike,


If the solution =
is kept simple, the education part should not require =
much
effort.
 <=
/pre>
I don't see why the numbering plan would have any effect on =
how trivial it
might be, since asking the question =
what is your E.164 number should be easy
to =
answer.
Yes,  it is possible to make =
administrative aspects complicated, but if that
is =
painful, don't go there.  Could you elaborate more on =
that?
 
For example, if =
ultimately what is needed is a cert that binds a PUBLIC key
with an E.164 =
number, it could be made more complicated by also =
including
the chain of service providers through =
which the key is delegated (probably not the =
right term), but that
conflation of =
delegation complexity with the act of knowing a PUBLIC key
matches with =
an E.164 number may be an act of shooting oneself in the =
foot.
 
Consistent with my earlier comment re who makes for a =
good CA, a called
party need to be able to verify that the entity who =
asserts the binding
between the public key and an E.164 number is =
authorized to do so. In the
best case, that would call for the cert =
path (which is not "key delegation" per se) 
to match the =
phone number assignment/delegation =
path.

Steve
------=_NextPart_001_00D1_01CE8219.BD8498A0-- ------=_NextPart_000_00D0_01CE8219.BD8498A0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NjE1NDM1MFowIwYJKoZIhvcNAQkEMRYEFOWJ6vvp+vpyrjdbDy2x4rllR3CgMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAUyTKL56rURkxBGI5Iwv7snpExx5DIdLONQe0wiaI Llhr2QarcaO1YlGe2fPkLPvu5hMWsIXy7O2/YCZ8QJ3RWrthrTAyIn6Vs2XlvMrGwS8Avo+VrHCi PO/M3Ow0Oed8KD0zGkuXcMPTVVfBeZXHVSE+toT/YL4XuSkbXDVR1Ukpto/zZV7q0cSely9UDzp2 zyvnejaXEe7yZVVTzBomh8ZT3wiSQsJhpWY/LjDcuGlAduRUIdd5f/XfacEymNMqEvyMHFm81kia 9oWVus0XqByQ9aRxH55g/l4DQavVaAfVEnstz8rvD8yCtPl6+KQCiDl//xX00K0xxqpo65QnuwAA AAAAAA== ------=_NextPart_000_00D0_01CE8219.BD8498A0-- From kent@bbn.com Tue Jul 16 08:56: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 9F08721F9A81 for ; Tue, 16 Jul 2013 08:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Tiud6rtgc8e for ; Tue, 16 Jul 2013 08:56:38 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC2C21F9ADA for ; Tue, 16 Jul 2013 08:56:37 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:55603) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Uz7c3-000Cpp-20; Tue, 16 Jul 2013 11:56:27 -0400 Message-ID: <51E56D2C.2010700@bbn.com> Date: Tue, 16 Jul 2013 11:56:28 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Michael Hammer References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> Content-Type: multipart/alternative; boundary="------------050302090102060607080206" Cc: "philippe.fouquart@orange.com" , "Henning.Schulzrinne@fcc.gov" , "hadriel.kaplan@oracle.com" , "stir@ietf.org" , "br@brianrosen.net" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 15:56:44 -0000 This is a multi-part message in MIME format. --------------050302090102060607080206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mike, > Brian, > > 1. The DigiNotar problem points out two problems: complexity of the > delegation and lack of oversight to the distributed processes. It does not > say they lost faith in the mathematics of the certificates, since they > simply replaced the incompetent with other more competent administrators. > In fact, the delegation process seems to be source of the weakness of the > system. So, may be good to learnt he right lessons there. DigiNotar was a disaster largely because _all_ of the TAs in the browser environment are able to issue certs for _any_ DNS name. So, yes, the failure to constrain the scope of "delegation" in that context is the really big problem. Also, technology was commercially available for many years that would have allowed DigiNotar to detect the covert issuance of certs and to allow them to revoke those certs. DigiNotar just didn't make use of such technology. > 2. Yes, there have to be processes for requesting an updated certificate > for a number, generating the certificate, distributing the certificate. > However, the distribution does not have to be tied to any hierarchy. DNS > could do this via caching, but without the hierarchy complexity. The reason > for updating a cert could be due to number portability, but the key trigger > is just knowing that it has ported and who the new SP is so that the private > key could be sent to the correct number-holder party. We don't need all the > other complex routing trappings that NP already covers for routing, which is > not the issue here. I'm not sure I agree with your notion of no need for a hierarchy. Numbering plans appear to be administered in a hierarchic fashion (said the telephony outsider), and so aligning a PKI with that hierarchy would be a natural fit, one that would counter the large scale failure that accompanied the DigiNotar security failure. DNSSEC and the RPKI are both examples where the certification system aligns with an extant, hierarchic system. Steve --------------050302090102060607080206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mike,

Brian,

1.  The DigiNotar problem points out two problems:  complexity of the
delegation and lack of oversight to the distributed processes.  It does not
say they lost faith in the mathematics of the certificates, since they
simply replaced the incompetent with other more competent administrators.
In fact, the delegation process seems to be source of the weakness of the
system.  So, may be good to learnt he right lessons there.
DigiNotar was a disaster largely because all of the TAs in the browser
environment are able to issue certs for any DNS name. So, yes, the failure
to constrain the scope of "delegation" in that context is the really big problem.
Also, technology was commercially available for many years that would have allowed
DigiNotar to detect the covert issuance of certs and to allow them to revoke those
certs. DigiNotar just didn't make use of such technology.
2.  Yes, there have to be processes for requesting an updated certificate
for a number, generating the certificate, distributing the certificate.
However, the distribution does not have to be tied to any hierarchy.  DNS
could do this via caching, but without the hierarchy complexity.  The reason
for updating a cert could be due to number portability, but the key trigger
is just knowing that it has ported and who the new SP is so that the private
key could be sent to the correct number-holder party.  We don't need all the
other complex routing trappings that NP already covers for routing, which is
not the issue here.
I'm not sure I agree with your notion of no need for a hierarchy. Numbering
plans appear to be administered in a hierarchic fashion  (said the telephony outsider),
and so aligning a PKI with that hierarchy would be a natural fit, one that would
counter the large scale failure that accompanied the DigiNotar security failure.
DNSSEC and the RPKI are both examples where the certification system aligns with
an extant, hierarchic system.

Steve
--------------050302090102060607080206-- From kent@bbn.com Tue Jul 16 09: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 6C2B321F93BF for ; Tue, 16 Jul 2013 09:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOmNsQytZN1o for ; Tue, 16 Jul 2013 09:04:14 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7789621F9A94 for ; Tue, 16 Jul 2013 09:04:14 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:55626) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Uz7jZ-000Gfq-HR; Tue, 16 Jul 2013 12:04:13 -0400 Message-ID: <51E56EFE.5040106@bbn.com> Date: Tue, 16 Jul 2013 12:04:14 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Michael Hammer References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <51E565A2.80806@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17EE8@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC17EE8@EX2K10MB1.corp.yaanatech.com> Content-Type: multipart/alternative; boundary="------------080506040602010304050009" Cc: "stir@ietf.org" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 16:04:20 -0000 This is a multi-part message in MIME format. --------------080506040602010304050009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mike, > > Why? > > The cert path can be very short and orthogonal to the delegation path. > it could be, but alignment makes the system simpler and easier to understand, and is supportive of the security principle of "least privilege". > > The authoritative cert signer can get the base cert passed up to it > via secure means or it can create and sign the cert at the top. > > The only important aspect there is that the cert creator know > definitively who to send the private key to. > In the vast majority of PKIs, cert subjects do not send private keys to cert issuers , so I am confused by the statement above. > > That does not need to be shared across the delegation path. > > Either way, the delegation path does not **need** to be in the cert. > agreed, and in standard cert formats there is not way to represent the path anyway. Steve --------------080506040602010304050009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mike,

Why? 

 

The cert path can be very short and orthogonal to the delegation path.

it could be, but alignment makes the system simpler and easier to understand,
and is supportive of the security principle of "least privilege".

The authoritative cert signer can get the base cert passed up to it via secure means or it can create and sign the cert at the top.

The only important aspect there is that the cert creator know definitively who to send the private key to.

In the vast majority of PKIs, cert subjects do not send private keys to cert
issuers , so I am confused by the statement above.

That does not need to be shared across the delegation path.

 

Either way, the delegation path does not *need* to be in the cert.

agreed, and in standard cert formats there is not way to represent the path anyway.

Steve
--------------080506040602010304050009-- From br@brianrosen.net Tue Jul 16 09:11: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 C610411E80D7 for ; Tue, 16 Jul 2013 09:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.271 X-Spam-Level: X-Spam-Status: No, score=-100.271 tagged_above=-999 required=5 tests=[AWL=0.165, 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 dBzsLRr6czCt for ; Tue, 16 Jul 2013 09:11:40 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 6E65C11E80D5 for ; Tue, 16 Jul 2013 09:11:40 -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=1XsXVPIt5gA0LKDmReYpGbyXF5E++wGkSpcPYm+3YbQ=; b=C/aHSnYUNP5LwHzGiny5TLd7Rs9SBzB+XPOEQPBl+S+ZPYQ4pluTnM8r5q6W2ZcSbpSE5FcrNsqPe76vaVbEaFZqtu3gshEoI3VaY8rZO4MKRCgupqHwcxBjny3Em9T3b9phwzgo/ocM+GhelOLkIAXRJhcbt7TdIRnAe6MYsiM=; Received: from neustargw.va.neustar.com ([209.173.53.233]:59222 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1Uz7ql-0004PN-9q; Tue, 16 Jul 2013 12:11:39 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_4DB7A3A4-C18B-4124-9305-507C1142AA1A" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <51E56EFE.5040106@bbn.com> Date: Tue, 16 Jul 2013 12:11:37 -0400 Message-Id: <30AC5063-E6F6-4230-98B0-3A52D8EF71CA@brianrosen.net> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <51E565A2.80806@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17EE8@EX2K10MB1.corp.yaanatech.com> <51E56EFE.5040106@bbn.com> To: Stephen Kent 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" , Michael Hammer Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 16:11:54 -0000 --Apple-Mail=_4DB7A3A4-C18B-4124-9305-507C1142AA1A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I think the credential path follows the delegation path, but I hope that = in most deployments, we're not chasing a chain of credentials to = validate. Ultimately, remember the math Henning did - even with cert per TN, it's = still not a whole lot of data. Brian On Jul 16, 2013, at 12:04 PM, Stephen Kent wrote: > Mike, >> Why?=20 >> =20 >> The cert path can be very short and orthogonal to the delegation = path. > it could be, but alignment makes the system simpler and easier to = understand, > and is supportive of the security principle of "least privilege". >> The authoritative cert signer can get the base cert passed up to it = via secure means or it can create and sign the cert at the top. >> The only important aspect there is that the cert creator know = definitively who to send the private key to. > In the vast majority of PKIs, cert subjects do not send private keys = to cert > issuers , so I am confused by the statement above. >> That does not need to be shared across the delegation path. >> =20 >> Either way, the delegation path does not *need* to be in the cert. > agreed, and in standard cert formats there is not way to represent the = path anyway. >=20 > Steve > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_4DB7A3A4-C18B-4124-9305-507C1142AA1A Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 I think the credential path follows the delegation path, but I hope that in most deployments, we're not chasing a chain of credentials to validate.

Ultimately, remember the math Henning did - even with cert per TN, it's still not a whole lot of data.

Brian

On Jul 16, 2013, at 12:04 PM, Stephen Kent <kent@bbn.com> wrote:

Mike,

Why? 

 

The cert path can be very short and orthogonal to the delegation path.

it could be, but alignment makes the system simpler and easier to understand,
and is supportive of the security principle of "least privilege".

The authoritative cert signer can get the base cert passed up to it via secure means or it can create and sign the cert at the top.

The only important aspect there is that the cert creator know definitively who to send the private key to.

In the vast majority of PKIs, cert subjects do not send private keys to cert
issuers , so I am confused by the statement above.

That does not need to be shared across the delegation path.

 

Either way, the delegation path does not *need* to be in the cert.

agreed, and in standard cert formats there is not way to represent the path anyway.

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

--Apple-Mail=_4DB7A3A4-C18B-4124-9305-507C1142AA1A-- From michael.hammer@yaanatech.com Tue Jul 16 09:12:31 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1C821F8449 for ; Tue, 16 Jul 2013 09:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SeJsnjJg9YX for ; Tue, 16 Jul 2013 09:12:26 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 8799D21F9EEB for ; Tue, 16 Jul 2013 09:12:20 -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, 16 Jul 2013 09:12:19 -0700 From: Michael Hammer To: "kent@bbn.com" Thread-Topic: [stir] Rollout timeframe Thread-Index: AQHOgj0MegkF68FLTUyBdNmNASSKrplnd8ug Date: Tue, 16 Jul 2013 16:12:18 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> In-Reply-To: <51E56D2C.2010700@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.87] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_00D8_01CE821D.B6E18AE0" MIME-Version: 1.0 Cc: "philippe.fouquart@orange.com" , "Henning.Schulzrinne@fcc.gov" , "hadriel.kaplan@oracle.com" , "stir@ietf.org" , "br@brianrosen.net" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 16:12:32 -0000 ------=_NextPart_000_00D8_01CE821D.B6E18AE0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00D9_01CE821D.B6E18AE0" ------=_NextPart_001_00D9_01CE821D.B6E18AE0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Steve, I am not saying that the existing delegation system cannot be leveraged, just don't co-mingle the administrative with the operational. There are a lot of privacy concerns identified by SPs about revealing what numbers they are assigned. By not co-mingling, you can avoid those concerns, and thus freely distribute certs. As long as the PKI has a secure automated means by which they can verify that an SP has "ownership" of the number for which they request a cert, there is no reason a cert could not be signed for them or be issued directly to them. Every additional link you put into that validation chain is one more possibility of failure. It's about minimizing failure with simple operation and strong oversight. Mike From: Stephen Kent [mailto:kent@bbn.com] Sent: Tuesday, July 16, 2013 11:56 AM To: Michael Hammer Cc: br@brianrosen.net; philippe.fouquart@orange.com; Henning.Schulzrinne@fcc.gov; hadriel.kaplan@oracle.com; stir@ietf.org Subject: Re: [stir] Rollout timeframe Mike, Brian, 1. The DigiNotar problem points out two problems: complexity of the delegation and lack of oversight to the distributed processes. It does not say they lost faith in the mathematics of the certificates, since they simply replaced the incompetent with other more competent administrators. In fact, the delegation process seems to be source of the weakness of the system. So, may be good to learnt he right lessons there. DigiNotar was a disaster largely because all of the TAs in the browser environment are able to issue certs for any DNS name. So, yes, the failure to constrain the scope of "delegation" in that context is the really big problem. Also, technology was commercially available for many years that would have allowed DigiNotar to detect the covert issuance of certs and to allow them to revoke those certs. DigiNotar just didn't make use of such technology. 2. Yes, there have to be processes for requesting an updated certificate for a number, generating the certificate, distributing the certificate. However, the distribution does not have to be tied to any hierarchy. DNS could do this via caching, but without the hierarchy complexity. The reason for updating a cert could be due to number portability, but the key trigger is just knowing that it has ported and who the new SP is so that the private key could be sent to the correct number-holder party. We don't need all the other complex routing trappings that NP already covers for routing, which is not the issue here. I'm not sure I agree with your notion of no need for a hierarchy. Numbering plans appear to be administered in a hierarchic fashion (said the telephony outsider), and so aligning a PKI with that hierarchy would be a natural fit, one that would counter the large scale failure that accompanied the DigiNotar security failure. DNSSEC and the RPKI are both examples where the certification system aligns with an extant, hierarchic system. Steve ------=_NextPart_001_00D9_01CE821D.B6E18AE0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Steve,

 

I am not saying that the existing delegation system cannot be = leveraged, just don’t co-mingle the administrative with the = operational.

There are a lot of privacy concerns identified by SPs about revealing = what numbers they are assigned.

By not co-mingling, you can avoid those concerns, and thus freely = distribute certs.

 

As long as the PKI has a secure automated means by which they can = verify that an SP has “ownership” of the number for which = they request a cert,

there is no reason a cert could not be signed for them or be issued = directly to them.

 

Every additional link you put into that validation chain is one more = possibility of failure.

It’s about minimizing failure with simple operation and strong = oversight.

 

Mike

 

 

From: Stephen Kent [mailto:kent@bbn.com]
Sent: Tuesday, July = 16, 2013 11:56 AM
To: Michael Hammer
Cc: = br@brianrosen.net; philippe.fouquart@orange.com; = Henning.Schulzrinne@fcc.gov; hadriel.kaplan@oracle.com; = stir@ietf.org
Subject: Re: [stir] Rollout = timeframe

 

Mike,


Brian,<=
/pre>
 
1.  The DigiNotar problem =
points out two problems:  complexity of =
the
delegation and lack of oversight to the =
distributed processes.  It does not
say they =
lost faith in the mathematics of the certificates, since =
they
simply replaced the incompetent with other =
more competent administrators.
In fact, the =
delegation process seems to be source of the weakness of =
the
system.  So, may be good to learnt he =
right lessons there.
DigiNotar was =
a disaster largely because all of the TAs in the browser =

environment are able to issue certs for any DNS name. So, =
yes, the failure
to constrain the scope of "delegation" in =
that context is the really big problem.
Also, technology was =
commercially available for many years that would have =
allowed
DigiNotar to detect the covert issuance of certs and to allow =
them to revoke those
certs. DigiNotar just didn't make use of such =
technology.

 
2.&nbs=
p; Yes, there have to be processes for requesting an updated =
certificate
for a number, generating the =
certificate, distributing the certificate.
However, =
the distribution does not have to be tied to any hierarchy.  =
DNS
could do this via caching, but without the =
hierarchy complexity.  The reason
for updating =
a cert could be due to number portability, but the key =
trigger
is just knowing that it has ported and who =
the new SP is so that the private
key could be sent =
to the correct number-holder party.  We don't need all =
the
other complex routing trappings that NP already =
covers for routing, which is
not the issue =
here.
I'm not sure I agree with =
your notion of no need for a hierarchy. Numbering
plans appear to be =
administered in a hierarchic fashion  (said the telephony =
outsider),
and so aligning a PKI with that hierarchy would be a =
natural fit, one that would
counter the large scale failure that =
accompanied the DigiNotar security failure. 
DNSSEC and the RPKI are =
both examples where the certification system aligns with
an extant, =
hierarchic system.

Steve
------=_NextPart_001_00D9_01CE821D.B6E18AE0-- ------=_NextPart_000_00D8_01CE821D.B6E18AE0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NjE2MTIxN1owIwYJKoZIhvcNAQkEMRYEFDHxWq3x6vb4XyFYzqKiDwfF4q33MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAghyaCL86OoBuM1qZrbXuem4uFcAQsStPmNizBeYr DeEsE0opoAcID9XWnE/lwtokSeVnQC6k3xAThRNsKbAiKg8zfCNRBQtAMpwhWvtwlBV4mvcll5FJ MYViGZVpkaM9riMXG4i7YHZLgTIE/0rzJpTAyolingLupiO/akL+f7L1c/y8Gh/QTOvGvEmX+OSt lr1oSg6f68vo2zzKdmFWn27ZpvckMOthuC3r79RFUWbma8fYvWIGyFX5YI+TG3s9/PGL1wJgQhxY wDipy6ZGHrRL4vHYL7Q4bgL4HXfhSmJAv6t67JB/744gsgU5FzH/Ql5cxyvg1Z0nQFLEFEg5+AAA AAAAAA== ------=_NextPart_000_00D8_01CE821D.B6E18AE0-- From hadriel.kaplan@oracle.com Tue Jul 16 09:28: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 B088F11E80ED for ; Tue, 16 Jul 2013 09:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[AWL=-1.034, BAYES_00=-2.599, MANGLED_TOOL=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 T3oqknbKJbyZ for ; Tue, 16 Jul 2013 09:27:54 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 28C8521F9ED8 for ; Tue, 16 Jul 2013 09:27:54 -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 r6GGRmGW008487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Jul 2013 16:27: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 r6GGRlsN012043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 16:27:48 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6GGRkHA000837; Tue, 16 Jul 2013 16:27:47 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 16 Jul 2013 09:27: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: <00C069FD01E0324C9FFCADF539701DB3BBC17E02@EX2K10MB1.corp.yaanatech.com> Date: Tue, 16 Jul 2013 12:27:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <80F50A9C-852B-45C8-9637-83DB1A718888@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17E02@EX2K10MB1.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "philippe.fouquart@orange.com" , "dan-ietf@danyork.org" , "stir@ietf.org" , "br@brianrosen.net" Subject: [stir] Using the NPAC (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 16:28:00 -0000 On Jul 16, 2013, at 11:11 AM, Michael Hammer = wrote: > ++1 Administrative complexity counts. >=20 > But, let us leverage existing painfully wrought systems such as number > portability rather than reinvent them. I certainly see benefits to re-using the number portability systems for = this, BUT there are some issues that need to be addressed with that too: 1) Number portability doesn't work the same in all countries. The UK, = for example, has a very different number portability model I think. I = don't believe it even requires a central/common database admin, for = example (though I could be wrong on that). Furthermore, some countries = don't even have number portability. 2) Number portability never crosses country-codes - there's no = international number porting as far as I know. The NP database only = knows about numbers within their given country, and are only accessible = by their country's carriers. Even within +1 NANP, there is a different = number portability database and provider/admin for USA vs. Canada. So = to get international calls to work for STIR, the NP would have to tie = into others. I'm not saying that can't be made to work - it can - just = that it's not as simple as "use the NPAC". Someone would have to crate = specs for how the international thing would work, and vendors or NP = admins would have to implement it. 3) At least in the USA, the NP database is run by a company awarded the = contract by a federal agency. Same goes for Canada. That means the NP = admin is a monopoly. If we want them to handle the caller-id = verification data, but we don't want them to charge whatever they wish = to because they're in a monopoly position, it will have to be part of = the contract too and overseen by the federal agency. That will take a = long time, and involve a lot more people. 4) Today, the NP database is queried by the originator or transit = carrier, to route the call. It is not queried by the terminating = carrier when receiving a call. While this may not seem like a big deal, = it has implications on cost/pricing as well as for who can be the = verifier. Because in the USA at least, there are hundreds of "service = providers" who don't have access to the NP database and instead rely on = a downstream carrier to query it for routing their calls. That means = they would have to rely on their upstream carriers to do the = verification too. I think that's ok, but it's an extra constraint. 5) We'd still have to define one or more protocol means of accessing the = NP database. Today for NP database access it appears to be various = SS7-based and IP-based protocols, at different points/places. But we'd = have to at least define how it would work, and how the NP database would = know about stuff, to figure out what we need to transport in the SIP = signaling. -hadriel From michael.hammer@yaanatech.com Tue Jul 16 09:29:32 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C43221E8050 for ; Tue, 16 Jul 2013 09:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ex-tzy76n0c7 for ; Tue, 16 Jul 2013 09:29:14 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 9E57D11E80F6 for ; Tue, 16 Jul 2013 09:29: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; Tue, 16 Jul 2013 09:29:14 -0700 From: Michael Hammer To: "kent@bbn.com" Thread-Topic: [stir] Rollout timeframe Thread-Index: AQHOgjiLZosA/DKyMEuxDpDhXheKTZlnbarwgAB/eQD//40YsA== Date: Tue, 16 Jul 2013 16:29:13 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC17F8F@EX2K10MB1.corp.yaanatech.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <51E565A2.80806@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17EE8@EX2K10MB1.corp.yaanatech.com> <51E56EFE.5040106@bbn.com> In-Reply-To: <51E56EFE.5040106@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.87] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_00E0_01CE8220.140F3B70" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 16:29:33 -0000 ------=_NextPart_000_00E0_01CE8220.140F3B70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00E1_01CE8220.140F3B70" ------=_NextPart_001_00E1_01CE8220.140F3B70 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Inline. From: Stephen Kent [mailto:kent@bbn.com] Sent: Tuesday, July 16, 2013 12:04 PM To: Michael Hammer Cc: stir@ietf.org Subject: Re: [stir] Rollout timeframe Mike, Why? The cert path can be very short and orthogonal to the delegation path. it could be, but alignment makes the system simpler and easier to understand, and is supportive of the security principle of "least privilege". I disagree about simpler. The current system is my proof point. (But, we can leverage that.) Least privilege is about multiple levels (S, TS, TS/SCI etc.) of what the asserter has authority to assert or view. There is only one level of assertion that needs authority here. And the assertion must be universally readable. The authoritative cert signer can get the base cert passed up to it via secure means or it can create and sign the cert at the top. The only important aspect there is that the cert creator know definitively who to send the private key to. In the vast majority of PKIs, cert subjects do not send private keys to cert issuers , so I am confused by the statement above. I was not clear. When a certificate is created the public key is in the cert, while the associated private key is not. The public/private key pair creator needs to securely delivery the private key to the intended "owner" of the cert. In this case, the SP is that owner, most likely. But, it would not be hard to use a mechanism to secure the passing of the private key to the owner when that owner is remote. I was pointing to 2 possibilities, one is where the signing authority creates the public/private key pair, then structures the cert, signs it and then publicly distributes the cert, while securely passing the private key to the number holder. The second option is that the local SP generates the public/private key pair, then structures the cert, then only sends the proto-cert data to the signing authority to sign creating the signed cert. Those description are rough, but hopefully get the general idea across. Mike That does not need to be shared across the delegation path. Either way, the delegation path does not *need* to be in the cert. agreed, and in standard cert formats there is not way to represent the path anyway. Steve ------=_NextPart_001_00E1_01CE8220.140F3B70 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Inline.

 

From: Stephen Kent [mailto:kent@bbn.com]
Sent: Tuesday, July = 16, 2013 12:04 PM
To: Michael Hammer
Cc: = stir@ietf.org
Subject: Re: [stir] Rollout = timeframe

 

Mike,

Why? 

 

The cert path can be very short and orthogonal to the delegation = path.

it could be, but = alignment makes the system simpler and easier to understand,
and is = supportive of the security principle of "least = privilege".

 

I= disagree about simpler.  The current system is my proof = point.  (But, we can leverage that.)

L= east privilege is about multiple levels (S, TS, TS/SCI etc.) of what the = asserter has authority to assert or view. 

T= here is only one level of assertion that needs authority here. And the = assertion must be universally readable.

 

The authoritative cert signer can get the base cert passed up to it = via secure means or it can create and sign the cert at the = top.

The only important aspect there is that the cert creator know = definitively who to send the private key to.

In the vast majority of PKIs, cert subjects do not = send private keys to cert
issuers , so I am confused by the statement = above.

I= was not clear.  When a certificate is created the public key is in = the cert, while the associated private key is = not.

T= he public/private key pair creator needs to securely delivery the = private key to the intended “owner” of the cert.  =

I= n this case, the SP is that owner, most likely.

B= ut, it would not be hard to use a mechanism to secure the passing of the = private key to the owner when that owner is = remote.

<= o:p> 

I= was pointing to 2 possibilities,

o= ne is where the signing authority creates the public/private key pair, =

t= hen structures the cert, signs it and then publicly distributes the = cert,

w= hile securely passing the private key to the number = holder.

<= o:p> 

T= he second option is that the local SP generates the public/private key = pair, then structures the cert,

t= hen only sends the proto-cert data to the signing authority to sign = creating the signed cert.

<= o:p> 

T= hose description are rough, but hopefully get the general idea = across.

<= o:p> 

M= ike

 

That does not need to be shared across the delegation = path.

 

Either way, the delegation path does not *need* to be in the = cert.

agreed, and in standard = cert formats there is not way to represent the path = anyway.

Steve

------=_NextPart_001_00E1_01CE8220.140F3B70-- ------=_NextPart_000_00E0_01CE8220.140F3B70 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NjE2MjkxMlowIwYJKoZIhvcNAQkEMRYEFLiroham/bRsXyIrVehDpABZM2ybMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAVBg7QVp6zx/ENqzBgQgPPQnX1UM/DbdTliWe1Pqx qz32VAtnsVAyvyF4WrUkdtPUgoc/1Mkk5hX+qs3xOOU4pz8Fij2JpXEBjzaY+ZTJN/rZ5n77iFFy EVDaIlgZ/UZdjlpjn6S4om8NZhN0h44c70eTdeSLnaM+IzF8/B/wgkou7CmbdS1Q3koGWuRmtkdd h40JebRegm6HD76se8usDeHUum+qDb3dhUfhD9eWeF/+jXSNErrLsiZWcYTQ5Xj03WuNHmHOhdMM X+cPCntS5cTtz48HpTUK4Wr6VkH5ZHx/MT29d6/S8TA4USHLpEam3sC6I7y5uQciXWwl2hAGAwAA AAAAAA== ------=_NextPart_000_00E0_01CE8220.140F3B70-- From michael.hammer@yaanatech.com Tue Jul 16 09:33: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 E972521E808B for ; Tue, 16 Jul 2013 09:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GzVsL9UACna for ; Tue, 16 Jul 2013 09:33:00 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id BC31911E80E9 for ; Tue, 16 Jul 2013 09:33:00 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 16 Jul 2013 09:32:58 -0700 From: Michael Hammer To: "br@brianrosen.net" , "kent@bbn.com" Thread-Topic: [stir] Rollout timeframe Thread-Index: AQHOgjiLZosA/DKyMEuxDpDhXheKTZlnbarwgAB/eQCAAAIQgP//j+Sw Date: Tue, 16 Jul 2013 16:32:57 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC17FC3@EX2K10MB1.corp.yaanatech.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <51E565A2.80806@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17EE8@EX2K10MB1.corp.yaanatech.com> <51E56EFE.5040106@bbn.com> <30AC5063-E6F6-4230-98B0-3A52D8EF71CA@brianrosen.net> In-Reply-To: <30AC5063-E6F6-4230-98B0-3A52D8EF71CA@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.87] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_00F0_01CE8220.99A38D40" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 16:33:05 -0000 ------=_NextPart_000_00F0_01CE8220.99A38D40 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00F1_01CE8220.99A38D40" ------=_NextPart_001_00F1_01CE8220.99A38D40 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I would contend that you only need the current number holder and a central authority (or their CA) involved. How the number got there is irrelevant (orthogonal). Agree, the data volume and transaction speed is doable. Mike From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, July 16, 2013 12:12 PM To: Stephen Kent Cc: Michael Hammer; stir@ietf.org Subject: Re: [stir] Rollout timeframe I think the credential path follows the delegation path, but I hope that in most deployments, we're not chasing a chain of credentials to validate. Ultimately, remember the math Henning did - even with cert per TN, it's still not a whole lot of data. Brian On Jul 16, 2013, at 12:04 PM, Stephen Kent wrote: Mike, Why? The cert path can be very short and orthogonal to the delegation path. it could be, but alignment makes the system simpler and easier to understand, and is supportive of the security principle of "least privilege". The authoritative cert signer can get the base cert passed up to it via secure means or it can create and sign the cert at the top. The only important aspect there is that the cert creator know definitively who to send the private key to. In the vast majority of PKIs, cert subjects do not send private keys to cert issuers , so I am confused by the statement above. That does not need to be shared across the delegation path. Either way, the delegation path does not *need* to be in the cert. agreed, and in standard cert formats there is not way to represent the path anyway. Steve _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_001_00F1_01CE8220.99A38D40 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

I would contend that you only need the current number holder and a = central authority (or their CA) involved.

How the number got there is irrelevant = (orthogonal).

 

Agree, the data volume and transaction speed is = doable.

 

Mike

 

 

From: Brian Rosen [mailto:br@brianrosen.net]
Sent: Tuesday, = July 16, 2013 12:12 PM
To: Stephen Kent
Cc: Michael = Hammer; stir@ietf.org
Subject: Re: [stir] Rollout = timeframe

 

I think the = credential path follows the delegation path, but I hope that in most = deployments, we're not chasing a chain of credentials to = validate.

 

Ultimately, remember the math Henning did - even with = cert per TN, it's still not a whole lot of = data.

 

Brian

 

On Jul 16, 2013, at 12:04 PM, Stephen Kent <kent@bbn.com> = wrote:



Mike,

Why? 

 

The cert path can be very short and orthogonal to the delegation = path.

it could be, but alignment makes the system = simpler and easier to understand,
and is supportive of the security = principle of "least = privilege".

The authoritative cert signer can get the base cert passed up to it = via secure means or it can create and sign the cert at the = top.

The only important aspect there is that the cert creator know = definitively who to send the private key to.

In the vast majority = of PKIs, cert subjects do not send private keys to cert
issuers , so = I am confused by the statement above.

That does not need to be shared across the delegation = path.

 

Either way, the delegation path does not *need* to be in the = cert.

agreed, and in standard cert formats there is = not way to represent the path = anyway.

Steve

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

 

------=_NextPart_001_00F1_01CE8220.99A38D40-- ------=_NextPart_000_00F0_01CE8220.99A38D40 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NjE2MzI1NlowIwYJKoZIhvcNAQkEMRYEFN2udwbGAwZMwhGRYyo0D34f76ODMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAgCVs7i9HQ3woAwc4BPiDTeicevI/FYXXeQT42yd8 6JZEgDItaYYnFO/EQTrBFpk70xy6CJ2Imsu1mK751T5OmNvfmhS7tYm9/rS4B/KF4wrtiujdVNd/ YptL2tB/aYsm0cp6AWSzkYT15Ja5E1dJ5phf1yxJ4hw8YDrClsspCO/Wz0KeZ6Z/3/7bhiRlEyun tBo8DFjHSrL8cLRginhezDeU9YGloLEhfYRJYtQrKo2xEfNRJTj95o49D+Vve8aR38d2/P7myufc dRz3C9RtYW41kDALGfnwWF8W0DC3mppt9jS5dXNPyEI0PHxljZI197T710s8cT59c3BsYPSeFQAA AAAAAA== ------=_NextPart_000_00F0_01CE8220.99A38D40-- From jon.peterson@neustar.biz Tue Jul 16 09:39: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 AC16E21F9ED4 for ; Tue, 16 Jul 2013 09:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.165 X-Spam-Level: X-Spam-Status: No, score=-105.165 tagged_above=-999 required=5 tests=[AWL=-0.866, BAYES_00=-2.599, MANGLED_TOOL=2.3, 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 nYxHK7iuHlrc for ; Tue, 16 Jul 2013 09:39:20 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 9861E21F9BF7 for ; Tue, 16 Jul 2013 09:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1373992666; x=1689347373; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=bKk22Guiqz AFbZwkL3xY2WpI/5rPJhV2ILAFMW0/nOo=; b=NIYXcW2HjrbC3m5WIqsln/0thu VJyNIYaJuqFMFQwZ77viXSXnjIXeQA6WoGfv5uM725HcZbtLSyiZxhD+QtEQ== Received: from ([10.31.58.70]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.20973940; Tue, 16 Jul 2013 12:37:45 -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, 16 Jul 2013 12:39:10 -0400 From: "Peterson, Jon" To: Hadriel Kaplan , Michael Hammer Thread-Topic: [stir] Using the NPAC (was: Re: Rollout timeframe) Thread-Index: AQHOgkF2Fmxbiza5Xk+YvM/oP2n3NplnTy2A Date: Tue, 16 Jul 2013 16:39:09 +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: mmQUt9NuYVN6/PMC5KhVwg== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "philippe.fouquart@orange.com" , "dan-ietf@danyork.org" , "br@brianrosen.net" , "stir@ietf.org" Subject: Re: [stir] Using the NPAC (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 16:39:24 -0000 Though for obvious reasons my comments on this won't be too extensive, I will repeat what I've said before: that the IETF shouldn't be designating trust anchors for this solution. We should be defining protocols and interfaces that will work with the trust anchors that the industry adopts. Those protocols and interfaces should assume a trust model that supports delegation, while being wary of the sort of pluralism that has caused ambiguity about authority for domain names certs in the past. Jon Peterson Neustar, Inc. On 7/16/13 9:27 AM, "Hadriel Kaplan" wrote: > >On Jul 16, 2013, at 11:11 AM, Michael Hammer > wrote: > >> ++1 Administrative complexity counts. >>=20 >> But, let us leverage existing painfully wrought systems such as number >> portability rather than reinvent them. > >I certainly see benefits to re-using the number portability systems for >this, BUT there are some issues that need to be addressed with that too: >1) Number portability doesn't work the same in all countries. The UK, >for example, has a very different number portability model I think. I >don't believe it even requires a central/common database admin, for >example (though I could be wrong on that). Furthermore, some countries >don't even have number portability. > >2) Number portability never crosses country-codes - there's no >international number porting as far as I know. The NP database only >knows about numbers within their given country, and are only accessible >by their country's carriers. Even within +1 NANP, there is a different >number portability database and provider/admin for USA vs. Canada. So to >get international calls to work for STIR, the NP would have to tie into >others. I'm not saying that can't be made to work - it can - just that >it's not as simple as "use the NPAC". Someone would have to crate specs >for how the international thing would work, and vendors or NP admins >would have to implement it. > >3) At least in the USA, the NP database is run by a company awarded the >contract by a federal agency. Same goes for Canada. That means the NP >admin is a monopoly. If we want them to handle the caller-id verification >data, but we don't want them to charge whatever they wish to because >they're in a monopoly position, it will have to be part of the contract >too and overseen by the federal agency. That will take a long time, and >involve a lot more people. > >4) Today, the NP database is queried by the originator or transit >carrier, to route the call. It is not queried by the terminating carrier >when receiving a call. While this may not seem like a big deal, it has >implications on cost/pricing as well as for who can be the verifier. >Because in the USA at least, there are hundreds of "service providers" >who don't have access to the NP database and instead rely on a downstream >carrier to query it for routing their calls. That means they would have >to rely on their upstream carriers to do the verification too. I think >that's ok, but it's an extra constraint. > >5) We'd still have to define one or more protocol means of accessing the >NP database. Today for NP database access it appears to be various >SS7-based and IP-based protocols, at different points/places. But we'd >have to at least define how it would work, and how the NP database would >know about stuff, to figure out what we need to transport in the SIP >signaling. > >-hadriel > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From kent@bbn.com Tue Jul 16 09:43: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 5A83521E8083 for ; Tue, 16 Jul 2013 09:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UA5QBpJxpV-I for ; Tue, 16 Jul 2013 09:42:59 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1D07D1F0D3B for ; Tue, 16 Jul 2013 09:42:59 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:55917) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Uz8L4-000HrJ-4g; Tue, 16 Jul 2013 12:42:58 -0400 Message-ID: <51E57813.3070601@bbn.com> Date: Tue, 16 Jul 2013 12:42:59 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Michael Hammer References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> Content-Type: multipart/alternative; boundary="------------030807070106070207000900" Cc: "stir@ietf.org" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 16:43:15 -0000 This is a multi-part message in MIME format. --------------030807070106070207000900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mike, > Steve, > > I am not saying that the existing delegation system cannot be > leveraged, just don't co-mingle the administrative with the operational. > > There are a lot of privacy concerns identified by SPs about revealing > what numbers they are assigned. > > By not co-mingling, you can avoid those concerns, and thus freely > distribute certs. > "freely distributing" certs ought not be the primary focus for a system that purports to provide a security service :-) . Ensuring that the certs are appropriately bound to the data that they purport to certify, and that the certs are issued to the right entities, ought to be the primary concerns. > > As long as the PKI has a secure automated means by which they can > verify that an SP has "ownership" of the number for which they request > a cert, > > there is no reason a cert could not be signed for them or be issued > directly to them. > Anytime a third party is "trusted" to validate data supplied by a subject and issue a cert on that basis, we have a problem. That is why the browser PKI model is so badly broken. I hope you are not suggesting using it as a model. > > Every additional link you put into that validation chain is one more > possibility of failure. > > It's about minimizing failure with simple operation and strong oversight. > I probably disagree, on both counts. Additional nodes in a cert path, if constrained via technical means, do not necessarily create additional security concerns. "Strong oversight" is not a substitute for using authoritative CAs. Again, a lesson to be learned from the DigiNotar incident. (All TAs in browsers are supposed to be audited, but ...) Steve --------------030807070106070207000900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mike,

Steve,

 

I am not saying that the existing delegation system cannot be leveraged, just don’t co-mingle the administrative with the operational.

There are a lot of privacy concerns identified by SPs about revealing what numbers they are assigned.

By not co-mingling, you can avoid those concerns, and thus freely distribute certs.

"freely distributing" certs ought not be the primary focus for a system that
purports to provide a security service :-) . Ensuring that the certs are appropriately
bound to the data that they purport to certify, and that the certs are issued to
the right entities, ought to be the primary concerns.

 As long as the PKI has a secure automated means by which they can verify that an SP has “ownership” of the number for which they request a cert,

there is no reason a cert could not be signed for them or be issued directly to them.

Anytime a third party is "trusted" to validate data supplied by a subject and issue
a cert on that basis, we have a problem. That is why the browser PKI model is so
badly broken. I hope you are not suggesting using it as a model.

 Every additional link you put into that validation chain is one more possibility of failure.

It’s about minimizing failure with simple operation and strong oversight.

I probably disagree, on both counts. Additional nodes in a cert path, if constrained
via technical means, do not necessarily create additional security concerns.

"Strong oversight" is not a substitute for using authoritative CAs. Again, a lesson
to be learned from the DigiNotar incident. (All TAs in browsers are supposed to be
audited, but ...)

Steve

--------------030807070106070207000900-- From michael.hammer@yaanatech.com Tue Jul 16 09:50: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 66ABF11E80FB for ; Tue, 16 Jul 2013 09:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, MANGLED_TOOL=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 PFeojAlPV2Xy for ; Tue, 16 Jul 2013 09:50:26 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 410DF11E80F5 for ; Tue, 16 Jul 2013 09:50:26 -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, 16 Jul 2013 09:50:17 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" Thread-Topic: Using the NPAC (was: Re: [stir] Rollout timeframe) Thread-Index: AQHOgkFvvKpJrey8ZUSQRLfpcp4llZlngjpA Date: Tue, 16 Jul 2013 16:50:16 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC1803B@EX2K10MB1.corp.yaanatech.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <80F50A9C-852B-45C8-9637-83DB1A718888@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17E02@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.87] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0101_01CE8223.04E4C1D0" MIME-Version: 1.0 Cc: "philippe.fouquart@orange.com" , "dan-ietf@danyork.org" , "stir@ietf.org" , "br@brianrosen.net" Subject: Re: [stir] Using the NPAC (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 16:50:31 -0000 ------=_NextPart_000_0101_01CE8223.04E4C1D0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit You are missing my point. And I did say "such as" meaning by way of example, but not definitive. The called party needs to only be able to reach the freely available cached data that every SP would likely have. That could be in DNS. The validator trusts it because it can validate a cert, a common action today. Let us not confuse number holder validation with routing. The leveraging occurs when needing during the cert creation process. (the administrative part) And that would likely be between the national authority and the existing registries of who owns what number. I assume that the national authority has the power to get to that information, likely without charge, or maybe at cost as part of whatever contract they negotiated when they created that monopoly. That knowledge is needed solely to ensure that the private key is held by or given to the number holder. Mike -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Tuesday, July 16, 2013 12:28 PM To: Michael Hammer Cc: br@brianrosen.net; philippe.fouquart@orange.com; stir@ietf.org; dan-ietf@danyork.org Subject: Using the NPAC (was: Re: [stir] Rollout timeframe) On Jul 16, 2013, at 11:11 AM, Michael Hammer wrote: > ++1 Administrative complexity counts. > > But, let us leverage existing painfully wrought systems such as number > portability rather than reinvent them. I certainly see benefits to re-using the number portability systems for this, BUT there are some issues that need to be addressed with that too: 1) Number portability doesn't work the same in all countries. The UK, for example, has a very different number portability model I think. I don't believe it even requires a central/common database admin, for example (though I could be wrong on that). Furthermore, some countries don't even have number portability. 2) Number portability never crosses country-codes - there's no international number porting as far as I know. The NP database only knows about numbers within their given country, and are only accessible by their country's carriers. Even within +1 NANP, there is a different number portability database and provider/admin for USA vs. Canada. So to get international calls to work for STIR, the NP would have to tie into others. I'm not saying that can't be made to work - it can - just that it's not as simple as "use the NPAC". Someone would have to crate specs for how the international thing would work, and vendors or NP admins would have to implement it. 3) At least in the USA, the NP database is run by a company awarded the contract by a federal agency. Same goes for Canada. That means the NP admin is a monopoly. If we want them to handle the caller-id verification data, but we don't want them to charge whatever they wish to because they're in a monopoly position, it will have to be part of the contract too and overseen by the federal agency. That will take a long time, and involve a lot more people. 4) Today, the NP database is queried by the originator or transit carrier, to route the call. It is not queried by the terminating carrier when receiving a call. While this may not seem like a big deal, it has implications on cost/pricing as well as for who can be the verifier. Because in the USA at least, there are hundreds of "service providers" who don't have access to the NP database and instead rely on a downstream carrier to query it for routing their calls. That means they would have to rely on their upstream carriers to do the verification too. I think that's ok, but it's an extra constraint. 5) We'd still have to define one or more protocol means of accessing the NP database. Today for NP database access it appears to be various SS7-based and IP-based protocols, at different points/places. But we'd have to at least define how it would work, and how the NP database would know about stuff, to figure out what we need to transport in the SIP signaling. -hadriel ------=_NextPart_000_0101_01CE8223.04E4C1D0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NjE2NTAxNVowIwYJKoZIhvcNAQkEMRYEFCH+okTWw0FQHQCnpMvFL9zUh1TTMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAAEFwWsQYz1fUJM0JwYgH71GioAxLLJg/GRyz8P+4 CtrD490kE67b+1clpbAeU/bYyirsAR6WN9aJCFjh+9/ygS3xrWbYltP2yTwn6f2rUX+kVG1ipJw1 OKhbIP007GEGcs0Z5lRF+nUa/25fJ6nan1SZPjR8PF+E1u3XHXnQBY+IkVz+6NrMsUJSqlTzLxtm olxoi9zTeZhgfZxvMuQvDCDOORElOdgamrbo6xlPALl4ZeK7i+2mkH57EZ9GRal7xq+ah949tqn1 dVIh31aOGu11ilnPOWDrXSLdcDObRt+uIqLJPxZulwUtNi905fj1IO+8KPlwPzNSz3KnAFQzrwAA AAAAAA== ------=_NextPart_000_0101_01CE8223.04E4C1D0-- From hadriel.kaplan@oracle.com Tue Jul 16 09: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 24FFD21E8088 for ; Tue, 16 Jul 2013 09:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.462 X-Spam-Level: X-Spam-Status: No, score=-6.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDM9FkN1YaMb for ; Tue, 16 Jul 2013 09:52:14 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5D721E8050 for ; Tue, 16 Jul 2013 09:52:14 -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 r6GGqBnW031437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Jul 2013 16:52:12 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 r6GGqBQr013594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 16:52:11 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 r6GGqAcX013580; Tue, 16 Jul 2013 16:52:10 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 16 Jul 2013 09:52: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: Date: Tue, 16 Jul 2013 12:52:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2AF842E6-6B13-447E-993E-3EFCCE651518@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 Mail List" Subject: Re: [stir] Using the NPAC (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 16:52:22 -0000 On Jul 16, 2013, at 12:39 PM, "Peterson, Jon" = wrote: >=20 > Though for obvious reasons my comments on this won't be too extensive, = I > will repeat what I've said before: that the IETF shouldn't be = designating > trust anchors for this solution. We should be defining protocols and > interfaces that will work with the trust anchors that the industry = adopts. > Those protocols and interfaces should assume a trust model that = supports > delegation, while being wary of the sort of pluralism that has caused > ambiguity about authority for domain names certs in the past. We're not "designating" trust anchors. We're merely discussing how, in = practice, a STIR solution could be deployed and what its limitations or = issues would be. I think it only makes sense that such a discussion = happen, and email is hardly authoritative "designation" - I mean it's = not like we're planning an RFC to say "and the NPAC shall be used for = this". =20 I appreciate that you and Brian have to be careful in what you say on = this topic, but I don't see a way around that. We can't all be expected = to agree on a solution we believe will succeed, if we're creating one in = a vacuum with no idea how it would actually be used, administered, and = deployed. -hadriel From kent@bbn.com Tue Jul 16 09:53:06 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC25A21F9A3B for ; Tue, 16 Jul 2013 09:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jw7UEs07+4ur for ; Tue, 16 Jul 2013 09:53:00 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C5C7621F9A43 for ; Tue, 16 Jul 2013 09:52:59 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:55943) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Uz8Ue-000DWM-GJ; Tue, 16 Jul 2013 12:52:52 -0400 Message-ID: <51E57A65.6020303@bbn.com> Date: Tue, 16 Jul 2013 12:52:53 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Michael Hammer References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <51E565A2.80806@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17EE8@EX2K10MB1.corp.yaanatech.com> <51E56EFE.5040106@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F8F@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC17F8F@EX2K10MB1.corp.yaanatech.com> Content-Type: multipart/alternative; boundary="------------000204040203010301000303" Cc: "stir@ietf.org" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 16:53:06 -0000 This is a multi-part message in MIME format. --------------000204040203010301000303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mike, > Mike, > > Why? > > The cert path can be very short and orthogonal to the delegation path. > > it could be, but alignment makes the system simpler and easier to > understand, > and is supportive of the security principle of "least privilege". > > I disagree about simpler. The current system is my proof point. > (But, we can leverage that.) > > Least privilege is about multiple levels (S, TS, TS/SCI etc.) of what > the asserter has authority to assert or view. > > There is only one level of assertion that needs authority here. And > the assertion must be universally readable. > To which "current system" do you refer? Your response tells me that you are not familiar with the term "least privilege." See the definition of the term in the paper by Jerry Saltzer, ca 1975. The term refers to the notion that a system should be structured to limit the authority (and thus the amount of damage) associated with each system element, based on what the element requires to do its job. > The authoritative cert signer can get the base cert passed up to it > via secure means or it can create and sign the cert at the top. > > The only important aspect there is that the cert creator know > definitively who to send the private key to. > > In the vast majority of PKIs, cert subjects do not send private keys > to cert > issuers , so I am confused by the statement above. > > I was not clear. When a certificate is created the public key is in > the cert, while the associated private key is not. > > The public/private key pair creator needs to securely delivery the > private key to the intended "owner" of the cert. > Again, not usually the case. In the typical PKI context, the cert subject creates the key pair and transmits a cert request to a CA or RA. > > In this case, the SP is that owner, most likely. > > But, it would not be hard to use a mechanism to secure the passing of > the private key to the owner when that owner is remote. > yes, that can be done, and there are some significant systems that operate that way, but that approach creates additional security concerns. > > I was pointing to 2 possibilities, > > one is where the signing authority creates the public/private key pair, > > then structures the cert, signs it and then publicly distributes the > cert, > > while securely passing the private key to the number holder. > yes, but not the default model, and not a good idea in most cases. (It is used when the cert issuer wants to retain the private key for key escrow purposes, but that's not relevant here.) > > The second option is that the local SP generates the public/private > key pair, then structures the cert, > > then only sends the proto-cert data to the signing authority to sign > creating the signed cert. > that is the common model, which was not represented in your previous message. Steve --------------000204040203010301000303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mike,

 

Mike,

Why? 

 

The cert path can be very short and orthogonal to the delegation path.

it could be, but alignment makes the system simpler and easier to understand,
and is supportive of the security principle of "least privilege".

 

I disagree about simpler.  The current system is my proof point.  (But, we can leverage that.)

Least privilege is about multiple levels (S, TS, TS/SCI etc.) of what the asserter has authority to assert or view. 

There is only one level of assertion that needs authority here. And the assertion must be universally readable.

To which "current system" do you refer?

Your response tells me that you are not familiar with the term "least privilege." See
the definition of the term in the paper by Jerry Saltzer, ca 1975. The term refers to
the notion that a system should be structured to limit the authority (and thus the
amount of damage) associated with each system element, based on what the element requires
to do its job.

 The authoritative cert signer can get the base cert passed up to it via secure means or it can create and sign the cert at the top.

The only important aspect there is that the cert creator know definitively who to send the private key to.

In the vast majority of PKIs, cert subjects do not send private keys to cert
issuers , so I am confused by the statement above.

I was not clear.  When a certificate is created the public key is in the cert, while the associated private key is not.

The public/private key pair creator needs to securely delivery the private key to the intended “owner” of the cert. 

Again, not usually the case. In the typical PKI context, the cert subject creates the key pair
and transmits a cert request to a CA or RA.

In this case, the SP is that owner, most likely.

But, it would not be hard to use a mechanism to secure the passing of the private key to the owner when that owner is remote.

yes, that can be done, and there are some significant systems that operate that way, but
that approach creates additional security concerns.

 I was pointing to 2 possibilities,

one is where the signing authority creates the public/private key pair,

then structures the cert, signs it and then publicly distributes the cert,

while securely passing the private key to the number holder.

yes, but not the default model, and not a good idea in most cases. (It is used when the
cert issuer wants to retain the private key for key escrow purposes, but that's not
relevant here.)

 The second option is that the local SP generates the public/private key pair, then structures the cert,

then only sends the proto-cert data to the signing authority to sign creating the signed cert.

that is the common model, which was not represented in your previous message.

Steve
--------------000204040203010301000303-- From michael.hammer@yaanatech.com Tue Jul 16 10: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 AD2B011E80D7 for ; Tue, 16 Jul 2013 10:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+Ndhy19ln4w for ; Tue, 16 Jul 2013 10:03: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 A893D11E80F7 for ; Tue, 16 Jul 2013 10:03:40 -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, 16 Jul 2013 10:03:40 -0700 From: Michael Hammer To: "kent@bbn.com" Thread-Topic: [stir] Rollout timeframe Thread-Index: AQHOgj0MegkF68FLTUyBdNmNASSKrplnd8uggACAIoD//44WoA== Date: Tue, 16 Jul 2013 17:03:39 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> In-Reply-To: <51E57813.3070601@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.87] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0112_01CE8224.E36FC6B0" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 17:03:50 -0000 ------=_NextPart_000_0112_01CE8224.E36FC6B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0113_01CE8224.E36FC6B0" ------=_NextPart_001_0113_01CE8224.E36FC6B0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Steve, We can argue about whether freely distributable is valid or not, but do you disagree that some operators would not want the number delegation revealed? The number portability DB in US is a trusted third party. And you argue both sides, since any delegation from central authority is a third party, even an SP. You would argue that having many more of them makes it more secure? Experience also argues the more there are the harder to police. I see no difference in the DigiNotar case. That appeared to be an organizational failure. That breach could have occurred with an SP as easily. What "technical constraints" are you saying were not implemented? Keep in mind that we need a solution that works when there are on the order of thousands of operators, as there are in the U.S. Mike From: Stephen Kent [mailto:kent@bbn.com] Sent: Tuesday, July 16, 2013 12:43 PM To: Michael Hammer Cc: stir@ietf.org Subject: Re: [stir] Rollout timeframe Mike, Steve, I am not saying that the existing delegation system cannot be leveraged, just don't co-mingle the administrative with the operational. There are a lot of privacy concerns identified by SPs about revealing what numbers they are assigned. By not co-mingling, you can avoid those concerns, and thus freely distribute certs. "freely distributing" certs ought not be the primary focus for a system that purports to provide a security service :-) . Ensuring that the certs are appropriately bound to the data that they purport to certify, and that the certs are issued to the right entities, ought to be the primary concerns. As long as the PKI has a secure automated means by which they can verify that an SP has "ownership" of the number for which they request a cert, there is no reason a cert could not be signed for them or be issued directly to them. Anytime a third party is "trusted" to validate data supplied by a subject and issue a cert on that basis, we have a problem. That is why the browser PKI model is so badly broken. I hope you are not suggesting using it as a model. Every additional link you put into that validation chain is one more possibility of failure. It's about minimizing failure with simple operation and strong oversight. I probably disagree, on both counts. Additional nodes in a cert path, if constrained via technical means, do not necessarily create additional security concerns. "Strong oversight" is not a substitute for using authoritative CAs. Again, a lesson to be learned from the DigiNotar incident. (All TAs in browsers are supposed to be audited, but ...) Steve ------=_NextPart_001_0113_01CE8224.E36FC6B0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Steve,

 

We can argue about whether freely distributable is valid or not, =

but do you disagree that some operators would not want the number = delegation revealed?

 

The number portability DB in US is a trusted third = party.

And you argue both sides, since any delegation from central authority = is a third party, even an SP.

You would argue that having many more of them makes it more = secure?

Experience also argues the more there are the harder to = police.

 

I see no difference in the DigiNotar case.  That appeared to be = an organizational failure.

That breach could have occurred with an SP as = easily.

What “technical constraints” are you saying were not = implemented?

 

Keep in mind that we need a solution that works when there are on the = order of thousands of operators, as there are in the = U.S.

 

Mike

 

 

From: Stephen Kent [mailto:kent@bbn.com]
Sent: Tuesday, July = 16, 2013 12:43 PM
To: Michael Hammer
Cc: = stir@ietf.org
Subject: Re: [stir] Rollout = timeframe

 

Mike,

 

Steve,

 

I am not saying that the existing delegation system cannot be = leveraged, just don’t co-mingle the administrative with the = operational.

There are a lot of privacy concerns identified by SPs about revealing = what numbers they are assigned.

By not co-mingling, you can avoid those concerns, and thus freely = distribute certs.

"freely distributing" certs ought not be the = primary focus for a system that
purports to provide a security = service :-) . Ensuring that the certs = are appropriately
bound to the data that they purport to certify, and = that the certs are issued to
the right entities, ought to be the = primary concerns.

 As long as the PKI has a secure automated means by which they = can verify that an SP has “ownership” of the number for = which they request a cert,

there is no reason a cert could not be signed for them or be issued = directly to them.

Anytime a = third party is "trusted" to validate data supplied by a = subject and issue
a cert on that basis, we have a problem. That is = why the browser PKI model is so
badly broken. I hope you are not = suggesting using it as a model.

 Every additional link you put into that validation chain is one = more possibility of failure.

It’s about minimizing failure with simple operation and strong = oversight.

I probably disagree, on both counts. = Additional nodes in a cert path, if constrained
via technical means, = do not necessarily create additional security = concerns.

"Strong oversight" is not a substitute for = using authoritative CAs. Again, a lesson
to be learned from the = DigiNotar incident. (All TAs in browsers are supposed to be
audited, = but ...)

Steve

------=_NextPart_001_0113_01CE8224.E36FC6B0-- ------=_NextPart_000_0112_01CE8224.E36FC6B0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NjE3MDMzOFowIwYJKoZIhvcNAQkEMRYEFBI4jrliONGq3D0n9xHVmYm5PV7UMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEATgstVVYObxD2Gp07DnXcTq3AGrAqJOiOotJc9j5t iMvnJABYMAzHZOOnYMPtajzg5sP+bjFhD5V9oa84YuWEE2Z3KSec0G/v4YsSqddDyoDr/cGCzuHx aRMbh8Av1//fXL0cWwDT4kCFWWINgEb//kf7VsQO5TPV7FJDezlDMUklAl4YyNLYDbUyrps4ymv5 ZQQuJy7tbU7oDR3WHLKn9P5tYVXiNglE5BXSTgoxInfVZ5+Umvr9NWxkQBHh0R77s4brWW2/X6vZ HQUieySpNhKAYhXot+HrJAqZEv+Kwd0rv6htU9JFBAorKUcgaWk0lCwiVQ33UjCSs3Te9Uev0gAA AAAAAA== ------=_NextPart_000_0112_01CE8224.E36FC6B0-- From hadriel.kaplan@oracle.com Tue Jul 16 10:26: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 538DA11E80D7 for ; Tue, 16 Jul 2013 10:26:22 -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 SZNiNavAAmyY for ; Tue, 16 Jul 2013 10:26:15 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id CFBE911E80DF for ; Tue, 16 Jul 2013 10:26:15 -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 r6GHQ62x004580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Jul 2013 17:26:06 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 r6GHQ4lY006381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 17:26:04 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6GHQ4gj006375; Tue, 16 Jul 2013 17:26:04 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 16 Jul 2013 10:26: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: <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> Date: Tue, 16 Jul 2013 13:26:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@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" , "kent@bbn.com" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 17:26:22 -0000 On Jul 16, 2013, at 1:03 PM, Michael Hammer = wrote: > We can argue about whether freely distributable is valid or not, > but do you disagree that some operators would not want the number = delegation revealed? There is no debate that some operators would not want their numbers = revealed publicly. They're ok with you learning they're the operator = when you a receive a call from them, but they'd not be ok with a = script-kiddie being able to learn every phone number they have. I can think of a reason why it would be a problem: if everyone could = learn how many numbers an operator has, people could figure out how many = subscribers an operator has gained/lost in a time period. You can game = the stock market using that type of information. -hadriel From michael.hammer@yaanatech.com Tue Jul 16 10:41: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 C114011E80DF for ; Tue, 16 Jul 2013 10:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3qD5I6lVSWy for ; Tue, 16 Jul 2013 10:41: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 EE81F21E8063 for ; Tue, 16 Jul 2013 10:41: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; Tue, 16 Jul 2013 10:40:53 -0700 From: Michael Hammer To: "kent@bbn.com" Thread-Topic: [stir] Rollout timeframe Thread-Index: AQHOgjiLZosA/DKyMEuxDpDhXheKTZlnbarwgAB/eQD//40YsIAAgH+A//+PSyA= Date: Tue, 16 Jul 2013 17:40:52 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC180B8@EX2K10MB1.corp.yaanatech.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <51E565A2.80806@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17EE8@EX2K10MB1.corp.yaanatech.com> <51E56EFE.5040106@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F8F@EX2K10MB1.corp.yaanatech.com> <51E57A65.6020303@bbn.com> In-Reply-To: <51E57A65.6020303@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.87] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_011A_01CE822A.165CF070" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 17:41:13 -0000 ------=_NextPart_000_011A_01CE822A.165CF070 Content-Type: multipart/alternative; boundary="----=_NextPart_001_011B_01CE822A.165CF070" ------=_NextPart_001_011B_01CE822A.165CF070 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Inline. From: Stephen Kent [mailto:kent@bbn.com] Sent: Tuesday, July 16, 2013 12:53 PM To: Michael Hammer Cc: stir@ietf.org Subject: Re: [stir] Rollout timeframe Mike, Mike, Why? The cert path can be very short and orthogonal to the delegation path. it could be, but alignment makes the system simpler and easier to understand, and is supportive of the security principle of "least privilege". I disagree about simpler. The current system is my proof point. (But, we can leverage that.) Least privilege is about multiple levels (S, TS, TS/SCI etc.) of what the asserter has authority to assert or view. There is only one level of assertion that needs authority here. And the assertion must be universally readable. To which "current system" do you refer? The fact that there are multiple again proves my point. Ask yourself how anyone knows who the current number belongs to and then tell me if that is simple or not. I think we both agree it should be simple, but differ only in whether following existing regimes is simpler or not. Your response tells me that you are not familiar with the term "least privilege." See the definition of the term in the paper by Jerry Saltzer, ca 1975. The term refers to the notion that a system should be structured to limit the authority (and thus the amount of damage) associated with each system element, based on what the element requires to do its job. I may be confusing my terms, but when the authority is distributed across more entities, how is that least privilege? You have given more actors control not fewer? Yes, each actor theoretically controls less data, but how is that enforced? You have only squeezed the balloon and created a bigger auditing problem elsewhere. I was thinking of limiting the authority to the least number of entities necessary to accomplish the function. Or, in your terms "limiting the authority associated with each system element based on what the element requires to do its job." It is the job of the "national authority element" and does not need to be shared more than necessary. The authoritative cert signer can get the base cert passed up to it via secure means or it can create and sign the cert at the top. The only important aspect there is that the cert creator know definitively who to send the private key to. In the vast majority of PKIs, cert subjects do not send private keys to cert issuers , so I am confused by the statement above. I was not clear. When a certificate is created the public key is in the cert, while the associated private key is not. The public/private key pair creator needs to securely delivery the private key to the intended "owner" of the cert. Again, not usually the case. In the typical PKI context, the cert subject creates the key pair and transmits a cert request to a CA or RA. In this case, the SP is that owner, most likely. But, it would not be hard to use a mechanism to secure the passing of the private key to the owner when that owner is remote. yes, that can be done, and there are some significant systems that operate that way, but that approach creates additional security concerns. I was pointing to 2 possibilities, one is where the signing authority creates the public/private key pair, then structures the cert, signs it and then publicly distributes the cert, while securely passing the private key to the number holder. yes, but not the default model, and not a good idea in most cases. (It is used when the cert issuer wants to retain the private key for key escrow purposes, but that's not relevant here.) The second option is that the local SP generates the public/private key pair, then structures the cert, then only sends the proto-cert data to the signing authority to sign creating the signed cert. that is the common model, which was not represented in your previous message. Steve With cryptography, one needs to get down to specific mathematically notations to fully specify. I was just trying to outline the general ideas across. Obviously more precise wording was needed. But I hope the idea that limiting the process to 2 actors who can authenticate each other, and relying on strong certificates rather than chains of organizations and networks could lead to better security and privacy. Mike ------=_NextPart_001_011B_01CE822A.165CF070 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Inline.

 

From: Stephen Kent [mailto:kent@bbn.com]
Sent: Tuesday, July = 16, 2013 12:53 PM
To: Michael Hammer
Cc: = stir@ietf.org
Subject: Re: [stir] Rollout = timeframe

 

Mike,

 

 

Mike,


Why? 

 

The cert path can be very short and orthogonal to the delegation = path.

it could be, but = alignment makes the system simpler and easier to understand,
and is = supportive of the security principle of "least = privilege".

 

I= disagree about simpler.  The current system is my proof = point.  (But, we can leverage that.)

L= east privilege is about multiple levels (S, TS, TS/SCI etc.) of what the = asserter has authority to assert or view. 

T= here is only one level of assertion that needs authority here. And the = assertion must be universally = readable.

To = which "current system" do you refer?

 

The fact that there are multiple again proves my point.  =

Ask yourself how anyone knows who the current number belongs to and = then tell me if that is simple or not.

I think we both agree it should be simple, but differ only in whether = following existing regimes is simpler or = not.

 


Your response = tells me that you are not familiar with the term "least = privilege." See
the definition of the term in the paper by Jerry = Saltzer, ca 1975. The term refers to
the notion that a system should = be structured to limit the authority (and thus the
amount of damage) = associated with each system element, based on what the element = requires
to do its job.

I may be confusing my terms, but when the authority is distributed = across more entities, how is that least = privilege?

You have given more actors control not fewer?  Yes, each actor = theoretically controls less data, but how is that = enforced?

You have only squeezed the balloon and created a bigger auditing = problem elsewhere.

I was thinking of limiting the authority to the least number of = entities necessary to accomplish the = function.

Or, in your terms “limiting the authority associated with each = system element based on  what the element requires to do its = job.”

It is the job of the “national authority element” and = does not need to be shared more than = necessary.

 

 

The authoritative cert signer can get the base cert passed up to it = via secure means or it can create and sign the cert at the = top.

The only important aspect there is that the cert creator know = definitively who to send the private key to.

In the vast majority of PKIs, cert subjects do not = send private keys to cert
issuers , so I am confused by the statement = above.


I= was not clear.  When a certificate is created the public key is in = the cert, while the associated private key is = not.

T= he public/private key pair creator needs to securely delivery the = private key to the intended “owner” of the cert.  =

Again, not usually the case. = In the typical PKI context, the cert subject creates the key pair
and = transmits a cert request to a CA or RA.

I= n this case, the SP is that owner, most likely.

B= ut, it would not be hard to use a mechanism to secure the passing of the = private key to the owner when that owner is = remote.

yes, that can be done, = and there are some significant systems that operate that way, = but
that approach creates additional security = concerns.

&= nbsp;I was pointing to 2 possibilities,

o= ne is where the signing authority creates the public/private key pair, =

t= hen structures the cert, signs it and then publicly distributes the = cert,

w= hile securely passing the private key to the number = holder.

yes, but not the = default model, and not a good idea in most cases. (It is used when = the
cert issuer wants to retain the private key for key escrow = purposes, but that's not
relevant here.)

&= nbsp;The second option is that the local SP generates the public/private = key pair, then structures the cert,

t= hen only sends the proto-cert data to the signing authority to sign = creating the signed cert.

that = is the common model, which was not represented in your previous = message.

Steve

 

With cryptography, one needs to get down to specific mathematically = notations to fully specify.

I was just trying to outline the general ideas across.  = Obviously more precise wording was needed.

But I hope the idea that limiting the process to 2 actors who can = authenticate each other,

and relying on strong certificates rather than chains of = organizations and networks could lead

to better security and privacy.

 

Mike

 

 

------=_NextPart_001_011B_01CE822A.165CF070-- ------=_NextPart_000_011A_01CE822A.165CF070 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NjE3NDA1MVowIwYJKoZIhvcNAQkEMRYEFE4qLGmmRKp5CPyWtVOC6XcFNtv3MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAX1M4of7Y3isyUDdJlJW6weO9kumOPI2Wfbmh43KA +ayQ3YUb1RF/3hfgaEuW9VfRSEtm2FahrjnLVfC6l8lx2Q60vDsoPgVkinMvWP63hAVM9yGv1Be2 sm4oQumDA7cPpv5ZSakblYwQeGxHp0Gz1cFAZoPjwzyYFKJrt0fS9P49cQmfQydY/9STIiaPt4uB j98hLiV4dhPeqrz15V4/UhFA0lFk8/mUhtgMy9P+ItiN+Xxw3f5GNpxCNyWXSmXfNWy9Cp2Il/8D YxbPAn62F3YqwdVWrr+w6ptMtLHIbnE3z4yLmghuRK9VCZ8pdkSj44HdhxBmHLcZDRrjnkxYIQAA AAAAAA== ------=_NextPart_000_011A_01CE822A.165CF070-- From hadriel.kaplan@oracle.com Tue Jul 16 10:57: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 CA23A21F8FD5 for ; Tue, 16 Jul 2013 10:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.467 X-Spam-Level: X-Spam-Status: No, score=-6.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9M0TxZzNc5n for ; Tue, 16 Jul 2013 10:57:24 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9D44C21E8054 for ; Tue, 16 Jul 2013 10:57:20 -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 r6GHvFqB005305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Jul 2013 17:57:16 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 r6GHvFhk027511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 17:57:15 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 r6GHvEDK015469; Tue, 16 Jul 2013 17:57:14 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 16 Jul 2013 10:57:14 -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: <51E56D2C.2010700@bbn.com> Date: Tue, 16 Jul 2013 13:57:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "stir@ietf.org Mail List" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 17:57:30 -0000 On Jul 16, 2013, at 11:56 AM, Stephen Kent wrote: > I'm not sure I agree with your notion of no need for a hierarchy. = Numbering > plans appear to be administered in a hierarchic fashion (said the = telephony outsider), > and so aligning a PKI with that hierarchy would be a natural fit, one = that would > counter the large scale failure that accompanied the DigiNotar = security failure.=20 > DNSSEC and the RPKI are both examples where the certification system = aligns with > an extant, hierarchic system. Numbering administration doesn't necessarily align with a clean = hierarchy for all countries, depending on how you mean that. The = country-code number portion itself does, and in the North American = Numbering Plan (NANP) the area-code level does but only with regard to = defining which nation has that whole area-code of numbers. In other = words, all numbers within an area-code belong to the USA, vs. another = area-code to Canada, vs. Jamaica, etc. But within that area-code's tree = branches, any specific full number can belong to a different carrier. = For example, the entire +1-603 area-code is a USA NANPA-based one, but = +1-603-555-1000 can belong to AT&T, while +1-603-555-1001 can be VZ, and = +1-603-555-1002 can be Comcast, etc. They're initially allocated as = blocks (of 1000 numbers I think), but once numbers are ported out they = become fragmented. So if you did this thing with actual certificates, it would be tricky. = Having an authoritative root CA for each country-code wouldn't be too = hard, but below that you'd have to define an encoding schema for = indicating a range-list of E.164 numbers a cert is good for, and then = revoke the cert and replace once a number gets ported.[1] Or you'd have = a separate cert for each E.164 number. Either way, the cert signing = process has to be automated/automatable, because numbers get ported and = the new assignee has to be able to claim that ported number in ~15 = minutes or so. The CIDER proposal avoids certificates, and just uses DNS instead. For = SIP email-style names it would be nearly identical to DKIM. For E.164 = numbers it uses a DNS anchor for each country-code, but leaves it up to = each country to decide how actual DNS delegation works. The important = aspect is it separates the DNS zone delegation from the E.164 number = delegation. Basically, the DNS admin decides who can populate the = public-keys in the DNS nodes representing the E.164 numbers, and gives = them provisioning access to do so, but the DNS admin is authoritative = for the node in DNS. In other words, when a carrier is assigned an = E.164 number, they're given access rights to populate the public-key for = that number in the DNS admin's database, but they're not delegated the = DNS node itself and are not authoritative for it. But of course if the = DNS admin wants to delegate it to them, they can (it's still DNS after = all). The ability to not do so is useful, though, to hide who the = carrier is and to let it be centrally managed if one so wishes. -hadriel [1] One could argue true cert revocation isn't necessary for numbers = being ported out, as we could just accept that the cert holder for a = ported-out number could illegitimately claim the number until that cert = times out. =46rom a practical threat perspective, that's not a big = weakness. (you'd still have revocation for the other usual reasons of = course - but for number porting situations it wouldn't be necessary to = revoke) From jon.peterson@neustar.biz Tue Jul 16 11:12: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 AAE9821F9DCF for ; Tue, 16 Jul 2013 11:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.258 X-Spam-Level: X-Spam-Status: No, score=-106.258 tagged_above=-999 required=5 tests=[AWL=0.341, 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 zM6c2nmfh81A for ; Tue, 16 Jul 2013 11:12:53 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACD221F9343 for ; Tue, 16 Jul 2013 11:12:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1373998336; x=1689357019; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=PBP7aMSQgX NC82fudwbucjJVv8ZWvYWk+vHsiPygKqs=; b=Pyj+NgUnCfaRk0e3kr1sdKixCX H1nOuUIwiOmFhrOlS+7TgcLdrhE4EYE1Iwr+KYnas87xAgdteFFKAtiP1+wg== Received: from ([10.31.58.71]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.22440860; Tue, 16 Jul 2013 14:12:15 -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, 16 Jul 2013 14:12:45 -0400 From: "Peterson, Jon" To: "dcrocker@bbiw.net" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkICx1fsldqNdEa1H4oCYTQLxplgBgeAgAAEgQCAAANuAIAAAaEAgAAGyYCAAAH6AIAABkaAgAACpAD//5iRAIAAd2uAgADroICAAEL+gIAAAeAAgABhRQCAAB8HgIAADPaAgAAKzoCAAzU2gIAADMkA//+reQCAAHxoAIAAxXwAgADeGgCAAGoOgA== Date: Tue, 16 Jul 2013 18:12:45 +0000 Message-ID: In-Reply-To: <51E4D1B4.4060504@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: pn+O/Y231cyNQthNWuSTgg== Content-Type: text/plain; charset="us-ascii" Content-ID: <90495371BD87DE4B8722DAA142835C0D@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF STIR Mail List Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 18:12:57 -0000 >> For the two approaches to be "fully redundant," there >> would be no case you could use one where you couldn't use the other, and >> no use of one that the other couldn't also fulfill. > >Since you say arguing is of little value, it's odd that you then went on >to impose a definition that significantly conflicts with the >characterization I provided repeatedly: The caller creates the >authentication information for every call, using both mechanisms. I saw little value in arguing over the meaning of "fully redundant," but some value in us getting a mutual understanding of how STIR should work. The characterization you provided repeatedly doesn't capture the model I have given, anyway. Start by dividing your "caller" into a set of network devices that may act on a caller's behalf. Some might be end-user terminals, some network intermediaries. In some cases, neither the terminal nor any intermediary creates any form of authentication information. In some cases only one does. In some cases, both do. In some cases, one entity creates two forms of authentication information itself. We could do the same exercise for the terminating side, splitting it into various entities that sometimes support these mechanisms or don't. Then at the end of the line, there is an end-to-end case where one calling entity creates two forms of authentication information itself, and one terminating entity has the capability to verify both forms of authentication information. You sometimes seem to have latched on to this last case and treated it as if this were the only case in which the proposed STIR mechanisms operate. Were that true, I would find a concern about redundancy more compelling. But it is in fact all of the other cases that motivate having both an in-band and out-of-band approach to STIR. [snip] >>> >>> There's a nice term for such an approach and, I might add, quite a bit >>> of experience with its applicability. The term is "non-interoperable'. >> >> Well, sometimes, DKIM gets used. And sometimes PGP gets used. > >Jon, seriously? You're invoking that one again? > >One of the hallmarks of constructive exchange is that both sides must >pay attention to what the other says and must incorporate it into >following responses. This permits some degree of incremental progress. > >Instead, here you seem to have entirely missed the response I offered >when you earlier attempted to call DKIM and PGP 'redundant'. I didn't miss it, though I must admit I wasn't entirely persuaded by it. I think the situations are analogous enough here that this applies. And I didn't raise this point to highlight that DKIM and PGP were redundant, merely that their simultaneous use did not (as far as I could tell) lead to some sort of interoperability failure. That's the point of yours I was replying to above. >Since repetition seems to be the hallmark of today's mailing list >activity: they are entirely different mechanisms, in terms of syntax and >semantics. In other words: they have nothing to do with each other. Again, I think this is a bit too strong of a claim. >So whatever you intended to demonstrate by the DKIM/PGP reference, >again, the reality is that it's irrelevant to the current discussion. I intended that to demonstrate that when they get used together, it doesn't cause an interoperability failure. >> The entities >> that use DKIM and the entities that use PGP aren't really the same. They >> don't coordinate. I'm sure it happens that sometimes both are used >> simultaneously. The interoperability failure there isn't apparent to me. > >And this seems to continue the irrelevancy to somehow claim that it >shouldn't be classed as an interoperability failure and this somehow is >responsive to my own reference? That was the original point above, actually. The sentences are meant to go together. >So let's be clear: interoperability failure means that two (or more) >entities that are seeking to interoperate using the same protocols fail >to do so. Sounds reasonable. >My previous reference to non-interoperability was pointing out that the >caller and callee are seeking to validate the Caller-ID value and that >having the usage mixture of mechanisms that you described is likely to >lead to one of them using one mechanism and the other use a different >one, thereby ensuring that they fail to achieve the validation they both >wanted. So you're worried about a case where the originating side uses only in-band, say, and the terminating side supports only out-of-band? A bit of dissonance for me, since above you seem to insist that I propose the caller must use both in-band and out-of-band for every call, in which case this could never arise. But no, you're quite correct here that there is a possible case where the calling side uses only one of the two mechanisms, and the terminating side has no entities that support that mechanism. Just like there's a possible case where I send an INVITE with one codec (or multipart body, if that floats your boat) and the terminating side doesn't support it. These cases arise because there are environments that are more conducive to one codec, or to one STIR mechanism, than others. As this incrementally rolls out, there will be some calls placed from black phones, say, that will never support out-of-band. There will also be some smart phones that can support out-of-band which are attached to networks that won't support in-band for the foreseeable future. It's not an ideal situation, don't get me wrong. It'd be better if one size fit all. But it's this assessment of the deployment realities that lead us to propose a two-prong approached to STIR. We further believed that, if, out of necessity, we were going to design two approaches, that we should design them in concert and try to reuse as many components as we could between them. >>>> What I have said in the past that may have confused you is that I >>>> envisioned that an authentication service (i.e., the originating side) >>>> that supported both in-band and out-of-band should ideally use both, >>> >>> And you don't think that makes it fully redundant for the caller? (And >>> fully redundant for /some/ callees.) >> >> In the case where in-band and out-of-band on the originating are >>literally >> being managed by the same device or service, I think it's about as >> redundant as a SIP INVITE proposing two codecs in the hope that the far > >You think that including an offer list -- a list of options -- is >comparable cost to the caller's doing all the work of performing two >authentication functions? > >Really? I didn't suggest it was a comparable amount of work, just that it was a comparable amount of redundancy, or intolerability concern. >(Now, if you had cited MIME multipart/alternative, it might be a bit >more interesting, but you didn't, so it isn't...) Very generous of you to find an argument that persuades you of this more than mine did. >>>> To me, this out-of-band question is a question about the problem we're >>>> aiming to solve, not the solution mechanisms. Are we going to try to >>>>do >>>> anything about the parts of the robocalling and voicemail hacking >>>> problem >>>> where SIP is not the protocol used on both side, or are we going to >>>>skip >>>> that? And if the latter, are we addressing enough of the problem for >>>> this >>>> to be worth our effort? >>> >>> So a proposed solution isn't about solutions but about the problem? >>> Sorry, but I've no idea what this paragraph means or how it responds. >> >> If the problem is to try to address robocalling and voicemail hacking, >>and >> those problems are not limited than the IP world, then should the scope >>of >> our work be limited to the IP world? > >As you state it, that's not the issue here. The issue here is how to >approach dealing with a very complex operational environment. The complexities of the operational environment are precisely what motivated us to adopt two approaches. >A term like "divide and conquer" is often applied. More specifically -- >and quite common to IETF efforts that are successful -- is to start with >developing the smallest useful solution that can be deployed, and then >add to it... over time. I discuss above a bit why we didn't propose to "divide and conquer" here, though, the original charter did propose we do one first and then the other. >So the most important issue is about project (working group) sequencing. > >In particular, /start/ with a clean, SIP-based mechanism. After that is >done, consider enhancements that extend its utility. It's like like we're so far apart on this point, right. The original charter did suggest we deliver in-band first. The difference here is that the original charter then stipulates that we do out-of-band, where here you say the charter should limit us just to considering it. For the purposes of creating reusable components, and to some degree having a crisp scope for each mechanism that recognizes the applicability of the other, I think they should both be on the plate from the start. Jon Peterson Neustar, Inc. >>> Really, my note asked very simple, very basic technical questions about >>> the out-of-band 'proposal'. Very simple. Very basic. >>> >>> For those promoting an immediate effort at producing an out-of-band >>> solution, the answers also out to be very simple and basic. >> >> I don't have all the answers about the solution. I do think we have a >> reasonable idea of what the problem is, and what some approaches are - >> enough to charter it and to work on it. > >If the listed "approaches" are clear enough to permit engineering >estimates of feasibility, you are correct. > >Unfortunately, we are not doing very well in garnering such technical >substance. > >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 Tue Jul 16 11:17: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 CBEA221F8FCE for ; Tue, 16 Jul 2013 11:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKjY4PEPI0eW for ; Tue, 16 Jul 2013 11:17:40 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 469EB21F9263 for ; Tue, 16 Jul 2013 11:17:40 -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 r6GIHVTQ028661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Jul 2013 18:17:34 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 r6GIHU15008123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 18:17:31 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6GIHU3n004716; Tue, 16 Jul 2013 18:17:30 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 16 Jul 2013 11:17:30 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <51E55F3E.8090205@dcrocker.net> Date: Tue, 16 Jul 2013 14:17:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <66338CC9-AA27-4912-92E9-A031A7CDDFBA@oracle.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <009f01ce8229$6509e3a0$2f1daae0$@shockey.us> <27376377-8220-4AEC-97A2-A1D59DAA54DA@oracle.com> <7A9C6940-5BC1-4A22-A4C8-85EF5495D4EC@brianrosen.net> <51E55F3E.8090205@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: IETF STIR Mail List Subject: [stir] Replay threat (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 18:17:47 -0000 On Jul 16, 2013, at 10:57 AM, Dave Crocker wrote: > Folks, > Question to the group: > There are a number of different styles of replay attack, with = different likelihoods and different effects (nature/degree of damage). > What specific replay scenarios does the group deem it essential to = prevent and why? > I've seen situations in which it was deemed acceptable to allow some = types of potential replay attacks, because the potential for its = occurrence and/or damage it would do were not a serious concern. It depends on how you define "replay". In my personal opinion, the = threat of someone replaying the same SIP message against the same target = is virtually nil. It's not hard to prevent it I think, so I don't see a = reason not to prevent it. We've already assumed the odds of a malicious MITM are very low. Or to = be more precise, we acknowledge there already are a ton of benign MITM, = and that if they wanted to be bad, caller-id authentication isn't gonna = prevent much. It's just closing a stateroom door on the Titanic. We've acknowledged there are bad senders, but if they can get their = messages signed, they hardly need to replay the message with the same = signature. We've acknowledged there are weak signers, but if they have the key to = sign messages, then they don't need to replay. We've acknowledged (I think) that there are bad receivers. So we have = to prevent them from replaying a received message against a *different* = target. I think of that as more of a cut-and-paste attack than replay, = but I don't care what it's called. The point is that I can easily get a = bank to call me, and I should not be able to use their call request's = STIR info to call someone else and have that someone else believe the = bank is calling them. Unfortunately, preventing that cut-and-paste attack is quite hard. = Mostly because it's hard to distinguish from a completely legitimate = call-forwarding case, and we have to support legitimate call-forwarding. -hadriel From kent@bbn.com Tue Jul 16 11:34:40 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5B421F991F for ; Tue, 16 Jul 2013 11:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzzH1b1OIVHe for ; Tue, 16 Jul 2013 11:34:34 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id DA65D21F964C for ; Tue, 16 Jul 2013 11:34:32 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:56172) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UzA50-000ExW-8A; Tue, 16 Jul 2013 14:34:30 -0400 Message-ID: <51E59237.8000401@bbn.com> Date: Tue, 16 Jul 2013 14:34:31 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Michael Hammer References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> Content-Type: multipart/alternative; boundary="------------030609060306070400030501" Cc: "stir@ietf.org" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 18:34:40 -0000 This is a multi-part message in MIME format. --------------030609060306070400030501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mike, > Steve, > > We can argue about whether freely distributable is valid or not, > > but do you disagree that some operators would not want the number > delegation revealed? > I don't claim to know what operators want. I know that what folks may want may not align well with security concerns. I'd rather not see us devise a system based on known, bad approaches, e.g., the web browser PKI model. > > The number portability DB in US is a trusted third party. > are we constrained by current models for number portability management when we devise a solution for this problem? Just asking, as I didn't think that was an explicit part of the WG charter, but I could be mistaken. > And you argue both sides, since any delegation from central authority > is a third party, even an SP. > no, its not, in the PKI sense that we are discussing. > > You would argue that having many more of them makes it more secure? > That's not what I said. I said that the preferred model would use exiting, authoritative entities to issue certs. Whenever a CA relies on a database from some other entity, problems are likely to arise, based on experience. > > Experience also argues the more there are the harder to police. > Fewer might be better, but not necessarily, as you seem to suggest. External auditing (policing?) of CA operation has proven to be inadequate in the browser context. > > I see no difference in the DigiNotar case. That appeared to be an > organizational failure. > it was a failure in multiple ways, ways that could have been avoided through technical means. > > That breach could have occurred with an SP as easily. > yes, but if the SP were (technically) constrained to issue certs that attested only to phone numbers that have been assigned to it under a numbering plan, the fallout would have been mitigated. I assume you are familiar with the DigiNotar details, and thus realize that the biggest problem was the fact that the attackers used DigiNotar to issue certs for web sites that were not DigiNotar clients. > > What "technical constraints" are you saying were not implemented? > One can use HSMs that assign cert serial numbers and log such assignments in a secure fashion. That way if an attacker compromises the computer used to mint certs, the attacker cannot control the serial numbers that are assigned and cannot delete the logs showing that certs were issued fraudulently. The CA, with knowledge of the "bad" cert serial numbers, can revoke them. None of those capabilities were present in the DigiNotar system. > > Keep in mind that we need a solution that works when there are on the > order of thousands of operators, as there are in the U.S. > The RPKI system might provide a useful example. It is being deployed on a global basis (slowly) and it must accommodate tens of thousands of ISPs. It incorporates the sort of delegation restrictions that I mentioned, and is aligned with the IP address and ASN allocation-delegation hierarchy. Steve --------------030609060306070400030501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mike,

Steve,

 

We can argue about whether freely distributable is valid or not,

but do you disagree that some operators would not want the number delegation revealed?

I don't claim to know what operators want. I know that what folks may want may not
align well with security concerns. I'd rather not see us devise a system based on known,
bad approaches, e.g., the web browser PKI model.

 The number portability DB in US is a trusted third party.

are we constrained by current models for number portability management when we devise a solution for this problem? Just asking, as I didn't think that was an explicit part
of the WG charter, but I could be mistaken.

And you argue both sides, since any delegation from central authority is a third party, even an SP.

no, its not, in the PKI sense that we are discussing.

You would argue that having many more of them makes it more secure?

That's not what I said. I said that the preferred model would use exiting,
authoritative entities to issue certs. Whenever a CA relies on a database from
some other entity, problems are likely to arise, based on experience.

Experience also argues the more there are the harder to police.

Fewer might be better, but not necessarily, as you seem to suggest. External
auditing (policing?) of CA operation has proven to be inadequate in the browser context.

 I see no difference in the DigiNotar case.  That appeared to be an organizational failure.

it was a failure in multiple ways, ways that could have been avoided through technical means.

That breach could have occurred with an SP as easily.

yes, but if the SP were (technically) constrained to issue certs that attested only
to phone numbers that have been assigned to it under a numbering plan, the fallout
would have been mitigated. I assume you are familiar with the DigiNotar details, and
thus realize that the biggest problem was the fact that the attackers used DigiNotar
to issue certs for web sites that were not DigiNotar clients.

What “technical constraints” are you saying were not implemented?

One can use HSMs that assign cert serial numbers and log such assignments in
a secure fashion. That way if an attacker compromises the computer used to mint
certs, the attacker cannot control the serial numbers that are assigned and cannot delete
the logs showing that certs were issued fraudulently. The CA, with knowledge
of the "bad" cert serial numbers, can revoke them. None of those capabilities were
present in the DigiNotar system.

 

Keep in mind that we need a solution that works when there are on the order of thousands of operators, as there are in the U.S.


The RPKI system might provide a useful example. It is being deployed on a global basis (slowly) and it must accommodate tens of thousands of ISPs. It incorporates the sort of
delegation restrictions that I mentioned, and is aligned with the IP address and ASN allocation-delegation hierarchy.

Steve
--------------030609060306070400030501-- From housley@vigilsec.com Tue Jul 16 11:39: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 9FF7311E80ED for ; Tue, 16 Jul 2013 11:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 18EJXxocT3Kk for ; Tue, 16 Jul 2013 11:39:12 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7C121F9C12 for ; Tue, 16 Jul 2013 11:39:12 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 6E5C3F2407C for ; Tue, 16 Jul 2013 14:39:37 -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 5AGGl3MXXmvt for ; Tue, 16 Jul 2013 14:39:06 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-212-98.washdc.fios.verizon.net [96.241.212.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 2DC44F2407E for ; Tue, 16 Jul 2013 14:39:35 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jul 2013 14:39:07 -0400 Message-Id: <26E873F4-2595-4C75-8DF4-1050B3A53328@vigilsec.com> To: IETF STIR Mail List Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [stir] DRAFT STIR BOF Agenda X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 18:39:17 -0000 https://pub.ietf.org/proceedings/87/stir/ I expect that there will be hums at the end of each major agenda topic: = Problem Statement, Solution Proposals, and Draft Charter. Russ From housley@vigilsec.com Tue Jul 16 11:45: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 377F011E80F9 for ; Tue, 16 Jul 2013 11:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 kbAGl-RKd8fd for ; Tue, 16 Jul 2013 11:45:13 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 6854611E80D5 for ; Tue, 16 Jul 2013 11:45:12 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id CA491F2407E for ; Tue, 16 Jul 2013 14:45:42 -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 p7oMh+k7Rxcp for ; Tue, 16 Jul 2013 14:45:07 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-212-98.washdc.fios.verizon.net [96.241.212.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 9078EF2407C for ; Tue, 16 Jul 2013 14:45:41 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: <26E873F4-2595-4C75-8DF4-1050B3A53328@vigilsec.com> Date: Tue, 16 Jul 2013 14:45:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <26E873F4-2595-4C75-8DF4-1050B3A53328@vigilsec.com> To: IETF STIR Mail List X-Mailer: Apple Mail (2.1085) Subject: Re: [stir] DRAFT STIR BOF Agenda X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 18:45:18 -0000 http://www.ietf.org/proceedings/87/agenda/agenda-87-stir Sorry for the cut-and-paste error. Here is the link to the agenda. Russ > https://pub.ietf.org/proceedings/87/stir/ >=20 > I expect that there will be hums at the end of each major agenda = topic: Problem Statement, Solution Proposals, and Draft Charter. >=20 > Russ From kent@bbn.com Tue Jul 16 12:04: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 0604711E80FE for ; Tue, 16 Jul 2013 12:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbZpzZod-9oi for ; Tue, 16 Jul 2013 12:04:06 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3A77411E8101 for ; Tue, 16 Jul 2013 12:03:45 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:56376) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UzAXI-000FJB-Hf; Tue, 16 Jul 2013 15:03:44 -0400 Message-ID: <51E59911.9000603@bbn.com> Date: Tue, 16 Jul 2013 15:03:45 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Michael Hammer References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <51E565A2.80806@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17EE8@EX2K10MB1.corp.yaanatech.com> <51E56EFE.5040106@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F8F@EX2K10MB1.corp.yaanatech.com> <51E57A65.6020303@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC180B8@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC180B8@EX2K10MB1.corp.yaanatech.com> Content-Type: multipart/alternative; boundary="------------000704040507050101070105" Cc: "stir@ietf.org" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 19:04:12 -0000 This is a multi-part message in MIME format. --------------000704040507050101070105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mike, > Why? > > The cert path can be very short and orthogonal to the delegation path. > > it could be, but alignment makes the system simpler and easier to > understand, > and is supportive of the security principle of "least privilege". > > I disagree about simpler. The current system is my proof point. > (But, we can leverage that.) > > Least privilege is about multiple levels (S, TS, TS/SCI etc.) of > what the asserter has authority to assert or view. > > There is only one level of assertion that needs authority here. > And the assertion must be universally readable. > > To which "current system" do you refer? > > /The fact that there are multiple again proves my point. / > My question re your term "current system" was intended to elicit a response citing a specific system, so that I might understand your comments in that context. Your reply help me (or other readers) understand the context of your assertion. > > // > > /Ask yourself how anyone knows who the current number belongs to and > then tell me if that is simple or not./ > > // > > /I think we both agree it should be simple, but differ only in whether > following existing regimes is simpler or not./ > Until we have a concrete, detailed proposals, debates about what is and is not simple will probably be futile. > > // > > Your response tells me that you are not familiar with the term "least > privilege." See > the definition of the term in the paper by Jerry Saltzer, ca 1975. The > term refers to > the notion that a system should be structured to limit the authority > (and thus the > amount of damage) associated with each system element, based on what > the element requires > to do its job. > > /I may be confusing my terms, but when the authority is distributed > across more entities, how is that least privilege?/ > yes, you are confusing the terms. Look at RFC 4949's definition of the phrase: The principle that a security architecture should be designed so that each system entity is granted the minimum system resources and authorizations that the entity needs to do its work. This principle is applied to each entity. If authorization is _distributed_ across multiple entities, then each of those should be constrained accordingly. > > // > > /You have given more actors control not fewer? Yes, each actor > theoretically controls less data, but how is that enforced?/ > see the RPKI design, for example. > > // > > /You have only squeezed the balloon and created a bigger auditing > problem elsewhere./ > Auditing is probably a necessary, but certainly not a sufficient, mechanism here. > > // > > /I was thinking of limiting the authority to the least number of > entities necessary to accomplish the function./ > The term "necessary" is unqualified here. 1 is a possible answer (but probably a very bad one). > // > > /Or, in your terms "limiting the authority associated with each system > element based on what the element requires to do its job."/ > > /It is the job of the "national authority element" and does not need > to be shared more than necessary./ > Well, at least you provided a concrete example this time. So you're suggesting one entity per country to manage cert issuance for all SPs? > // > > ... > > /With cryptography, one needs to get down to specific mathematically > notations to fully specify./ > > /I was just trying to outline the general ideas across. Obviously more > precise wording was needed./ > > /But I hope the idea that limiting the process to 2 actors who can > authenticate each other, / > > /and relying on strong certificates rather than chains of > organizations and networks could lead / > > /to better security and privacy./ > The points on which we disagree above don't require any math (unless you're proposing IBE, which would not be algorithm agile, and which has a lot of IP issues). They're common PKI technology/terminology issues. Steve --------------000704040507050101070105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mike,

Why? 

 

The cert path can be very short and orthogonal to the delegation path.

it could be, but alignment makes the system simpler and easier to understand,
and is supportive of the security principle of "least privilege".

 

I disagree about simpler.  The current system is my proof point.  (But, we can leverage that.)

Least privilege is about multiple levels (S, TS, TS/SCI etc.) of what the asserter has authority to assert or view. 

There is only one level of assertion that needs authority here. And the assertion must be universally readable.

To which "current system" do you refer?

 

The fact that there are multiple again proves my point. 

My question re your term "current system" was intended to elicit a response citing
a specific system, so that I might understand your comments in that context. Your
reply help me (or other readers) understand the context of your assertion.

Ask yourself how anyone knows who the current number belongs to and then tell me if that is simple or not.

I think we both agree it should be simple, but differ only in whether following existing regimes is simpler or not.

Until we have a concrete, detailed proposals, debates about what is and is not simple
will probably be futile.

 Your response tells me that you are not familiar with the term "least privilege." See
the definition of the term in the paper by Jerry Saltzer, ca 1975. The term refers to
the notion that a system should be structured to limit the authority (and thus the
amount of damage) associated with each system element, based on what the element requires
to do its job.

I may be confusing my terms, but when the authority is distributed across more entities, how is that least privilege?

yes, you are confusing the terms. Look at RFC 4949's definition of the phrase:

The principle that a security architecture should be designed
so that each system entity is granted the minimum system resources
and authorizations that the entity needs to do its work.

This principle is applied to each entity. If authorization is distributed across
multiple entities, then each of those should be constrained accordingly.

You have given more actors control not fewer?  Yes, each actor theoretically controls less data, but how is that enforced?

see the RPKI design, for example.

You have only squeezed the balloon and created a bigger auditing problem elsewhere.

Auditing is probably a necessary, but certainly not a sufficient, mechanism here.

I was thinking of limiting the authority to the least number of entities necessary to accomplish the function.

The term "necessary" is unqualified here. 1 is a possible answer (but probably a very bad
one).

Or, in your terms “limiting the authority associated with each system element based on  what the element requires to do its job.”

It is the job of the “national authority element” and does not need to be shared more than necessary.

Well, at least you provided a concrete example this time. So you're suggesting one
entity per country to manage cert issuance for all SPs?

 ...

 

With cryptography, one needs to get down to specific mathematically notations to fully specify.

I was just trying to outline the general ideas across.  Obviously more precise wording was needed.

But I hope the idea that limiting the process to 2 actors who can authenticate each other,

and relying on strong certificates rather than chains of organizations and networks could lead

to better security and privacy.

The points on which we disagree above don't require any math (unless you're proposing
IBE, which would not be algorithm agile, and which has a lot of IP issues). They're
common PKI technology/terminology issues.

Steve


--------------000704040507050101070105-- From michael.hammer@yaanatech.com Tue Jul 16 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 58C7E21E80AA for ; Tue, 16 Jul 2013 12:10:59 -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.074, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ob-zMOYd3GEH for ; Tue, 16 Jul 2013 12:10: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 2BFBA21E80AE for ; Tue, 16 Jul 2013 12:10:41 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 16 Jul 2013 12:10:40 -0700 From: Michael Hammer To: "kent@bbn.com" Thread-Topic: [stir] Rollout timeframe Thread-Index: AQHOgj0MegkF68FLTUyBdNmNASSKrplnd8uggACAIoD//44WoIAAkRSA//+PYsA= Date: Tue, 16 Jul 2013 19:10:40 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC181C3@EX2K10MB1.corp.yaanatech.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <51E59237.8000401@bbn.com> In-Reply-To: <51E59237.8000401@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.87] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0189_01CE8236.A15944B0" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 19:10:59 -0000 ------=_NextPart_000_0189_01CE8236.A15944B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_018A_01CE8236.A15944B0" ------=_NextPart_001_018A_01CE8236.A15944B0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Steve, My pointing to NP was only to indicate that there are trusted third parties that are reliable. I also did not want to reinvent the number delegation system for the operational aspects. My focus is on how the called party can validate in near-real-time (few seconds) the authenticity of the number. That in turn needs administrative side that can update in only slightly longer time (minutes) due to number portability. Given that calls can come from anywhere globally, I didn't think crawling the internet to discover some locally peculiar regime would help. Anyway, I am going to give this a rest for now. Mike From: Stephen Kent [mailto:kent@bbn.com] Sent: Tuesday, July 16, 2013 2:35 PM To: Michael Hammer Cc: stir@ietf.org Subject: Re: [stir] Rollout timeframe Mike, Steve, We can argue about whether freely distributable is valid or not, but do you disagree that some operators would not want the number delegation revealed? I don't claim to know what operators want. I know that what folks may want may not align well with security concerns. I'd rather not see us devise a system based on known, bad approaches, e.g., the web browser PKI model. The number portability DB in US is a trusted third party. are we constrained by current models for number portability management when we devise a solution for this problem? Just asking, as I didn't think that was an explicit part of the WG charter, but I could be mistaken. And you argue both sides, since any delegation from central authority is a third party, even an SP. no, its not, in the PKI sense that we are discussing. You would argue that having many more of them makes it more secure? That's not what I said. I said that the preferred model would use exiting, authoritative entities to issue certs. Whenever a CA relies on a database from some other entity, problems are likely to arise, based on experience. Experience also argues the more there are the harder to police. Fewer might be better, but not necessarily, as you seem to suggest. External auditing (policing?) of CA operation has proven to be inadequate in the browser context. I see no difference in the DigiNotar case. That appeared to be an organizational failure. it was a failure in multiple ways, ways that could have been avoided through technical means. That breach could have occurred with an SP as easily. yes, but if the SP were (technically) constrained to issue certs that attested only to phone numbers that have been assigned to it under a numbering plan, the fallout would have been mitigated. I assume you are familiar with the DigiNotar details, and thus realize that the biggest problem was the fact that the attackers used DigiNotar to issue certs for web sites that were not DigiNotar clients. What "technical constraints" are you saying were not implemented? One can use HSMs that assign cert serial numbers and log such assignments in a secure fashion. That way if an attacker compromises the computer used to mint certs, the attacker cannot control the serial numbers that are assigned and cannot delete the logs showing that certs were issued fraudulently. The CA, with knowledge of the "bad" cert serial numbers, can revoke them. None of those capabilities were present in the DigiNotar system. Keep in mind that we need a solution that works when there are on the order of thousands of operators, as there are in the U.S. The RPKI system might provide a useful example. It is being deployed on a global basis (slowly) and it must accommodate tens of thousands of ISPs. It incorporates the sort of delegation restrictions that I mentioned, and is aligned with the IP address and ASN allocation-delegation hierarchy. Steve ------=_NextPart_001_018A_01CE8236.A15944B0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Steve,

 

My pointing to NP was only to indicate that there are trusted third = parties that are reliable.

I also did not want to reinvent the number delegation system for the = operational aspects.

 

My focus is on how the called party can validate in near-real-time = (few seconds) the authenticity of the number.

That in turn needs administrative side that can update in only = slightly longer time (minutes) due to number = portability.

Given that calls can come from anywhere globally, I didn’t = think crawling the internet to discover some locally peculiar regime = would help.

 

Anyway, I am going to give this a rest for = now.

 

Mike

 

 

From: Stephen Kent [mailto:kent@bbn.com]
Sent: Tuesday, July = 16, 2013 2:35 PM
To: Michael Hammer
Cc: = stir@ietf.org
Subject: Re: [stir] Rollout = timeframe

 

Mike,


Steve,

 

We can argue about whether freely distributable is valid or not, =

but do you disagree that some operators would not want the number = delegation revealed?

I don't = claim to know what operators want. I know that what folks may want may = not
align well with security concerns. I'd rather not see us devise a = system based on known,
bad approaches, e.g., the web browser PKI = model.

 The number portability DB in US is a trusted third = party.

are we constrained by = current models for number portability management when we devise a = solution for this problem? Just asking, as I didn't think that was an = explicit part
of the WG charter, but I could be = mistaken.


And you argue both sides, since any delegation from central authority = is a third party, even an SP.

no, its not, in the PKI sense that we are = discussing.

You would argue that having many more of them makes it more = secure?

That's not what I = said. I said that the preferred model would use = exiting,
authoritative entities to issue certs. Whenever a CA relies = on a database from
some other entity, problems are likely to arise, = based on experience.

Experience also argues the more there are the harder to = police.

Fewer might be better, = but not necessarily, as you seem to suggest. External
auditing = (policing?) of CA operation has proven to be inadequate in the browser = context.

 I see no difference in the DigiNotar case.  That appeared = to be an organizational failure.

it was a failure in multiple ways, ways that could = have been avoided through technical means.

That breach could have occurred with an SP as = easily.

yes, but if the SP = were (technically) constrained to issue certs that attested only
to = phone numbers that have been assigned to it under a numbering plan, the = fallout
would have been mitigated. I assume you are familiar with the = DigiNotar details, and
thus realize that the biggest problem was the = fact that the attackers used DigiNotar
to issue certs for web sites = that were not DigiNotar clients.

What “technical constraints” are you saying were not = implemented?

One can use HSMs = that assign cert serial numbers and log such assignments in
a secure = fashion. That way if an attacker compromises the computer used to = mint
certs, the attacker cannot control the serial numbers that are = assigned and cannot delete
the logs showing that certs were issued = fraudulently. The CA, with knowledge
of the "bad" cert = serial numbers, can revoke them. None of those capabilities = were
present in the DigiNotar system.

 

Keep in mind that we need a solution that works when there are on the = order of thousands of operators, as there are in the = U.S.


The RPKI system might = provide a useful example. It is being deployed on a global basis = (slowly) and it must accommodate tens of thousands of ISPs. It = incorporates the sort of
delegation restrictions that I mentioned, = and is aligned with the IP address and ASN allocation-delegation = hierarchy.

Steve

------=_NextPart_001_018A_01CE8236.A15944B0-- ------=_NextPart_000_0189_01CE8236.A15944B0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NjE5MTAzOFowIwYJKoZIhvcNAQkEMRYEFOu7Ba8mnS4a6BCSKlpZ1HhWoE34MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAB7Pfr/Azu3o6ACNkjGdqHwkLVazBxWSvYB/RpljZ jbfo0D61SDtq0LJ9XNgLSVy0Bl8NT+6yJ1WmfL/9na5xCC8T7PbvgR1iI0yAH1wafmmL34oFgFsh RUfG31jjwgtir1sQ9R5oAiAXuhux8QiCGJ9f59TwkdwJNJmBM/6q38u6cFvfP71vl7wH8sJ6r6Bk JyolaUKnYSvzN6ke810I/cIEz7NovLCUdQgqOC+3FkczcbaBwONZFLs4lpfG5eoN4OVXHgXPpVHf W/L39/kOvpoBZCmD/KIQddNyRWl8iRyj+2y4IZMU2YaqS8Ockl8Vw4ldjIyofO9NdjEPqX/D5gAA AAAAAA== ------=_NextPart_000_0189_01CE8236.A15944B0-- From kent@bbn.com Tue Jul 16 12: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 97C0E11E80FA for ; Tue, 16 Jul 2013 12:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncsH0lEJ4Hrs for ; Tue, 16 Jul 2013 12:14:54 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 80FD111E80D3 for ; Tue, 16 Jul 2013 12:14:54 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:56377) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UzAhr-000FQM-Fn; Tue, 16 Jul 2013 15:14:39 -0400 Message-ID: <51E59BA0.20500@bbn.com> Date: Tue, 16 Jul 2013 15:14:40 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hadriel Kaplan References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "stir@ietf.org Mail List" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 19:15:00 -0000 Hadriel, > On Jul 16, 2013, at 11:56 AM, Stephen Kent wrote: > >> I'm not sure I agree with your notion of no need for a hierarchy. Numb= ering >> plans appear to be administered in a hierarchic fashion (said the tel= ephony outsider), >> and so aligning a PKI with that hierarchy would be a natural fit, one = that would >> counter the large scale failure that accompanied the DigiNotar securit= y failure. >> DNSSEC and the RPKI are both examples where the certification system a= ligns with >> an extant, hierarchic system. > Numbering administration doesn't necessarily align with a clean hierarc= hy for all countries, depending on how you mean that. The country-code n= umber portion itself does, and in the North American Numbering Plan (NANP= ) the area-code level does but only with regard to defining which nation = has that whole area-code of numbers. In other words, all numbers within = an area-code belong to the USA, vs. another area-code to Canada, vs. Jama= ica, etc. But within that area-code's tree branches, any specific full n= umber can belong to a different carrier. For example, the entire +1-603 = area-code is a USA NANPA-based one, but +1-603-555-1000 can belong to AT&= T, while +1-603-555-1001 can be VZ, and +1-603-555-1002 can be Comcast, e= tc. They're initially allocated as blocks (of 1000 numbers I think), but= once numbers are ported out they become fragmented. yep, this matches what I understood to be true. > So if you did this thing with actual certificates, it would be tricky. = Having an authoritative root CA for each country-code wouldn't be too ha= rd, but below that you'd have to define an encoding schema for indicating= a range-list of E.164 numbers a cert is good for, and then revoke the ce= rt and replace once a number gets ported.[1] Or you'd have a separate ce= rt for each E.164 number. Either way, the cert signing process has to be= automated/automatable, because numbers get ported and the new assignee h= as to be able to claim that ported number in ~15 minutes or so. An efficient encoding and suitable distribution of ranges of numbers=20 across multiple certs is a challenge, but we ought not assume it is impossible. I concur with=20 the need to automate cert signing. I would not suggest a per-number cert unless there was a=20 real need for that granularity of authentication. I admit that 15 minutes is pretty fast to = make this info available. That may be biggest challenge for any solution. > The CIDER proposal avoids certificates, and just uses DNS instead. For= SIP email-style names it would be nearly identical to DKIM. For E.164 n= umbers it uses a DNS anchor for each country-code, but leaves it up to ea= ch country to decide how actual DNS delegation works. The important aspe= ct is it separates the DNS zone delegation from the E.164 number delegati= on. Basically, the DNS admin decides who can populate the public-keys in= the DNS nodes representing the E.164 numbers, and gives them provisionin= g access to do so, but the DNS admin is authoritative for the node in DNS= =2E In other words, when a carrier is assigned an E.164 number, they're = given access rights to populate the public-key for that number in the DNS= admin's database, but they're not delegated the DNS node itself and are = not authoritative for it. But of course if the DNS admin wants to delega= te it to them, they can (it's still DNS after all). The ability to not d= o so is useful, though, to hide who the carrier is and to let it be centr= ally managed if one so wishes. I'm not enough of a DNS expert to fully understand the outline of the=20 design you provided above. I'll look forward to seeing others (more DNS=20 knowledgeable than I) comment on it. > [1] One could argue true cert revocation isn't necessary for numbers be= ing ported out, as we could just accept that the cert holder for a ported= -out number could illegitimately claim the number until that cert times o= ut. From a practical threat perspective, that's not a big weakness. (you= 'd still have revocation for the other usual reasons of course - but for = number porting situations it wouldn't be necessary to revoke) When designing a PKI one should always make decisions about cert=20 lifetimes and CRL size and issuance frequency based on some model of expected operation.=20 It is appalling that some very big PKIs fail this test, e.g., the U.S. DoD PKI! It isn't = yet clear *at least to me) how big the vulnerability is if revocation info is slow,=20 relative to new cert issuance. We might want to err on the side of being = unable to verify calling number info (and providing an indication to the called parry) vs. denying service. From kent@bbn.com Tue Jul 16 12:17: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 B696111E80ED for ; Tue, 16 Jul 2013 12:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjNbVhkD1UlT for ; Tue, 16 Jul 2013 12:17:17 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id DBB6111E80D3 for ; Tue, 16 Jul 2013 12:17:17 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:56381) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UzAkM-000FSO-8X; Tue, 16 Jul 2013 15:17:14 -0400 Message-ID: <51E59C3B.9080906@bbn.com> Date: Tue, 16 Jul 2013 15:17:15 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Brian Rosen References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <51E565A2.80806@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17EE8@EX2K10MB1.corp.yaanatech.com> <51E56EFE.5040106@bbn.com> <30AC5063-E6F6-4230-98B0-3A52D8EF71CA@brianrosen.net> In-Reply-To: <30AC5063-E6F6-4230-98B0-3A52D8EF71CA@brianrosen.net> Content-Type: multipart/alternative; boundary="------------010203000902090201070206" Cc: "stir@ietf.org" , Michael Hammer Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 19:17:24 -0000 This is a multi-part message in MIME format. --------------010203000902090201070206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian, > I think the credential path follows the delegation path, but I hope > that in most deployments, we're not chasing a chain of credentials to > validate. I don't know what you mean by the statement above. Do you mean that you hope cert paths (or a DNSSEC equivalent) will be short, that most of tbe data will change slowly enough that caching will be a big win, or what? > Ultimately, remember the math Henning did - even with cert per TN, > it's still not a whole lot of data. These days very few things that I imagine dealing with amount to a "whole lot of data" :-) . Steve --------------010203000902090201070206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian,

I think the credential path follows the delegation path, but I hope that in most deployments, we're not chasing a chain of credentials to validate.
I don't know what you mean by the statement above. Do you mean that you hope cert paths
(or a DNSSEC equivalent) will be short, that most of tbe data will change slowly enough that
caching will be a big win, or what?
Ultimately, remember the math Henning did - even with cert per TN, it's still not a whole lot of data.
These days very few things that I imagine dealing with amount to a "whole lot of data" :-) .

Steve

--------------010203000902090201070206-- From michael.hammer@yaanatech.com Tue Jul 16 12: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 462B521F9D24 for ; Tue, 16 Jul 2013 12:23:20 -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.072, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRnHNMjtJXMN for ; Tue, 16 Jul 2013 12:23:15 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 14E0821F9D17 for ; Tue, 16 Jul 2013 12:23: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; Tue, 16 Jul 2013 12:23:08 -0700 From: Michael Hammer To: "kent@bbn.com" Thread-Topic: [stir] Rollout timeframe Thread-Index: AQHOgjiLZosA/DKyMEuxDpDhXheKTZlnbarwgAB/eQD//40YsIAAgH+A//+PSyCAAJVGgP//ju3w Date: Tue, 16 Jul 2013 19:23:07 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC1820A@EX2K10MB1.corp.yaanatech.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <51E565A2.80806@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17EE8@EX2K10MB1.corp.yaanatech.com> <51E56EFE.5040106@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F8F@EX2K10MB1.corp.yaanatech.com> <51E57A65.6020303@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC180B8@EX2K10MB1.corp.yaanatech.com> <51E59911.9000603@bbn.com> In-Reply-To: <51E59911.9000603@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.87] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0195_01CE8238.5E969770" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 19:23:22 -0000 ------=_NextPart_000_0195_01CE8238.5E969770 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0196_01CE8238.5E969770" ------=_NextPart_001_0196_01CE8238.5E969770 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit One last reply. (famous last words) s/current system/current state of affairs/ It's balkanized. There is no one system we can align with. If we need to reflect the delegation systems of every nation globally into our solution, the BOF time frame goals won't be met. Mike From: Stephen Kent [mailto:kent@bbn.com] Sent: Tuesday, July 16, 2013 3:04 PM To: Michael Hammer Cc: stir@ietf.org Subject: Re: [stir] Rollout timeframe Mike, Why? The cert path can be very short and orthogonal to the delegation path. it could be, but alignment makes the system simpler and easier to understand, and is supportive of the security principle of "least privilege". I disagree about simpler. The current system is my proof point. (But, we can leverage that.) Least privilege is about multiple levels (S, TS, TS/SCI etc.) of what the asserter has authority to assert or view. There is only one level of assertion that needs authority here. And the assertion must be universally readable. To which "current system" do you refer? The fact that there are multiple again proves my point. My question re your term "current system" was intended to elicit a response citing a specific system, so that I might understand your comments in that context. Your reply help me (or other readers) understand the context of your assertion. Ask yourself how anyone knows who the current number belongs to and then tell me if that is simple or not. I think we both agree it should be simple, but differ only in whether following existing regimes is simpler or not. Until we have a concrete, detailed proposals, debates about what is and is not simple will probably be futile. Your response tells me that you are not familiar with the term "least privilege." See the definition of the term in the paper by Jerry Saltzer, ca 1975. The term refers to the notion that a system should be structured to limit the authority (and thus the amount of damage) associated with each system element, based on what the element requires to do its job. I may be confusing my terms, but when the authority is distributed across more entities, how is that least privilege? yes, you are confusing the terms. Look at RFC 4949's definition of the phrase: The principle that a security architecture should be designed so that each system entity is granted the minimum system resources and authorizations that the entity needs to do its work. This principle is applied to each entity. If authorization is distributed across multiple entities, then each of those should be constrained accordingly. You have given more actors control not fewer? Yes, each actor theoretically controls less data, but how is that enforced? see the RPKI design, for example. You have only squeezed the balloon and created a bigger auditing problem elsewhere. Auditing is probably a necessary, but certainly not a sufficient, mechanism here. I was thinking of limiting the authority to the least number of entities necessary to accomplish the function. The term "necessary" is unqualified here. 1 is a possible answer (but probably a very bad one). Or, in your terms "limiting the authority associated with each system element based on what the element requires to do its job." It is the job of the "national authority element" and does not need to be shared more than necessary. Well, at least you provided a concrete example this time. So you're suggesting one entity per country to manage cert issuance for all SPs? ... With cryptography, one needs to get down to specific mathematically notations to fully specify. I was just trying to outline the general ideas across. Obviously more precise wording was needed. But I hope the idea that limiting the process to 2 actors who can authenticate each other, and relying on strong certificates rather than chains of organizations and networks could lead to better security and privacy. The points on which we disagree above don't require any math (unless you're proposing IBE, which would not be algorithm agile, and which has a lot of IP issues). They're common PKI technology/terminology issues. Steve ------=_NextPart_001_0196_01CE8238.5E969770 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

One last reply.  (famous last words)

 

s/current system/current state of affairs/

 

It’s balkanized.  There is no one system we can align = with.

 

If we need to reflect the delegation systems of every nation globally = into our solution, the BOF time frame goals won’t be = met.

 

Mike

 

 

From: Stephen Kent [mailto:kent@bbn.com]
Sent: Tuesday, July = 16, 2013 3:04 PM
To: Michael Hammer
Cc: = stir@ietf.org
Subject: Re: [stir] Rollout = timeframe

 

Mike,


Why? 

 

The cert path can be very short and orthogonal to the delegation = path.

it could = be, but alignment makes the system simpler and easier to = understand,
and is supportive of the security principle of = "least privilege".

 

I= disagree about simpler.  The current system is my proof = point.  (But, we can leverage that.)

L= east privilege is about multiple levels (S, TS, TS/SCI etc.) of what the = asserter has authority to assert or view. 

T= here is only one level of assertion that needs authority here. And the = assertion must be universally = readable.

To which = "current system" do you refer?

 

The fact that there are multiple again proves my point.  =

My question re your = term "current system" was intended to elicit a response = citing
a specific system, so that I might understand your comments in = that context. Your
reply help me (or other readers) understand the = context of your assertion.

Ask yourself how anyone knows who the current number belongs to and = then tell me if that is simple or = not.

I think we both agree it should be simple, but differ only in whether = following existing regimes is simpler or = not.

Until we have a concrete, detailed proposals, debates = about what is and is not simple
will probably be = futile.

 Your response tells me that you are not familiar with = the term "least privilege." See
the definition of the term = in the paper by Jerry Saltzer, ca 1975. The term refers to
the notion = that a system should be structured to limit the authority (and thus the =
amount of damage) associated with each system element, based on what = the element requires
to do its job.


I may be confusing my terms, but when the authority is distributed = across more entities, how is that least = privilege?

yes, you = are confusing the terms. Look at RFC 4949's definition of the = phrase:

The principle that a security architecture should be = designed
so that each system entity is granted the minimum system = resources
and authorizations that the entity needs to do its = work.

This principle is applied to each entity. If authorization = is distributed across
multiple entities, then each of those = should be constrained accordingly.

You have given more actors control not fewer?  Yes, each actor = theoretically controls less data, but how is that = enforced?

see the = RPKI design, for example.

You have only squeezed the balloon and created a bigger auditing = problem elsewhere.

Auditing is probably a necessary, but certainly not a = sufficient, mechanism here.

I was thinking of limiting the authority to the least number of = entities necessary to accomplish the = function.

The term = "necessary" is unqualified here. 1 is a possible answer (but = probably a very bad
one).


Or, in your terms “limiting the authority associated with each = system element based on  what the element requires to do its = job.”

It is the job of the “national authority element” and = does not need to be shared more than = necessary.

Well, at = least you provided a concrete example this time. So you're suggesting = one
entity per country to manage cert issuance for all = SPs?


 ...

 

With cryptography, one needs to get down to specific mathematically = notations to fully specify.

I was just trying to outline the general ideas across.  = Obviously more precise wording was needed.

But I hope the idea that limiting the process to 2 actors who can = authenticate each other,

and relying on strong certificates rather than chains of = organizations and networks could lead

to better security and privacy.

The points on which we = disagree above don't require any math (unless you're proposing
IBE, = which would not be algorithm agile, and which has a lot of IP issues). = They're
common PKI technology/terminology = issues.

Steve

------=_NextPart_001_0196_01CE8238.5E969770-- ------=_NextPart_000_0195_01CE8238.5E969770 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NjE5MjMwNVowIwYJKoZIhvcNAQkEMRYEFJi5CUomBwa/L2BWY6S005D0Kfi0MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEALIQyGhcvNOvrwDV5kkB1Lb1ojJ54v6poXDGVP365 ypPL5he8qBE6MTTxNwtTfqoMZR7gqjbIQk2xogW/TX4wKR745BtKb1o+SRU/Qh9Xp/a9HFW30+jM QCp7LMz/8QYog25YDFIape69wwrF09wre/QnJt0T1iEAYeBoU77cLe2WNaxAvtYYuFjb+AefHi/A 0Wph7Gom3gcYNGZq/+V6yxhzbTcXSWmwDp5409qcriY16zA/IuhuTLbUhmmumVO6zglP8Ens721y w7gupgl8NIFdQV6kCcrpO5HbuOznGudWornCWhbwkbMiUY+IMIKA/HJDGzvilBOsFGpyOJZHUgAA AAAAAA== ------=_NextPart_000_0195_01CE8238.5E969770-- From hadriel.kaplan@oracle.com Tue Jul 16 12: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 9BBEB21F9D71 for ; Tue, 16 Jul 2013 12:26:11 -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 pHO4ufF7ahQ4 for ; Tue, 16 Jul 2013 12:25:58 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 33EF321F9D6B for ; Tue, 16 Jul 2013 12:25:55 -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 r6GJPpk9003566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Jul 2013 19:25:51 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 r6GJPoiS002157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 19:25:51 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 r6GJPniV026584; Tue, 16 Jul 2013 19:25:50 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 16 Jul 2013 12:25:49 -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: <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> Date: Tue, 16 Jul 2013 15:25:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@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" , "kent@bbn.com" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 19:26:11 -0000 On Jul 16, 2013, at 1:03 PM, Michael Hammer = wrote: > The number portability DB in US is a trusted third party. > And you argue both sides, since any delegation from central authority = is a third party, even an SP. > You would argue that having many more of them makes it more secure? > Experience also argues the more there are the harder to police. > =20 > I see no difference in the DigiNotar case. That appeared to be an = organizational failure. > That breach could have occurred with an SP as easily. > What =93technical constraints=94 are you saying were not implemented? >=20 I think Steven's point is that the web-pki model basically allows any = trusted CA to claim any domain name, even though none of them are = actually authoritative for domain name assignments. You can think of it = as basically creating an alternate-root to DNS - an alternate authority = of names - from an SSL/TLS-usage perspective. Since browsers trust ~160 CAs, the odds of a trusted CA screwing up not = only became high, but once it happened it affected all domain names. It = didn't just screw up the validity of domain names DigiNotar happens to = certify, but it screwed up ALL of them, because no one knows what domain = names DigitNotar could legitimately certify. With DNSSEC, however, the = actual authority of domain name assignments is the same entity who = actually signs stuff; they are not an alternate authority of names, they = *are* the one-and-only authority of the name. If they screw up, they = affect only the names signed by them (i.e., the names under their DNS = tree branch). And if they screw up, "revocation" is fairly simple for = them to perform and have take effect: they just change their DNSSEC = entries. When it comes to STIR stuff, the point is we can't just trust = third-party CAs to certify any E.164 number it cares to; because if they = scrwe up, it affectes all E.164 numbers. We have to have some means of = tying the certification to the authority that actually authoritatively = assigns the numbers. So we need to know that a cert from carrier-X for = number +1-603-555-1000 is signed by a CA that actually assigned = carrier-X that E.164 number; which means we need to know what numbers = the CA can assign - that it's authoritative for that role/decision. So... assuming we define some encoding scheme and mechanics for this = E.164 stuff to be done in certs... we could have the ITU sign certs of = country-code admins indicating the country-code number, and the = country-code admins sign certs of carriers indicating the full number, = and the carriers sign certs of their customer service providers, and = them signing certs of enterprises or end-users. (or more likely we'd = skip the ITU level one, and start with country-code level admins) But that would require a means of actually retrieving the correct cert, = walking the chain of signers, retrieving each of their certs, and = checking revocation lists. Meanwhile the caller has hung up the phone = because it didn't ring. :) -hadriel From br@brianrosen.net Tue Jul 16 12:39: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 9D3C521F9E47 for ; Tue, 16 Jul 2013 12:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.283 X-Spam-Level: X-Spam-Status: No, score=-100.283 tagged_above=-999 required=5 tests=[AWL=0.154, 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 3AKTgO6W3NSW for ; Tue, 16 Jul 2013 12:39:35 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 7526521F9E37 for ; Tue, 16 Jul 2013 12:39:35 -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=hL9WHnJcTTEo3nfFTtReMei6yCIK7m1rO0bu3U/vOJE=; b=kUy21LARZoTACQWNDQea6FKQXRl2Py3bnw8tcEH/Z3N4PNuVfxJ28YhF9QFGfEVw/7ChUzEA1XMPeTbLVx+1EhROkC+nIT6fZqfFfIQC6I5ejqlL/pkz669qkpbwZxq9VjG9bWbCM42N6gqzDXh4fkyGhyoVbeApW6C6PSgcamw=; Received: from neustargw.va.neustar.com ([209.173.53.233]:45397 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UzB5y-00028d-DE; Tue, 16 Jul 2013 15:39:34 -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: <51E59C3B.9080906@bbn.com> Date: Tue, 16 Jul 2013 15:39:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0B0C46A1-5582-42E6-A6F9-76C1526AF2C5@brianrosen.net> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <51E565A2.80806@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17EE8@EX2K10MB1.corp.yaanatech.com> <51E56EFE.5040106@bbn.com> <30AC5063-E6F6-4230-98B0-3A52D8EF71CA@brianrosen.net> <51E59C3B.9080906@bbn.com> To: Stephen Kent 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" , Michael Hammer Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 19:39:40 -0000 In the U.S., there may be many delegations in a path from the North = American Number Plan Administrator to the user that has the number. = Only the first two of these are captured in the formal delegation = databases - NANPA allocates a NPA (area code) to the Pooling = Administrator, which delegates a 1000 number block to a carrier. That carrier may resell 100 numbers to a SIP provider, who resells 20 of = them to another SIP provider who sells 10 of them to an enterprise, who = allocates one of those to an employee. At each step in the delegation (possibly save the last one), there could = theoretically be a credential issued. I would not want to verify the validity of all of these individually to = check a source identity. Ideally, I'd like to go one place and be able to get one credential that = is authoritative for the number. That seems possible, even when we have the credential path follow the = delegation path. I hear you on data size. But remember, an exabyte hear and an exabyte = there, and pretty soon, we're talking real big data stores. Brian On Jul 16, 2013, at 3:17 PM, Stephen Kent wrote: > Brian, >=20 >> I think the credential path follows the delegation path, but I hope = that in most deployments, we're not chasing a chain of credentials to = validate. > I don't know what you mean by the statement above. Do you mean that = you hope cert paths > (or a DNSSEC equivalent) will be short, that most of tbe data will = change slowly enough that > caching will be a big win, or what? >> Ultimately, remember the math Henning did - even with cert per TN, = it's still not a whole lot of data. > These days very few things that I imagine dealing with amount to a = "whole lot of data" :-) . >=20 > Steve >=20 From dhc@dcrocker.net Tue Jul 16 12:57: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 A31BB21F8488 for ; Tue, 16 Jul 2013 12:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNB7NY0CbdN6 for ; Tue, 16 Jul 2013 12:57:53 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A337C21F991F for ; Tue, 16 Jul 2013 12:57:50 -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 r6GJvksQ029979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Jul 2013 12:57:50 -0700 Message-ID: <51E5A599.5050102@dcrocker.net> Date: Tue, 16 Jul 2013 12:57:13 -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: <26E873F4-2595-4C75-8DF4-1050B3A53328@vigilsec.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]); Tue, 16 Jul 2013 12:57:50 -0700 (PDT) Cc: IETF STIR Mail List Subject: Re: [stir] DRAFT STIR BOF Agenda 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, 16 Jul 2013 19:57:57 -0000 On 7/16/2013 11:45 AM, Russ Housley wrote: > http://www.ietf.org/proceedings/87/agenda/agenda-87-stir > - Jon Peterson: inband solution > - Eric Rescorla: out-of-band solution > - Hadriel Kaplan: DNS-based solution I thought both Jon and Hadriel's proposals were "inband". d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From br@brianrosen.net Tue Jul 16 13:05: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 6E0EC21F99FC for ; Tue, 16 Jul 2013 13:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.288 X-Spam-Level: X-Spam-Status: No, score=-100.288 tagged_above=-999 required=5 tests=[AWL=0.149, 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 jlJjr6Hdgi3v for ; Tue, 16 Jul 2013 13:05:30 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 562AE21F9C7B for ; Tue, 16 Jul 2013 13:05: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=RgGA2UDqAMsHQzGzxKPnDCZ6FpGvtcisdLrMkjHAEKw=; b=VhyW5RU0XKlBz4WVOnZeH3Y8Xw/pIeuVFSg20uTFqUBxmrNAFUT2s/GTo5FZAp+QkDygtMnI9J5zZt3fUztZFCsHCtwFC/BZxbPLqQkx4UgbT5kdQYFUOYgOWc6cKf6eaB+YBKYCQNwd8q5/njSOgd1avcv3DypxO7K67/utHXg=; Received: from neustargw.va.neustar.com ([209.173.53.233]:48253 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UzBUy-0004x6-VB; Tue, 16 Jul 2013 16:05:25 -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: <51E5A599.5050102@dcrocker.net> Date: Tue, 16 Jul 2013 16:05:23 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <26E873F4-2595-4C75-8DF4-1050B3A53328@vigilsec.com> <51E5A599.5050102@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: IETF STIR Mail List , Russ Housley Subject: Re: [stir] DRAFT STIR BOF Agenda X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 20:05:34 -0000 They are. Probably poor choice of topic wording. Brian On Jul 16, 2013, at 3:57 PM, Dave Crocker wrote: > On 7/16/2013 11:45 AM, Russ Housley wrote: >> http://www.ietf.org/proceedings/87/agenda/agenda-87-stir > > >> - Jon Peterson: inband solution >> - Eric Rescorla: out-of-band solution >> - Hadriel Kaplan: DNS-based solution > > > I thought both Jon and Hadriel's proposals were "inband". > > d/ > > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From michael.hammer@yaanatech.com Tue Jul 16 13:14: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 A786321F9DBB for ; Tue, 16 Jul 2013 13:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 3DAJs4nb-4-f for ; Tue, 16 Jul 2013 13:14:42 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3B521F8438 for ; Tue, 16 Jul 2013 13:14: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; Tue, 16 Jul 2013 13:14:41 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" Thread-Topic: [stir] Rollout timeframe Thread-Index: AQHOgj0MegkF68FLTUyBdNmNASSKrplnd8uggACAIoD//44WoIAAn2YA//+RkoA= Date: Tue, 16 Jul 2013 20:14:41 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> In-Reply-To: <82C4B977-B099-479B-9FD3-5421788FF1A6@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.87] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_01A1_01CE823F.9327E960" MIME-Version: 1.0 Cc: "stir@ietf.org" , "kent@bbn.com" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 20:14:48 -0000 ------=_NextPart_000_01A1_01CE823F.9327E960 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Agree, but I was suggesting one CA operating for the national authority who knows via feedback from the delegation system what SP has each number. One CA One cert per number No chains. One place to look to validate. Your DNSSEC solution just defines how the central authority maintains its knowing of what SP owns what number. There are other technologies to store/maintain the {Tel#, SP name, SP public key | cert, User public key | cert} tuple. Delegation updates SP values, Assignment uses SP values to update User values. 15 digits: 1,000,000,000,000,000 = Peta numbers P T G M K And that is the whole E.164 number space, so at national level orders of magnitude less. Mike -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Tuesday, July 16, 2013 3:26 PM To: Michael Hammer Cc: kent@bbn.com; stir@ietf.org Subject: Re: [stir] Rollout timeframe On Jul 16, 2013, at 1:03 PM, Michael Hammer wrote: > The number portability DB in US is a trusted third party. > And you argue both sides, since any delegation from central authority is a third party, even an SP. > You would argue that having many more of them makes it more secure? > Experience also argues the more there are the harder to police. > > I see no difference in the DigiNotar case. That appeared to be an organizational failure. > That breach could have occurred with an SP as easily. > What "technical constraints" are you saying were not implemented? > I think Steven's point is that the web-pki model basically allows any trusted CA to claim any domain name, even though none of them are actually authoritative for domain name assignments. You can think of it as basically creating an alternate-root to DNS - an alternate authority of names - from an SSL/TLS-usage perspective. Since browsers trust ~160 CAs, the odds of a trusted CA screwing up not only became high, but once it happened it affected all domain names. It didn't just screw up the validity of domain names DigiNotar happens to certify, but it screwed up ALL of them, because no one knows what domain names DigitNotar could legitimately certify. With DNSSEC, however, the actual authority of domain name assignments is the same entity who actually signs stuff; they are not an alternate authority of names, they *are* the one-and-only authority of the name. If they screw up, they affect only the names signed by them (i.e., the names under their DNS tree branch). And if they screw up, "revocation" is fairly simple for them to perform and have take effect: they just change their DNSSEC entries. When it comes to STIR stuff, the point is we can't just trust third-party CAs to certify any E.164 number it cares to; because if they scrwe up, it affectes all E.164 numbers. We have to have some means of tying the certification to the authority that actually authoritatively assigns the numbers. So we need to know that a cert from carrier-X for number +1-603-555-1000 is signed by a CA that actually assigned carrier-X that E.164 number; which means we need to know what numbers the CA can assign - that it's authoritative for that role/decision. So... assuming we define some encoding scheme and mechanics for this E.164 stuff to be done in certs... we could have the ITU sign certs of country-code admins indicating the country-code number, and the country-code admins sign certs of carriers indicating the full number, and the carriers sign certs of their customer service providers, and them signing certs of enterprises or end-users. (or more likely we'd skip the ITU level one, and start with country-code level admins) But that would require a means of actually retrieving the correct cert, walking the chain of signers, retrieving each of their certs, and checking revocation lists. Meanwhile the caller has hung up the phone because it didn't ring. :) -hadriel ------=_NextPart_000_01A1_01CE823F.9327E960 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NjIwMTQ0MFowIwYJKoZIhvcNAQkEMRYEFNxcR6oclz63A+WGSgAUL+YapMlaMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAUir+YMKXu+xN3YUxrowIfX8bcwaj263+pfbGphO3 PVRqj3Gl6FZUlSUmvZrTPNJDPruZavAkGhQBHPHEi5Wyjlm2C+z8LCpoCRQQH4r24njBSHppl9mc Ko2fF6KeCFnOe4rbEOsWYSq2LdwYpl8LjxIGU5lZUwb81ct53tfgmTH/6wNfGq5T/iNbb7Qaxi+K 9xadgxnW3agpmrNwlXygxPOLZjF7DlSnBpQvnf09qqpc3tn6xssGdLRgvvQMkYNaqDYsbYiAjQO5 ooFUNAC93zCjSdUx2AhU0QCx+++YLNBAtRa7jwDI7VSWuuqXKT51IjNK43JSdEXqgvvI5YR2BgAA AAAAAA== ------=_NextPart_000_01A1_01CE823F.9327E960-- From hadriel.kaplan@oracle.com Tue Jul 16 13:21: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 6558E21E808B for ; Tue, 16 Jul 2013 13:21:08 -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 RdMXsQmRvw0E for ; Tue, 16 Jul 2013 13:21:00 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3105121E8064 for ; Tue, 16 Jul 2013 13:21:00 -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 r6GKKtip001327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Jul 2013 20:20: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 r6GKKrkI008781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 20:20:55 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6GKKrlQ008595; Tue, 16 Jul 2013 20:20:53 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 16 Jul 2013 13:20: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: Tue, 16 Jul 2013 16:20:52 -0400 Content-Transfer-Encoding: 7bit Message-Id: <21225AB4-3BDE-4162-B421-E0535C6463B7@oracle.com> References: <26E873F4-2595-4C75-8DF4-1050B3A53328@vigilsec.com> <51E5A599.5050102@dcrocker.net> To: Brian Rosen , Russ Housley X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: IETF STIR Mail List Subject: Re: [stir] DRAFT STIR BOF Agenda X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 20:21:09 -0000 Actually, what *is* Jon presenting on? draft-jennings-dispatch-rfc4474bis? -hadriel On Jul 16, 2013, at 4:05 PM, Brian Rosen wrote: > They are. Probably poor choice of topic wording. > > Brian > > On Jul 16, 2013, at 3:57 PM, Dave Crocker wrote: > >> On 7/16/2013 11:45 AM, Russ Housley wrote: >>> http://www.ietf.org/proceedings/87/agenda/agenda-87-stir >> >> >>> - Jon Peterson: inband solution >>> - Eric Rescorla: out-of-band solution >>> - Hadriel Kaplan: DNS-based solution >> >> >> I thought both Jon and Hadriel's proposals were "inband". >> >> 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 housley@vigilsec.com Tue Jul 16 13:21: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 D4A7621E8064 for ; Tue, 16 Jul 2013 13:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 IXZIJbXKOBqQ for ; Tue, 16 Jul 2013 13:21:45 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 27F3521E8056 for ; Tue, 16 Jul 2013 13:21:45 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 166C9F2407E; Tue, 16 Jul 2013 16:21:55 -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 Bd4Q9ox4AgS6; Tue, 16 Jul 2013 16:21:43 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-212-98.washdc.fios.verizon.net [96.241.212.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 72098F2407C; Tue, 16 Jul 2013 16:21:53 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <51E094AB.4000105@dcrocker.net> Date: Tue, 16 Jul 2013 16:21:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1085) Cc: IETF STIR Mail List Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 20:21:52 -0000 Dave: > Meta-point: >=20 > The text is only about authentication, but the discussion has been = about authorization. For example one might have an authenticated = originator value that is not the string displayed as Caller-ID.[*] I = understood the purpose of the wg to be ensuring that the displayed = string was authorized by its assignee. >=20 > If no one cares about this distinction and everyone feels that = "authenticate the originator" is sufficiently precise and accurate, = fine, but I thought it worth making sure. You are correct, and several people agreed with you. However, none of = you offered text. So, I have made a stab at updating the charter text = to address this point. I'll post it in a minute. >> to place calls using the identity. Expansion of the authentication >> mechanism to identities using the user@domain form should be = considered >> in the initial design, but the main focus of the working group is to >> develop a solution for telephone numbers. After completing the SIP = end >=20 > 'Considered...but main focus' essentially calls for solving the issue = in the current effort. >=20 > Instead: >=20 > Expansion of the authentication mechanism to identifiers using the = user@domain form is deferred. >=20 > This creates awareness of the issue and implies an intent to deal with = it (later). Okay, but if someone comes up with a clean way to tackle telephone = numbers and user@domain in a consistent fashion, I believe that would be = highly desirable. >> to end solution, the working group will consider session = establishment >> where there are one or more non-SIP hops, most likely using an >> out-of-band authentication mechanism. However, the in-band and >> out-of-band mechanisms should share as much in common as possible, >> especially the credentials. >=20 > These two draft sentence essentially require defining an out-of-band = mechanism; if they don't they are meaningless or a distraction. >=20 > Instead: >=20 > Consideration of out-of-band mechanisms, to deal with transit = across non-SIP hops, is deferred. I do not see consensus for this position. It is agree that an = end-to-end SIP session is the first priority. However, others have said = that an out-of-band solution is also needed to address the whole = problem. This is the second priority, and the charter text that I will = propose says: After completing the in-band mechanism, the working group will = consider session establishment where there are one or more non-SIP hops, most likely using an out-of-band authorization mechanism. However, the in-band and the out-of-band mechanisms should share as much in common = as possible, especially the credentials. >> - A fallback mechanism to allow out-of-band identity establishment >> during call setup >=20 > I thought there was agreement to drop this deliverable. It seems to = have crept back in. No. This is tied to the above. Russ From jon.peterson@neustar.biz Tue Jul 16 13:22: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 A277621E8056 for ; Tue, 16 Jul 2013 13:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.003 X-Spam-Level: X-Spam-Status: No, score=-106.003 tagged_above=-999 required=5 tests=[AWL=0.043, 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 0MLS1hJO6pk4 for ; Tue, 16 Jul 2013 13:22:03 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 5748121E8093 for ; Tue, 16 Jul 2013 13:21:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1374006625; x=1689361207; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=wrWzAalfp4 VO7Un5B3g20vu26tj1R6+Uv8MXYX55Pp4=; b=oSIJ3q9ayQMJj1vAqtvublhvW1 Z11/8/u3/ArgVAdls8IrMJY86sueFbZwU/A2OKHnA0pq5t2RuIXtQeZISr6Q== Received: from ([10.31.58.71]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.28051749; Tue, 16 Jul 2013 16:30: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; Tue, 16 Jul 2013 16:21:52 -0400 From: "Peterson, Jon" To: IETF STIR Mail List Thread-Topic: New Version Notification for draft-peterson-secure-origin-ps-01.txt Thread-Index: AQHOgYZqbMiNn3zUoUeMW4QmGU4p3JlnjtoA Date: Tue, 16 Jul 2013 20:21:51 +0000 Message-ID: In-Reply-To: <20130715180911.27969.65244.idtracker@ietfa.amsl.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: qL0KIWgEjHY7deokNHGeUQ== Content-Type: text/plain; charset="us-ascii" Content-ID: <0BAB74F6C7614349872930D68B72FA56@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [stir] FW: New Version Notification for draft-peterson-secure-origin-ps-01.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 20:22:07 -0000 We did iterate the secure origins problem statement draft in advance of the meeting. Aside from some minor edits, the change here is mostly the addition of some text towards a threat model. Jon Peterson Neustar, Inc. On 7/15/13 11:09 AM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-peterson-secure-origin-ps-01.txt >has been successfully submitted by Jon Peterson and posted to the >IETF repository. > >Filename: draft-peterson-secure-origin-ps >Revision: 01 >Title: Secure Origin Identification: Problem Statement, Threat Model, >Requirements, and Roadmap >Creation date: 2013-07-15 >Group: Individual Submission >Number of pages: 28 >URL: =20 >http://www.ietf.org/internet-drafts/draft-peterson-secure-origin-ps-01.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-peterson-secure-origin-ps >Htmlized: =20 >http://tools.ietf.org/html/draft-peterson-secure-origin-ps-01 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-peterson-secure-origin-ps-01 > >Abstract: > Over the past decade, SIP has become a major signaling protocol for > voice communications, one which has replaced many traditional > telephony deployments. However, interworking SIP with the > traditional telephone network has ultimately reduced the security of > Caller ID systems. Given the widespread interworking of SIP with the > telephone network, the lack of effective standards for identifying > the calling party in a SIP session has granted attackers new powers > as they impersonate or obscure calling party numbers when > orchestrating bulk commercial calling schemes, hacking voicemail > boxes or even circumventing multi-factor authentication systems > trusted by banks. This document therefore examines the reasons why > providing identity for telephone numbers on the Internet has proven > so difficult, and shows how changes in the last decade may provide us > with new strategies for attaching a secure identity to SIP sessions. > > =20 > =20 > > >The IETF Secretariat > From housley@vigilsec.com Tue Jul 16 13:34: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 D893421F9ED4 for ; Tue, 16 Jul 2013 13:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.028, 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 mAa3apNXh-cO for ; Tue, 16 Jul 2013 13:34:05 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 58AF821F9EC2 for ; Tue, 16 Jul 2013 13:34:02 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 6889CF240BA for ; Tue, 16 Jul 2013 16:34:33 -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 VO3uG1yZobU8 for ; Tue, 16 Jul 2013 16:33:58 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-212-98.washdc.fios.verizon.net [96.241.212.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 05B5AF2407E for ; Tue, 16 Jul 2013 16:34:27 -0400 (EDT) From: Russ Housley Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/mixed; boundary=Apple-Mail-100-562644282 Date: Tue, 16 Jul 2013 16:33:55 -0400 In-Reply-To: To: IETF STIR Mail List References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> Message-Id: <457ED3A0-D8D1-4420-A2C3-5B07B16AE641@vigilsec.com> X-Mailer: Apple Mail (2.1085) Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 20:34:11 -0000 --Apple-Mail-100-562644282 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have tried to pull all of the discussion into an updated charter. I = have also attached a diff to make it easier to review. Russ --Apple-Mail-100-562644282 Content-Disposition: attachment; filename=charter-stir-00-00bc.wdiff.html Content-Type: text/html; name="charter-stir-00-00bc.wdiff.html" Content-Transfer-Encoding: 7bit wdiff charter-stir-00-00b.txt charter-stir-00-00c.txt 

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

Chairs: TBD
Area Advisor: Richard Barnes

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

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.  As with email, the claimed source identity of a SIP
request is not verified, and this permits unauthorized use of source
identities as part of deceptive and coercive activities, such as
robocalling (bulk unsolicited commercial communications), vishing
(voicemail hacking, and impersonating banks) and swatting (impersonating
callers to emergency services to stimulate unwarranted large scale law
enforcement deployments).  This working group will define a deployable
mechanism to validate that verifies the identity authorization of the calling party that can be
verified by entities in the path of to use
a call. particular telephone number.

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

As its first work item, the working group will specify an in-band a SIP header-based
authorization mechanism to authenticate verify the originator of a SIP session where the
identity being authenticated is a
authorized to use the claimed source telephone number and number, where the session
is established with SIP end to end.  This is called an in-band mechanism.
The mechanism will use a canonical telephone number representation
specified by the working group, including any mappings that might be
needed between the SIP header fields and the canonical telephone number
representation.  The working group will consider choices for protecting the
identity information and the credentials used, but will likely be based on a
digital signature mechanism that covers a set of information in the SIP headers,
header fields, and verification will employ a credential that contains
the public key and is associated with the identity. one or more telephone numbers.
In order to be authoritative, credentials used with this mechanism will
be derived from existing telephone number assignment and delegation
models.  That is, when a telephone number or range of telephone numbers
is delegated to an entity, relevant credentials will be generated (or
modified) to reflect such delegation.  The mechanism must allow parties
who are not delegated a telephone number, but are preauthorized authorized by the
entity who is delegated the number, to place calls using the identity.  Expansion of the authentication
mechanism to identities using the user@domain form should be considered
in the initial design, but the main focus of the working group is to
develop a solution for telephone numbers.

After completing the SIP end
to end solution, in-band mechanism, the working group will consider
session establishment where there are one or more non-SIP hops, most
likely using an out-of-band authentication authorization mechanism.  However, the
in-band and the out-of-band mechanisms should share as much in common as
possible, especially the credentials.

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

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

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

Authenticated

Authentication and authorization of identity is closely linked to
privacy, and one these security features frequently
comes come at the cost of the other.
privacy.  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.

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

The working group will deliver the following:

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

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

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

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

Milestones

Sep 2013   Submit problem statement for Informational
Nov 2013   Submit in-band mechanism for Proposed Standard
Feb 2014   Submit credential specification for Proposed Standard
Jun 2014   Submit fallback for Proposed Standard
--Apple-Mail-100-562644282 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii = = = = = = = = = = Name: Secure Telephone Identity Revisited (stir) Area: RAI Chairs: TBD Area Advisor: Richard Barnes Mailing list: stir@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/stir 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. As with email, the claimed source identity of a SIP request is not verified, and this permits unauthorized use of source identities as part of deceptive and coercive activities, such as robocalling (bulk unsolicited commercial communications), vishing (voicemail hacking, and impersonating banks) and swatting (impersonating callers to emergency services to stimulate unwarranted large scale law enforcement deployments). This working group will define a deployable mechanism that verifies the authorization of the calling party to use a particular telephone number. SIP is one of the main VoIP technologies used by parties that want to present an incorrect origin, in this context an origin telephone number. Several previous efforts have tried to secure the origins of SIP communications, including RFC 3325, RFC 4474, and the VIPR working group. To date, however, true validation of the source of SIP calls has not seen any appreciable deployment. Several factors contributed to this lack of success, including: failure of the problem to be seen as critical at the time; lack of any technical means of producing a proof of authority over telephone numbers; misalignment of the mechanisms proposed by RFC 4474 with the complex deployment environment that has emerged for SIP; lack of end-to-end SIP session establishment; and inherent operational problems with a transitive trust model. To make deployment of this solution more likely, consideration must be given to latency, real-time performance, computational overhead, and administrative overhead for the legitimate call source and all verifiers. As its first work item, the working group will specify a SIP header-based authorization mechanism to verify the originator of a SIP session is authorized to use the claimed source telephone number, where the session is established with SIP end to end. This is called an in-band mechanism. The mechanism will use a canonical telephone number representation specified by the working group, including any mappings that might be needed between the SIP header fields and the canonical telephone number representation. The working group will consider choices for protecting identity information and credentials used, but will likely be based on a digital signature mechanism that covers a set of information in the SIP header fields, and verification will employ a credential that contains the public key and is associated with the one or more telephone numbers. In order to be authoritative, credentials used with this mechanism will be derived from existing telephone number assignment and delegation models. That is, when a telephone number or range of telephone numbers is delegated to an entity, relevant credentials will be generated (or modified) to reflect such delegation. The mechanism must allow parties who are not delegated a telephone number, but are authorized by the entity who is delegated the number, to place calls using the identity. After completing the in-band mechanism, the working group will consider session establishment where there are one or more non-SIP hops, most likely using an out-of-band authorization mechanism. However, the in-band and the out-of-band mechanisms should share as much in common as possible, especially the credentials. Expansion of the authorization mechanism to identities using the user@domain form deferred since the main focus of the working group is to develop a solution for telephone numbers. The working group will coordinate with the Security Area on credential management. The working group will coordinate with other working groups in the RAI Area regarding signaling through existing deployments. Authentication and authorization of identity is closely linked to privacy, and these security features frequently come at the cost of privacy. 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. 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 The working group will deliver the following: - A problem statement detailing the deployment environment and situation that motivate work on secure telephone identity - A mechanism document describing the SIP end-to-end with telephone number-based identities - A document describing the credentials required to support telephone number identity authentication - A fallback mechanism to allow out-of-band identity establishment during call setup Milestones Sep 2013 Submit problem statement for Informational Nov 2013 Submit in-band mechanism for Proposed Standard Feb 2014 Submit credential specification for Proposed Standard Jun 2014 Submit fallback for Proposed Standard --Apple-Mail-100-562644282-- From Henning.Schulzrinne@fcc.gov Tue Jul 16 13:53: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 1D10421E808B for ; Tue, 16 Jul 2013 13:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.059 X-Spam-Level: X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=0.540, 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 RvPHUiv-DH9z for ; Tue, 16 Jul 2013 13:52:58 -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 1ED7421F9FFC for ; Tue, 16 Jul 2013 13:52:55 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Michael Hammer , "hadriel.kaplan@oracle.com" Thread-Topic: [stir] Rollout timeframe Thread-Index: AQHOgj0M7qXit7Q26EG36sN0YCvrSJlnvRAAgAAIk4CAAAXGgIAAJ7UAgAANq4D//8Hhhw== Date: Tue, 16 Jul 2013 20:52:53 +0000 References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com>, <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 20:53:12 -0000 I'm not sure this is what you have in mind, but to elaborate a bit:=0A= =0A= I suspect that for both the DNS and other database solutions, as well as ce= rts, you can do something like the following:=0A= =0A= * The carrier of record for a number block has credentials with the nationa= l DB operator, whether a cert or simply a password. (For simplicity, I assu= me one such operator, which appears to be common in most jurisdictions. If = multiple, add a level of indirection.)=0A= =0A= * The carrier of record takes a request from their customer containing a pu= blic key and says to the DB operator: "Hi, DB operator, please issue a cert= for the public key for this number out of my block". DB operator complies = and signs public key. No need to reveal who the public key belongs to.=0A= =0A= * Signing requests get chained up, i.e., the end user sends a request to th= eir provider, who turns around and contacts theirs, etc. Add OAuth to taste= .=0A= =0A= There is no need to trace the delegation chain in real time for validation = - every cert is signed by the DB operator.=0A= =0A= There is no need for a single protocol to do the requests, although that's = obviously a good thing to have for automated provisioning. Fax and ftp will= do, if needed, since the interoperability is local to the carrier and its = customers.=0A= =0A= If somebody screws up, they can only screw up their own number range. A cus= tomer down the chain needs to trust everybody up the chain, but that's true= today - if the carrier re-assigns your number to somebody else or two part= ies, you will have at least a few miserable days getting it straightened ou= t. We do get those types of complaints, apparently more so recently.=0A= =0A= Henning=0A= ________________________________________=0A= From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Michael Ha= mmer [michael.hammer@yaanatech.com]=0A= Sent: Tuesday, July 16, 2013 4:14 PM=0A= To: hadriel.kaplan@oracle.com=0A= Cc: stir@ietf.org; kent@bbn.com=0A= Subject: Re: [stir] Rollout timeframe=0A= =0A= Agree, but I was suggesting one CA operating for the national authority=0A= who knows via feedback from the delegation system what SP has each number.= =0A= One CA=0A= One cert per number=0A= No chains.=0A= One place to look to validate.=0A= =0A= Your DNSSEC solution just defines how the central authority maintains its= =0A= knowing of what SP owns what number.=0A= There are other technologies to store/maintain the {Tel#, SP name, SP publi= c=0A= key | cert, User public key | cert} tuple.=0A= Delegation updates SP values, Assignment uses SP values to update User=0A= values.=0A= =0A= 15 digits:=0A= 1,000,000,000,000,000 =3D Peta numbers=0A= P T G M K=0A= =0A= And that is the whole E.164 number space, so at national level orders of=0A= magnitude less.=0A= =0A= Mike=0A= =0A= =0A= -----Original Message-----=0A= From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com]=0A= Sent: Tuesday, July 16, 2013 3:26 PM=0A= To: Michael Hammer=0A= Cc: kent@bbn.com; stir@ietf.org=0A= Subject: Re: [stir] Rollout timeframe=0A= =0A= =0A= On Jul 16, 2013, at 1:03 PM, Michael Hammer = =0A= wrote:=0A= =0A= > The number portability DB in US is a trusted third party.=0A= > And you argue both sides, since any delegation from central authority is = a=0A= third party, even an SP.=0A= > You would argue that having many more of them makes it more secure?=0A= > Experience also argues the more there are the harder to police.=0A= >=0A= > I see no difference in the DigiNotar case. That appeared to be an=0A= organizational failure.=0A= > That breach could have occurred with an SP as easily.=0A= > What "technical constraints" are you saying were not implemented?=0A= >=0A= =0A= I think Steven's point is that the web-pki model basically allows any=0A= trusted CA to claim any domain name, even though none of them are actually= =0A= authoritative for domain name assignments. You can think of it as basicall= y=0A= creating an alternate-root to DNS - an alternate authority of names - from= =0A= an SSL/TLS-usage perspective.=0A= =0A= Since browsers trust ~160 CAs, the odds of a trusted CA screwing up not onl= y=0A= became high, but once it happened it affected all domain names. It didn't= =0A= just screw up the validity of domain names DigiNotar happens to certify, bu= t=0A= it screwed up ALL of them, because no one knows what domain names DigitNota= r=0A= could legitimately certify. With DNSSEC, however, the actual authority of= =0A= domain name assignments is the same entity who actually signs stuff; they= =0A= are not an alternate authority of names, they *are* the one-and-only=0A= authority of the name. If they screw up, they affect only the names signed= =0A= by them (i.e., the names under their DNS tree branch). And if they screw= =0A= up, "revocation" is fairly simple for them to perform and have take effect:= =0A= they just change their DNSSEC entries.=0A= =0A= When it comes to STIR stuff, the point is we can't just trust third-party= =0A= CAs to certify any E.164 number it cares to; because if they scrwe up, it= =0A= affectes all E.164 numbers. We have to have some means of tying the=0A= certification to the authority that actually authoritatively assigns the=0A= numbers. So we need to know that a cert from carrier-X for number=0A= +1-603-555-1000 is signed by a CA that actually assigned carrier-X that=0A= E.164 number; which means we need to know what numbers the CA can assign -= =0A= that it's authoritative for that role/decision.=0A= =0A= So... assuming we define some encoding scheme and mechanics for this E.164= =0A= stuff to be done in certs... we could have the ITU sign certs of=0A= country-code admins indicating the country-code number, and the country-cod= e=0A= admins sign certs of carriers indicating the full number, and the carriers= =0A= sign certs of their customer service providers, and them signing certs of= =0A= enterprises or end-users. (or more likely we'd skip the ITU level one, and= =0A= start with country-code level admins)=0A= =0A= But that would require a means of actually retrieving the correct cert,=0A= walking the chain of signers, retrieving each of their certs, and checking= =0A= revocation lists. Meanwhile the caller has hung up the phone because it=0A= didn't ring. :)=0A= =0A= -hadriel=0A= =0A= From hadriel.kaplan@oracle.com Tue Jul 16 13:53: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 CA05821F9FF3 for ; Tue, 16 Jul 2013 13:53:19 -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 BPmd4j0X7h9N for ; Tue, 16 Jul 2013 13:53:13 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id E49D721F9FFC for ; Tue, 16 Jul 2013 13:53:12 -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 r6GKrAsp023828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Jul 2013 20:53:11 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 r6GKr9av020991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 20:53:10 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 r6GKr95b016396; Tue, 16 Jul 2013 20:53:09 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 16 Jul 2013 13:53: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: Tue, 16 Jul 2013 16:53:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <26DCAC7F-7B6D-44F0-92F5-8BE3F43E8DD3@oracle.com> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> To: Russ Housley X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: IETF STIR Mail List Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 20:53:20 -0000 On Jul 16, 2013, at 4:21 PM, Russ Housley wrote: >> These two draft sentence essentially require defining an out-of-band = mechanism; if they don't they are meaningless or a distraction. >>=20 >> Instead: >>=20 >> Consideration of out-of-band mechanisms, to deal with transit = across non-SIP hops, is deferred. >=20 > I do not see consensus for this position. It is agree that an = end-to-end SIP session is the first priority. However, others have said = that an out-of-band solution is also needed to address the whole = problem. This is the second priority, and the charter text that I will = propose says: >=20 If the chairs are going to be fair, I don't think there's a consensus = for the opposite case *either*. We are not a Working Group yet, and = there is no existing charter of a Working Group yet. The current = charter is an empty page. Thus we need consensus to put something *in* = a new charter, as much as we need to remove something from one. In = fact, I'd argue you need far stronger consensus to put something *in* a = new charter, than you do to keep something out. Be that as it may, I think it's clear we'll be debating this issue in = the BOF. I don't see enough time for doing that - 30 minutes for = charter debate isn't long when you know in advance there'll be heated = debate. I'm happy to give up my presentation time slot, to give more time for = the debate. Maybe the chairs could also write up a script of what we're each going = to say in advance. You only need to copy from the emails we've already = sent. That way we'd save on time, and even have the minutes already = documented. :) -hadriel From hadriel.kaplan@oracle.com Tue Jul 16 14:08: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 7732A21F9EA9 for ; Tue, 16 Jul 2013 14:08:12 -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 0V1KGyIUyoN4 for ; Tue, 16 Jul 2013 14:08:05 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9339021F9E7E for ; Tue, 16 Jul 2013 14:08:05 -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 r6GL83ZK015959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Jul 2013 21:08: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 r6GL81QE029936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 21:08:02 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6GL815V014022; Tue, 16 Jul 2013 21:08:01 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 16 Jul 2013 14:08: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: Date: Tue, 16 Jul 2013 17:07:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <084261CE-3F4D-48CE-A5BA-7B9A37E94351@oracle.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com>, <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "stir@ietf.org" , Michael Hammer Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 21:08:12 -0000 Yup, that's basically what CIDER proposes happens. Except it skips the = part about needing to get back a cert, or even having certs, because = they're useless and unnecessary overhead and just something more that = can go wrong. Many people in the IETF love them - most developers and = especially admins trying to use them hate them, afaict. -hadriel p.s. And the CIDER draft does have an appendix on requirements for the = public-key provisioning protocol part, even though you could obviously = do it with email or fax or a web-portal or whatever. On Jul 16, 2013, at 4:52 PM, Henning Schulzrinne = wrote: > I'm not sure this is what you have in mind, but to elaborate a bit: >=20 > I suspect that for both the DNS and other database solutions, as well = as certs, you can do something like the following: >=20 > * The carrier of record for a number block has credentials with the = national DB operator, whether a cert or simply a password. (For = simplicity, I assume one such operator, which appears to be common in = most jurisdictions. If multiple, add a level of indirection.) >=20 > * The carrier of record takes a request from their customer containing = a public key and says to the DB operator: "Hi, DB operator, please issue = a cert for the public key for this number out of my block". DB operator = complies and signs public key. No need to reveal who the public key = belongs to. >=20 > * Signing requests get chained up, i.e., the end user sends a request = to their provider, who turns around and contacts theirs, etc. Add OAuth = to taste. >=20 > There is no need to trace the delegation chain in real time for = validation - every cert is signed by the DB operator. >=20 > There is no need for a single protocol to do the requests, although = that's obviously a good thing to have for automated provisioning. Fax = and ftp will do, if needed, since the interoperability is local to the = carrier and its customers. >=20 > If somebody screws up, they can only screw up their own number range. = A customer down the chain needs to trust everybody up the chain, but = that's true today - if the carrier re-assigns your number to somebody = else or two parties, you will have at least a few miserable days getting = it straightened out. We do get those types of complaints, apparently = more so recently. >=20 > Henning > ________________________________________ > From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of = Michael Hammer [michael.hammer@yaanatech.com] > Sent: Tuesday, July 16, 2013 4:14 PM > To: hadriel.kaplan@oracle.com > Cc: stir@ietf.org; kent@bbn.com > Subject: Re: [stir] Rollout timeframe >=20 > Agree, but I was suggesting one CA operating for the national = authority > who knows via feedback from the delegation system what SP has each = number. > One CA > One cert per number > No chains. > One place to look to validate. >=20 > Your DNSSEC solution just defines how the central authority maintains = its > knowing of what SP owns what number. > There are other technologies to store/maintain the {Tel#, SP name, SP = public > key | cert, User public key | cert} tuple. > Delegation updates SP values, Assignment uses SP values to update User > values. >=20 > 15 digits: > 1,000,000,000,000,000 =3D Peta numbers > P T G M K >=20 > And that is the whole E.164 number space, so at national level orders = of > magnitude less. >=20 > Mike >=20 >=20 > -----Original Message----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > Sent: Tuesday, July 16, 2013 3:26 PM > To: Michael Hammer > Cc: kent@bbn.com; stir@ietf.org > Subject: Re: [stir] Rollout timeframe >=20 >=20 > On Jul 16, 2013, at 1:03 PM, Michael Hammer = > wrote: >=20 >> The number portability DB in US is a trusted third party. >> And you argue both sides, since any delegation from central authority = is a > third party, even an SP. >> You would argue that having many more of them makes it more secure? >> Experience also argues the more there are the harder to police. >>=20 >> I see no difference in the DigiNotar case. That appeared to be an > organizational failure. >> That breach could have occurred with an SP as easily. >> What "technical constraints" are you saying were not implemented? >>=20 >=20 > I think Steven's point is that the web-pki model basically allows any > trusted CA to claim any domain name, even though none of them are = actually > authoritative for domain name assignments. You can think of it as = basically > creating an alternate-root to DNS - an alternate authority of names - = from > an SSL/TLS-usage perspective. >=20 > Since browsers trust ~160 CAs, the odds of a trusted CA screwing up = not only > became high, but once it happened it affected all domain names. It = didn't > just screw up the validity of domain names DigiNotar happens to = certify, but > it screwed up ALL of them, because no one knows what domain names = DigitNotar > could legitimately certify. With DNSSEC, however, the actual = authority of > domain name assignments is the same entity who actually signs stuff; = they > are not an alternate authority of names, they *are* the one-and-only > authority of the name. If they screw up, they affect only the names = signed > by them (i.e., the names under their DNS tree branch). And if they = screw > up, "revocation" is fairly simple for them to perform and have take = effect: > they just change their DNSSEC entries. >=20 > When it comes to STIR stuff, the point is we can't just trust = third-party > CAs to certify any E.164 number it cares to; because if they scrwe up, = it > affectes all E.164 numbers. We have to have some means of tying the > certification to the authority that actually authoritatively assigns = the > numbers. So we need to know that a cert from carrier-X for number > +1-603-555-1000 is signed by a CA that actually assigned carrier-X = that > E.164 number; which means we need to know what numbers the CA can = assign - > that it's authoritative for that role/decision. >=20 > So... assuming we define some encoding scheme and mechanics for this = E.164 > stuff to be done in certs... we could have the ITU sign certs of > country-code admins indicating the country-code number, and the = country-code > admins sign certs of carriers indicating the full number, and the = carriers > sign certs of their customer service providers, and them signing certs = of > enterprises or end-users. (or more likely we'd skip the ITU level = one, and > start with country-code level admins) >=20 > But that would require a means of actually retrieving the correct = cert, > walking the chain of signers, retrieving each of their certs, and = checking > revocation lists. Meanwhile the caller has hung up the phone because = it > didn't ring. :) >=20 > -hadriel >=20 From richard@shockey.us Tue Jul 16 14:38: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 CA03921F9AE6 for ; Tue, 16 Jul 2013 14:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.913 X-Spam-Level: X-Spam-Status: No, score=-101.913 tagged_above=-999 required=5 tests=[AWL=0.352, 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 D3yMmnjH6Wgo for ; Tue, 16 Jul 2013 14:38:25 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 3C77A21F9ABB for ; Tue, 16 Jul 2013 14:38:25 -0700 (PDT) Received: (qmail 7507 invoked by uid 0); 16 Jul 2013 21:38:24 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy14.unifiedlayer.com with SMTP; 16 Jul 2013 21:38:24 -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=PJnuA8i603HRwoRv+uQVCiJeyFY4fCwzWgY+P4JCcl4=; b=MzSXdk8JaRFDngKb3spn4jp2OLfwLfXETalr/L8tDH6vD0pxnncVjYEWa5HxLTQOvF4jYUoipAxnfTWZHigN/iJ3yi7g9dErm/iRIJv2b7Z2becIf3b3Eu57sgChIUlP; Received: from [72.66.111.124] (port=56295 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UzCwx-00082Q-I4; Tue, 16 Jul 2013 15:38:23 -0600 From: "Richard Shockey" To: "'Brian Rosen'" , "'Stephen Kent'" References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <51E565A2.80806@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17EE8@EX2K10MB1.corp.yaanatech.com> <51E56EFE.5040106@bbn.com> <30AC5063-E6F6-4230-98B0-3A52D8EF71CA@brianrosen.net> <51E59C3B.9080906@bbn.com> <0B0C46A1-5582-42E6-A6F9-76C1526AF2C5@brianrosen.net> In-Reply-To: <0B0C46A1-5582-42E6-A6F9-76C1526AF2C5@brianrosen.net> Date: Tue, 16 Jul 2013 17:38:19 -0400 Message-ID: <022d01ce826c$cbe8bef0$63ba3cd0$@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: AQL/BCbN34pvssG/zmP8Y9dsYJE+5AHGECHJAXjKTQcCVaaUMAHzMIkXAW9TyhQCEOZjQADGdqIoAsWzo9QCsZtIdQJoOSwgAhnVAaQBvIeLbwI/LTUVATb7nDCWLvtpYA== 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, 'Michael Hammer' Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 21:38:42 -0000 After my 2nd cocktail. Why don't we in +1 just call up the NSA and the Communications Security Establishment Canada and suggests they take over joint CA responsibility for the NANP. The have the money a certain "technical expertise". They already have our call detail records. If they could stop Call Spoofing they would be extremely popular with the public. It's a joke ..sort of .. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Tuesday, July 16, 2013 3:40 PM To: Stephen Kent Cc: stir@ietf.org; Michael Hammer Subject: Re: [stir] Rollout timeframe In the U.S., there may be many delegations in a path from the North American Number Plan Administrator to the user that has the number. Only the first two of these are captured in the formal delegation databases - NANPA allocates a NPA (area code) to the Pooling Administrator, which delegates a 1000 number block to a carrier. That carrier may resell 100 numbers to a SIP provider, who resells 20 of them to another SIP provider who sells 10 of them to an enterprise, who allocates one of those to an employee. At each step in the delegation (possibly save the last one), there could theoretically be a credential issued. I would not want to verify the validity of all of these individually to check a source identity. Ideally, I'd like to go one place and be able to get one credential that is authoritative for the number. That seems possible, even when we have the credential path follow the delegation path. I hear you on data size. But remember, an exabyte hear and an exabyte there, and pretty soon, we're talking real big data stores. Brian On Jul 16, 2013, at 3:17 PM, Stephen Kent wrote: > Brian, > >> I think the credential path follows the delegation path, but I hope that in most deployments, we're not chasing a chain of credentials to validate. > I don't know what you mean by the statement above. Do you mean that > you hope cert paths (or a DNSSEC equivalent) will be short, that most > of tbe data will change slowly enough that caching will be a big win, or what? >> Ultimately, remember the math Henning did - even with cert per TN, it's still not a whole lot of data. > These days very few things that I imagine dealing with amount to a "whole lot of data" :-) . > > Steve > _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From br@brianrosen.net Tue Jul 16 14:41: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 1E0E721F9C4C for ; Tue, 16 Jul 2013 14:41:47 -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 CurKFl6V6Y1t for ; Tue, 16 Jul 2013 14:41:42 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 809AC21F9A26 for ; Tue, 16 Jul 2013 14:41: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=P7EGjL2VNZBRF2bJ+PL4io9QsrHvIGt42K0pOKKHiOE=; b=gD1IHGGR9P9mNWHwIDbMMQXXv6eafOfATb61ZXZB2YuHOOMn4Zebj0L27hjme9uwgpNaxIS2Zmmiwsg3Vxl8132tYdsr9y1tYDWGnMp0+zy7Be1HLMyMLEWDn1s9sfFi6yljApcudOsCWBJbkR+ERE2gz66MStlhMce35xWHTxE=; Received: from neustargw.va.neustar.com ([209.173.53.233]:46866 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UzD09-0002DO-6E; Tue, 16 Jul 2013 17:41: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: <022d01ce826c$cbe8bef0$63ba3cd0$@shockey.us> Date: Tue, 16 Jul 2013 17:41:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <51E565A2.80806@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17EE8@EX2K10MB1.corp.yaanatech.com> <51E56EFE.5040106@bbn.com> <30AC5063-E6F6-4230-98B0-3A52D8EF71CA@brianrosen.net> <51E59C3B.9080906@bbn.com> <0B0C46A1-5582-42E6-A6F9-76C1526AF2C5@brianrosen.net> <022d01ce826c$cbe8bef0$63ba3cd0$@shockey.us> To: Richard Shockey 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, 'Michael Hammer' , 'Stephen Kent' Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 21:41:47 -0000 Sure, why not? They would jump on it, because it gives them real time call set up time = data, not after-the-fact billing data. Brian On Jul 16, 2013, at 5:38 PM, Richard Shockey wrote: > After my 2nd cocktail. >=20 > Why don't we in +1 just call up the NSA and the Communications = Security > Establishment Canada and suggests they take over joint CA = responsibility for > the NANP.=20 >=20 > The have the money a certain "technical expertise". They already have = our > call detail records. If they could stop Call Spoofing they would = be > extremely popular with the public. =20 >=20 > It's a joke ..sort of .. =20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of > Brian Rosen > Sent: Tuesday, July 16, 2013 3:40 PM > To: Stephen Kent > Cc: stir@ietf.org; Michael Hammer > Subject: Re: [stir] Rollout timeframe >=20 > In the U.S., there may be many delegations in a path from the North = American > Number Plan Administrator to the user that has the number. Only the = first > two of these are captured in the formal delegation databases - NANPA > allocates a NPA (area code) to the Pooling Administrator, which = delegates a > 1000 number block to a carrier. >=20 > That carrier may resell 100 numbers to a SIP provider, who resells 20 = of > them to another SIP provider who sells 10 of them to an enterprise, = who > allocates one of those to an employee. >=20 > At each step in the delegation (possibly save the last one), there = could > theoretically be a credential issued. >=20 > I would not want to verify the validity of all of these individually = to > check a source identity. >=20 > Ideally, I'd like to go one place and be able to get one credential = that is > authoritative for the number. >=20 > That seems possible, even when we have the credential path follow the > delegation path. >=20 > I hear you on data size. But remember, an exabyte hear and an exabyte > there, and pretty soon, we're talking real big data stores. >=20 > Brian >=20 > On Jul 16, 2013, at 3:17 PM, Stephen Kent wrote: >=20 >> Brian, >>=20 >>> I think the credential path follows the delegation path, but I hope = that > in most deployments, we're not chasing a chain of credentials to = validate. >> I don't know what you mean by the statement above. Do you mean that=20= >> you hope cert paths (or a DNSSEC equivalent) will be short, that most=20= >> of tbe data will change slowly enough that caching will be a big win, = or > what? >>> Ultimately, remember the math Henning did - even with cert per TN, = it's > still not a whole lot of data. >> These days very few things that I imagine dealing with amount to a = "whole > lot of data" :-) . >>=20 >> Steve >>=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 From michael.hammer@yaanatech.com Tue Jul 16 14:51: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 E298121F9E5C for ; Tue, 16 Jul 2013 14:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 n14zAwg44NEk for ; Tue, 16 Jul 2013 14:51: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 98D7E21E804E for ; Tue, 16 Jul 2013 14:51: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, 16 Jul 2013 14:51:45 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" , "Henning.Schulzrinne@fcc.gov" Thread-Topic: [stir] Rollout timeframe Thread-Index: AQHOgj0MegkF68FLTUyBdNmNASSKrplnd8uggACAIoD//44WoIAAn2YA//+RkoCAAIbFgIAABDiA//+PiAA= Date: Tue, 16 Jul 2013 21:51:45 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC18417@EX2K10MB1.corp.yaanatech.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com>, <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <084261CE-3F4D-48CE-A5BA-7B9A37E94351@oracle.com> In-Reply-To: <084261CE-3F4D-48CE-A5BA-7B9A37E94351@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.87] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_01DB_01CE824D.2255E3F0" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 21:51:52 -0000 ------=_NextPart_000_01DB_01CE824D.2255E3F0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Yes, much along those lines. However, unlike CIDER, you don't need secret trees that have limited access, and no privacy concerns. The certificates can be promiscuously distributed, and can be validated by also having the well-known DB cert. You can even have the cert send in-band, with no query to the DNS. And how to validate a cert is well known. The DB operator has credentials for all the carriers of record. That can be many if the delegation cuts out some levels of middlemen and CoR is more granular, but still doable. A standard process to register a Tel#/public key pair and get a cert between carrier of record and DB should not be hard. How the carrier of record manages the creation of public keys and pairing with telephone numbers and manages that with their customers does not need to be standardized. (Note, the carrier could even create those pairings in advance and register them with the DB in advance, and distribute only to users when assigning to users. If you trust the carrier to administer the number, no reason not to trust them to administer the private key/cert distribution.) If one wanted the end-user to generate the Tel#/private key pair, the CoR could ask them to generate that and submit the public key up hop-by-hop through the SP chain to the CoR that registers it and returns a cert. What gets signed and what passes E2E in-band is still an issue, but at least a trust basis would be in place. And presumable, the SPs that support it won't turn around and circumvent it by stripping out supporting E2E headers. Mike -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Tuesday, July 16, 2013 5:08 PM To: Henning Schulzrinne Cc: Michael Hammer; stir@ietf.org Subject: Re: [stir] Rollout timeframe Yup, that's basically what CIDER proposes happens. Except it skips the part about needing to get back a cert, or even having certs, because they're useless and unnecessary overhead and just something more that can go wrong. Many people in the IETF love them - most developers and especially admins trying to use them hate them, afaict. -hadriel p.s. And the CIDER draft does have an appendix on requirements for the public-key provisioning protocol part, even though you could obviously do it with email or fax or a web-portal or whatever. On Jul 16, 2013, at 4:52 PM, Henning Schulzrinne wrote: > I'm not sure this is what you have in mind, but to elaborate a bit: > > I suspect that for both the DNS and other database solutions, as well as certs, you can do something like the following: > > * The carrier of record for a number block has credentials with the > national DB operator, whether a cert or simply a password. (For > simplicity, I assume one such operator, which appears to be common in > most jurisdictions. If multiple, add a level of indirection.) > > * The carrier of record takes a request from their customer containing a public key and says to the DB operator: "Hi, DB operator, please issue a cert for the public key for this number out of my block". DB operator complies and signs public key. No need to reveal who the public key belongs to. > > * Signing requests get chained up, i.e., the end user sends a request to their provider, who turns around and contacts theirs, etc. Add OAuth to taste. > > There is no need to trace the delegation chain in real time for validation - every cert is signed by the DB operator. > > There is no need for a single protocol to do the requests, although that's obviously a good thing to have for automated provisioning. Fax and ftp will do, if needed, since the interoperability is local to the carrier and its customers. > > If somebody screws up, they can only screw up their own number range. A customer down the chain needs to trust everybody up the chain, but that's true today - if the carrier re-assigns your number to somebody else or two parties, you will have at least a few miserable days getting it straightened out. We do get those types of complaints, apparently more so recently. > > Henning > ________________________________________ > From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of > Michael Hammer [michael.hammer@yaanatech.com] > Sent: Tuesday, July 16, 2013 4:14 PM > To: hadriel.kaplan@oracle.com > Cc: stir@ietf.org; kent@bbn.com > Subject: Re: [stir] Rollout timeframe > > Agree, but I was suggesting one CA operating for the national > authority who knows via feedback from the delegation system what SP has each number. > One CA > One cert per number > No chains. > One place to look to validate. > > Your DNSSEC solution just defines how the central authority maintains > its knowing of what SP owns what number. > There are other technologies to store/maintain the {Tel#, SP name, SP > public key | cert, User public key | cert} tuple. > Delegation updates SP values, Assignment uses SP values to update User > values. > > 15 digits: > 1,000,000,000,000,000 = Peta numbers > P T G M K > > And that is the whole E.164 number space, so at national level orders > of magnitude less. > > Mike > > > -----Original Message----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > Sent: Tuesday, July 16, 2013 3:26 PM > To: Michael Hammer > Cc: kent@bbn.com; stir@ietf.org > Subject: Re: [stir] Rollout timeframe > > > On Jul 16, 2013, at 1:03 PM, Michael Hammer > > wrote: > >> The number portability DB in US is a trusted third party. >> And you argue both sides, since any delegation from central authority >> is a > third party, even an SP. >> You would argue that having many more of them makes it more secure? >> Experience also argues the more there are the harder to police. >> >> I see no difference in the DigiNotar case. That appeared to be an > organizational failure. >> That breach could have occurred with an SP as easily. >> What "technical constraints" are you saying were not implemented? >> > > I think Steven's point is that the web-pki model basically allows any > trusted CA to claim any domain name, even though none of them are > actually authoritative for domain name assignments. You can think of > it as basically creating an alternate-root to DNS - an alternate > authority of names - from an SSL/TLS-usage perspective. > > Since browsers trust ~160 CAs, the odds of a trusted CA screwing up > not only became high, but once it happened it affected all domain > names. It didn't just screw up the validity of domain names DigiNotar > happens to certify, but it screwed up ALL of them, because no one > knows what domain names DigitNotar could legitimately certify. With > DNSSEC, however, the actual authority of domain name assignments is > the same entity who actually signs stuff; they are not an alternate > authority of names, they *are* the one-and-only authority of the name. > If they screw up, they affect only the names signed by them (i.e., the > names under their DNS tree branch). And if they screw up, "revocation" is fairly simple for them to perform and have take effect: > they just change their DNSSEC entries. > > When it comes to STIR stuff, the point is we can't just trust > third-party CAs to certify any E.164 number it cares to; because if > they scrwe up, it affectes all E.164 numbers. We have to have some > means of tying the certification to the authority that actually > authoritatively assigns the numbers. So we need to know that a cert > from carrier-X for number > +1-603-555-1000 is signed by a CA that actually assigned carrier-X > +that > E.164 number; which means we need to know what numbers the CA can > assign - that it's authoritative for that role/decision. > > So... assuming we define some encoding scheme and mechanics for this > E.164 stuff to be done in certs... we could have the ITU sign certs of > country-code admins indicating the country-code number, and the > country-code admins sign certs of carriers indicating the full number, > and the carriers sign certs of their customer service providers, and > them signing certs of enterprises or end-users. (or more likely we'd > skip the ITU level one, and start with country-code level admins) > > But that would require a means of actually retrieving the correct > cert, walking the chain of signers, retrieving each of their certs, > and checking revocation lists. Meanwhile the caller has hung up the > phone because it didn't ring. :) > > -hadriel > ------=_NextPart_000_01DB_01CE824D.2255E3F0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NjIxNTE0NFowIwYJKoZIhvcNAQkEMRYEFPKQyZIGqOqRkgod/vly+I/u7hpCMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAZN1jvQXQSz0UWcxhyM3fx3lP+9wMvLH7SiTZRS+q /aT7yuZXdxDaSbREKkx7Obn9EH53l8soUbdtsVnku62JC19ITIo3ERgvoj8z7aE95p7Ytmx/uN+e vLngk8xPPhEqIPP/QM82Mq8jYwH4MtT6pIqU5XbOdDu0fxg10sSlrYi4zD0MqjebqUq/W0t1EooE 9nm/bGLH4lhRor046uwjJN3caWwaoSMkgW6URcBfygn3PQqloPKR2eWj6Sws6AvIZ8rQTp/lWpNw vZI5gJRAVJC6g4S2riJipwxriQjvymgSxiqW/r+7gsEtZgWtp1S1T5nMMdSYT0PLqtUVycxeOwAA AAAAAA== ------=_NextPart_000_01DB_01CE824D.2255E3F0-- From michael.hammer@yaanatech.com Tue Jul 16 15:34: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 56F7921F99C7 for ; Tue, 16 Jul 2013 15:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 yqBPho09QTWp for ; Tue, 16 Jul 2013 15:34: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 0970521F8C11 for ; Tue, 16 Jul 2013 15:34:02 -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, 16 Jul 2013 15:34:01 -0700 From: Michael Hammer To: "housley@vigilsec.com" , "stir@ietf.org" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIBWXEGbn3ibkCpY0NkPYfuGZlgOFKAgAAEgQCAAANtAIAAAaEAgAAGyYCAAAH7AIAABkaA//+MAvCAAISOAIAAAhCAgADroICAAEL9gIAAAeEAgABhRACAAB8HgIAADPeAgAAKzoCABhDlgIAAA2uA//+j5WA= Date: Tue, 16 Jul 2013 22:34:01 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC18468@EX2K10MB1.corp.yaanatech.com> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> <457ED3A0-D8D1-4420-A2C3-5B07B16AE641@vigilsec.com> In-Reply-To: <457ED3A0-D8D1-4420-A2C3-5B07B16AE641@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.87] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_01F2_01CE8253.0A322D00" MIME-Version: 1.0 Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jul 2013 22:34:07 -0000 ------=_NextPart_000_01F2_01CE8253.0A322D00 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Not an easy task to do. I have perhaps one area of concern: "The mechanism must allow parties who are not delegated a telephone number, but are authorized by the entity who is delegated the number, to place calls using the identity." I think that this is an ancillary mechanism, versus "the" mechanism, but that aside how about: "The mechanism(s) must allow a delegated telephone number holder to locally sub-delegate and revoke its use by another delegated telephone number holder without compromising the global delegation scheme." I suggested earlier how this could be done. My concern is that such local issues should not impact the SPs or the central authority, nor should it weaken the overall delegation process. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Russ Housley Sent: Tuesday, July 16, 2013 4:34 PM To: IETF STIR Mail List Subject: Re: [stir] Draft STIR Charter I have tried to pull all of the discussion into an updated charter. I have also attached a diff to make it easier to review. Russ ------=_NextPart_000_01F2_01CE8253.0A322D00 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NjIyMzQwMFowIwYJKoZIhvcNAQkEMRYEFHvKmBn0hMP6QJkhc6aAMQqaQXnHMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAN/Df69o4B1sT/yvAVJT6Ap1gZjOx++AyFo3B7zmd gtByLBArpds2/vMkdAQmAWoTXZUwTZyrtGgk8PcNkkp+M1kocqhmRqeOA5ZN3lKjwjhqiLeBRGJm ph1yRnvQ+GHBFEd+7WDbYPFST4RsBvBfjiHxjSL7vZLZWsJfH//mcUx5893MLqe5fSJkNgRYOEcd Jg/8lNfKUFGusCsypfmN2lne+ePJcRnzxnz4r4OVwS7NuSif4dnMQGvxRS/tNnq2qLuE2Ir6DJmQ OLt2GFjLpqabZ36SnshWBc2HEtSK4BK8D5gVLF7Z19blG0uu5ftNI60YKRd9w73t/h9J3+g90wAA AAAAAA== ------=_NextPart_000_01F2_01CE8253.0A322D00-- From hadriel.kaplan@oracle.com Tue Jul 16 17: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 D209121F9CF5 for ; Tue, 16 Jul 2013 17:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.481 X-Spam-Level: X-Spam-Status: No, score=-6.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osieIEdm7IhM for ; Tue, 16 Jul 2013 17:57:13 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4544621F9CE6 for ; Tue, 16 Jul 2013 17:57:13 -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 r6H0vBY7001775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Jul 2013 00:57:12 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 r6H0v9E7018131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jul 2013 00:57:11 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 r6H0v9Lt028993; Wed, 17 Jul 2013 00:57:09 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 16 Jul 2013 17:57:08 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> Date: Tue, 16 Jul 2013 20:57:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <971DC811-7446-4346-84C1-37738E3AF6C4@oracle.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@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 Mail List" Subject: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 00:57:20 -0000 On Jul 16, 2013, at 4:14 PM, Michael Hammer = wrote: > Agree, but I was suggesting one CA operating for the national = authority=20 > who knows via feedback from the delegation system what SP has each = number. > One CA > One cert per number > No chains. OK, I think I grok the part above so far - you're just saying use one = trusted CA per country, and have it sign all certs, and there's a = separate cert per E.164. I'm with you so far... > One place to look to validate. Where? Where does the call verifier system get the cert from, when it = receives a call request? Where does it check that both the root CA's = cert and the carrier's cert have not been revoked? > Your DNSSEC solution just defines how the central authority maintains = its > knowing of what SP owns what number. Sure it does that, but it doesn't "just" do that - that's not even its = main purpose/benefit. It lets the verifier systems retrieve the public = keys, in a highly-efficient, scalable manner; and in such a way that = they don't have to do any additional CRL/OCSP validation. It stores the = keys in the same place that defines the number assignments, and when = number assignment changes, both the database entry of the assignment and = the database of the keys changes at the same time. There aren't a bunch = of certs floating around in the ether to worry about. [as an aside, CIDER is not a "DNSSEC" solution per se - the DNS tree = should be DNSSEC signed, but whether the verifier checks the DNSSEC = parts or not is up to them, and my guess is most won't for calls within = their country, because the threat model of bogus DNS injection is likely = pretty small for STIR in practice] > There are other technologies to store/maintain the {Tel#, SP name, SP = public > key | cert, User public key | cert} tuple. Yup, of course there are. > Delegation updates SP values, Assignment uses SP values to update User > values. I'm not sure I grok that. What do you mean? -hadriel From michael.hammer@yaanatech.com Tue Jul 16 19:36: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 E41E921F9AEB for ; Tue, 16 Jul 2013 19:36:46 -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.066, 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 3ED81g9d5tOQ for ; Tue, 16 Jul 2013 19:36: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 B71AB21F9AE9 for ; Tue, 16 Jul 2013 19:36:41 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 16 Jul 2013 19:36:38 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" Thread-Topic: CA Certs (was: Re: [stir] Rollout timeframe) Thread-Index: AQHOgoiTjNbaSFT4jEWsFf1ms6QitZloIM1g Date: Wed, 17 Jul 2013 02:36:37 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-7446-4346-84C1-37738E3AF6C4@oracle.com> In-Reply-To: <971DC811-7446-4346-84C1-37738E3AF6C4@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.87] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0009_01CE8274.EE426930" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 02:36:47 -0000 ------=_NextPart_000_0009_01CE8274.EE426930 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Inline... -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Tuesday, July 16, 2013 8:57 PM To: Michael Hammer Cc: stir@ietf.org Mail List Subject: CA Certs (was: Re: [stir] Rollout timeframe) On Jul 16, 2013, at 4:14 PM, Michael Hammer wrote: > Agree, but I was suggesting one CA operating for the national > authority who knows via feedback from the delegation system what SP has each number. > One CA > One cert per number > No chains. OK, I think I grok the part above so far - you're just saying use one trusted CA per country, and have it sign all certs, and there's a separate cert per E.164. I'm with you so far... > One place to look to validate. Where? Where does the call verifier system get the cert from, when it receives a call request? Where does it check that both the root CA's cert and the carrier's cert have not been revoked? >> The cert can be provided in-band with the call. >> If need be, the certs can be fetched from a known location. Each carrier can also cache any cert. The central administrator's cert can also be published and cached widely so that any Tel# cert can be directly verified. >> This does not involve the carrier's cert other than that the central administrator needs to validate that the carrier's cert used in updating the DB is up to date and not revoked. Those certs are a separate matter. If the DB wants, they can use passwords if they want. >> Revocations are done via Certificate Revocation Lists. > Your DNSSEC solution just defines how the central authority maintains > its knowing of what SP owns what number. Sure it does that, but it doesn't "just" do that - that's not even its main purpose/benefit. It lets the verifier systems retrieve the public keys, in a highly-efficient, scalable manner; and in such a way that they don't have to do any additional CRL/OCSP validation. >> How many RTTs does your system require versus none? It stores the keys in the same place that defines the number assignments, and when number assignment changes, both the database entry of the assignment and the database of the keys changes at the same time. There aren't a bunch of certs floating around in the ether to worry about. >> For normal operation they don't float in the ether, they are included in the signaling between caller and called. No different than the validation that would be required to be sure that access to your solution is not spoofed. [as an aside, CIDER is not a "DNSSEC" solution per se - the DNS tree should be DNSSEC signed, but whether the verifier checks the DNSSEC parts or not is up to them, and my guess is most won't for calls within their country, because the threat model of bogus DNS injection is likely pretty small for STIR in practice] >> So, you basically propose a solution that is either unsecure or requires an equivalent strong security? Need to compare apples to apples here. > There are other technologies to store/maintain the {Tel#, SP name, SP > public key | cert, User public key | cert} tuple. Yup, of course there are. > Delegation updates SP values, Assignment uses SP values to update User > values. I'm not sure I grok that. What do you mean? >> Just that it is inherent that the central authority keep track of who "owns" the number to determine who is allowed to update. You have the same in your solution. Once, the carrier of record is authenticated, then the information they provide for that number (public key) can be used to create/store/return a cert. You have same storage of public key and association to a number in your solution. >> I am also hoping that the cert-based solution exhibits a higher degree of shared fate, since it coincides with the signaling, versus dependency on 5-9's operation for the repository you propose. Hopes that helps, Mike -hadriel ------=_NextPart_000_0009_01CE8274.EE426930 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NzAyMzYzNlowIwYJKoZIhvcNAQkEMRYEFHTZJ5FGWSQmhT9mVRBU94gS3eNIMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAXIMTnUmIhux0CIik0LewLe87jNNlTIvP8NbHPaPE d7G+lUu501xHhTzXsJZgAVtGjCnJ1ZhUUzjMFcHo5o37vqap3865I6LxzzWdTK04OWzlxyvoNYKW E0GtmElF8iBwnwSD5MjHtUe8k/VZjvfFmORBu+Kmz+OJ+m3ULhX/0WKSzTfp3xs5GV6PNIxAOmDY NGYTZTt8erHpllNQmbYHwi/vh95vUwqopv6PSTcQrCbqxmRJKNhL08/vqxzHqEz/SYG9UQCbNszU xL70lNz+kzhq1ahtFP1tkKdJ+hYLDxJ1L+Tky2q2RVEr9muOOqid7XrH7R1d23wQ8daYn7/j1QAA AAAAAA== ------=_NextPart_000_0009_01CE8274.EE426930-- From hadriel.kaplan@oracle.com Tue Jul 16 20:34: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 ED19C21F99C2 for ; Tue, 16 Jul 2013 20:34:17 -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 mhFz6FYaNYuO for ; Tue, 16 Jul 2013 20:34:11 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3F28021F99C5 for ; Tue, 16 Jul 2013 20:34:11 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6H3Y8Tl015435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Jul 2013 03:34:09 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 r6H3Y6fx010077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jul 2013 03:34:07 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 r6H3Y6s3006940; Wed, 17 Jul 2013 03:34:06 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 16 Jul 2013 20:34: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: <00C069FD01E0324C9FFCADF539701DB3BBC18417@EX2K10MB1.corp.yaanatech.com> Date: Tue, 16 Jul 2013 23:34:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <25FEFC18-0141-4ED3-A35A-C2D75D5968D5@oracle.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com>, <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <084261CE-3F4D-48CE-A5BA-7B9A37E94351@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18417@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" , "Henning.Schulzrinne@fcc.gov" Subject: [stir] CA certs (was Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 03:34:18 -0000 On Jul 16, 2013, at 5:51 PM, Michael Hammer = wrote: > Yes, much along those lines. >=20 > However, unlike CIDER, you don't need secret trees that have limited = access, > and no privacy concerns. What "secret trees"? You mean that CIDER could be deployed as a private = DNS? CIDER could be deployed in a private/federated manner, for sure, but it = doesn't *have* to be. Each country/anchor can make that decision for = themselves. Obviously if a country chooses to keep it private, then they'd have to = either figure out how to let other countries validate the numbers, or = not have their numbers be validated by other countries. It's not = actually impossible to keep your country's CIDER tree private while = still letting other countries validate your numbers - because = international calls in most countries happen to come in through very = specific peering points/carriers, and we could figure out how to make it = work. For example, the private country could let just the specific = international carriers access its CIDER servers; or it could let just = specific DNS resolvers do so under controlled conditions. There are = only ~160 country-code admins to have to deal with, so it's not totally = crazy. Then again, using HTTP or LDAP or anything else has the same problem - = if you don't provide unrestricted access to the certs, then you have to = live with the complexities of access control to them from everywhere, = including all other countries; or not make them accessible to other = countries; or use the same sort of hacks. > The certificates can be promiscuously distributed, How? > You can even have the cert send in-band, with no query to the DNS. Sadly, that we can't do. Or at least the premise has been that we can't = expect to do that successfully, and I believe the premise is likely = true. > The DB operator has credentials for all the carriers of record. =20 > That can be many if the delegation cuts out some levels of middlemen = and CoR > is more granular, but still doable. Sure - it has to have that in CIDER too, to grant access rights for = publishing public keys. No matter what, the common root/anchor/whatever = has to know about the CoRs, and it's scalable because they know about = them already today. > A standard process to register a Tel#/public key pair and get a cert = between > carrier of record and DB should not be hard. Agreed. > How the carrier of record manages the creation of public keys and = pairing > with telephone numbers=20 > and manages that with their customers does not need to be = standardized. Right it doesn't *have* to be standardized, but as it turns out, it = could be the exact same protocol as used between the CoR and the DB. = Creating a standard protocol for it doesn't mean people must or will use = it - it just simplifies things for some people if there is a standard = protocol for it. > (Note, the carrier could even create those pairings in advance and = register > them with the DB in advance,=20 > and distribute only to users when assigning to users. If you trust = the > carrier to administer the number,=20 > no reason not to trust them to administer the private key/cert > distribution.) I don't disagree that could happen, but we'd never say so in any IETF = documents. It's bad mojo to have private keys passed around. Kinda = ruins the non-repudiation aspects. There's "trust" and then there's = "Legally-binding Trust". I think even the carriers might prefer you use = a private key they can't know about, for example so that if you screw up = later they could prove you screwed up and not them. > If one wanted the end-user to generate the Tel#/private key pair, the = CoR > could ask them to generate that and=20 > submit the public key up hop-by-hop through the SP chain to the CoR = that > registers it and returns a cert. Yup, like CIDER too. Except CIDER skips the "returns a cert" portion. > What gets signed and what passes E2E in-band is still an issue, but at = least > a trust basis would be in place. Right, much of the debate has been around how the trust basis would = happen, not about what passes E2E. So far there are two proposals for = what passes E2E, but no debate about that yet. > And presumable, the SPs that support it won't turn around and = circumvent it > by stripping out supporting E2E headers. Right, which means we need to make the info in the headers as = benign/uncontroversial as possible. -hadriel From hadriel.kaplan@oracle.com Tue Jul 16 21:37: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 A9BF421F893E for ; Tue, 16 Jul 2013 21:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.185 X-Spam-Level: X-Spam-Status: No, score=-6.185 tagged_above=-999 required=5 tests=[AWL=-0.186, 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 CL3q3wplfkQy for ; Tue, 16 Jul 2013 21:37:48 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9F79921F88FE for ; Tue, 16 Jul 2013 21:37: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 r6H4bib1022743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Jul 2013 04:37:45 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 r6H4bhP4015503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jul 2013 04:37:44 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6H4bhjx015499; Wed, 17 Jul 2013 04:37:43 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 16 Jul 2013 21:37: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: <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> Date: Wed, 17 Jul 2013 00:37:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@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" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 04:37:55 -0000 On Jul 16, 2013, at 10:36 PM, Michael Hammer = wrote: > -----Original Message----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com]=20 >=20 > On Jul 16, 2013, at 4:14 PM, Michael Hammer = > wrote: >=20 >> One place to look to validate. >=20 > Where? Where does the call verifier system get the cert from, when it > receives a call request? Where does it check that both the root CA's = cert > and the carrier's cert have not been revoked? >=20 >>> The cert can be provided in-band with the call. =20 It can't. Not if we want to get the stuff through E2E. :( >>> If need be, the certs can be fetched from a known location. =20 What known location? An HTTP server in the cloud? Run by whom? >>> Each carrier > can also cache any cert. =20 How? You mean cache them after they've retrieved them from a previous = call? How long do they cache them for, so as not to screw up the ability for = the originator/DB to change certs? > The central administrator's cert can also be > published and cached widely so that any Tel# cert can be directly = verified. Yup. >>> This does not involve the carrier's cert other than that the central > administrator needs to validate that the carrier's cert used in = updating the > DB is up to date and not revoked. Those certs are a separate matter. = If > the DB wants, they can use passwords if they want. Sorry, I should have been clearer: I mean the end-entity E.164 cert not = the carrier cert. I meant when a call arrives, the verifier goes and = gets a cert for the E.164. That cert is signed by a root CA (the = central admin cert). The verifier needs to check the root CA cert = hasn't been revoked, but let's ignore that part because it's not a check = it has to do on every call really. But the verifier has to check the = root CA hasn't revoked the end-entity E.164 cert. That's painful. We could ignore that end-entity revocation check too if we decide it's = ok for it to be wrong until the cert expiry time. For example if we = make those E.164 certs only last a few months or something, we could = just take the risk that the cert has been revoked and if we're wrong it = would only be a problem for a few months in the worst case. But it = wouldn't look good in the press if that E.164 happened to be Citibank's = number. And refreshing certs every few months isn't fun either. >>> Revocations are done via Certificate Revocation Lists. Ouch. Those really suck. Although it would be a fascinating case-study to see how CRLs scale when = one carrier has its private keys compromised. :) >> Your DNSSEC solution just defines how the central authority maintains=20= >> its knowing of what SP owns what number. >=20 > Sure it does that, but it doesn't "just" do that - that's not even its = main > purpose/benefit. It lets the verifier systems retrieve the public = keys, in > a highly-efficient, scalable manner; and in such a way that they don't = have > to do any additional CRL/OCSP validation. =20 >=20 >>> How many RTTs does your system require versus none? In actual practice? I would expect CIDER to take about one RTT on = average, for domestic calls. More for international, but users expect = longer PDD for international calls. There is no "none". HTTP takes 2 RTTs best-case for just the TCP+HTTP = portion - but you need to do DNS before that to resolve the URL. CIDER = gives you the key during that DNS portion. No need to go further. If by "none" you mean put the cert in the signaling, see above/below on = that. > It stores the keys in the same place that defines the number = assignments, > and when number assignment changes, both the database entry of the > assignment and the database of the keys changes at the same time. = There > aren't a bunch of certs floating around in the ether to worry about. >=20 >>> For normal operation they don't float in the ether, they are = included in > the signaling between caller and called. No different than the = validation > that would be required to be sure that access to your solution is not > spoofed. See above. The premise has so far been that we can't include the certs = in the signaling and expect them to get E2E. I agree with that premise, = unfortunately. > [as an aside, CIDER is not a "DNSSEC" solution per se - the DNS tree = should > be DNSSEC signed, but whether the verifier checks the DNSSEC parts or = not is > up to them, and my guess is most won't for calls within their country, > because the threat model of bogus DNS injection is likely pretty small = for > STIR in practice] >=20 >>> So, you basically propose a solution that is either unsecure or = requires > an equivalent strong security? Need to compare apples to apples here. For sure, but I was just commenting on your using the phrase "Your = DNSSEC solution..." above. So I was just commenting on that "DNSSEC" = label. But since we're on this topic, the threat model for bogus DNS responses = in STIR is far different from the threat model of using bogus certs in = STIR. The latter is trivial to accomplish. The former is really hard. >> Delegation updates SP values, Assignment uses SP values to update = User=20 >> values. >=20 > I'm not sure I grok that. What do you mean? >=20 >>> Just that it is inherent that the central authority keep track of = who > "owns" the number to determine who is allowed to update. You have the = same > in your solution. Once, the carrier of record is authenticated, then = the > information they provide for that number (public key) can be used to > create/store/return a cert. You have same storage of public key and > association to a number in your solution. Ahh, got it. >>> I am also hoping that the cert-based solution exhibits a higher = degree of > shared fate, since it coincides with the signaling, versus dependency = on > 5-9's operation for the repository you propose. Right, if we could put the certs in the signaling we'd have fewer things = to fail. The bad news is we can't put the certs in the signaling. The = good news is DNS is pretty stable and redundantly deployable; and in = practice I expect many carriers to have either highly managed = connections to the DB, or actual local copies of the thing; and if it = can't be reached temporarily, I don't expect calls to fail. -hadriel From tsearle@sipstacks.com Wed Jul 17 00:26: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 84F7A21F8E79 for ; Wed, 17 Jul 2013 00:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_BACKHAIR_34=1, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mN8ijsqi7bFs for ; Wed, 17 Jul 2013 00:26:04 -0700 (PDT) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id 478A421F8C7C for ; Wed, 17 Jul 2013 00:26:04 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id a11so3330590iee.20 for ; Wed, 17 Jul 2013 00:26:02 -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=SAW1hvG4PpbGL21gggShohjVW/LZsBR6A2LlaUzO3Xo=; b=YiI6lRwXytmPPR2x0GUfc8neLuZ1o75JDahCQoDa7wyRWvP3+V18h6yowbght2XbAb B7Lor9uBnmGh8XVkgRJgv51sGp5/hh0sGlvhhneaulx27R9YJdlOb+dzErSrVfOyjCpA L6oAi2hlrtFKse/Gq/R39VKUdH0zKxy1q8bbDirlGA/1QIkpehYDRtoOPzB1zLM8L6XQ GrnvvpmnYo8226XiOGrz8vYNyZ2qnGOstmEX/txqOk09KDul62kBQvNQ/DJFfYB+Sqxl TSn7Y5P8l0UqkCW42YUW+XXfKYcLJ/3o7gdxwtXj9maGTGb5cgEPBy9nmFqGCnUH4Rej ftmw== MIME-Version: 1.0 X-Received: by 10.43.12.198 with SMTP id pj6mr4449989icb.68.1374045962545; Wed, 17 Jul 2013 00:26:02 -0700 (PDT) Received: by 10.64.68.132 with HTTP; Wed, 17 Jul 2013 00:26:02 -0700 (PDT) In-Reply-To: <7B23E7E8-2432-48B8-A2BF-75653D89936F@oracle.com> References: <20130712043221.11767.74779.idtracker@ietfa.amsl.com> <1F4B4D44-BD3E-4995-876A-147832C925F9@oracle.com> <7B23E7E8-2432-48B8-A2BF-75653D89936F@oracle.com> Date: Wed, 17 Jul 2013 09:26:02 +0200 Message-ID: From: Torrey Searle To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=bcaec518701c80c6b504e1b0017b X-Gm-Message-State: ALoCoQkAzZuOhlFXwAxw/eATNjXpdIQ/oUPCHJcWr1hajU/TALH61sT+4mKXTwIg5I9ef5esvCA2 Cc: "stir@ietf.org" Subject: Re: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 17 Jul 2013 07:26:36 -0000 --bcaec518701c80c6b504e1b0017b Content-Type: text/plain; charset=ISO-8859-1 Hello, Regarding the SIP <->XMPP inter-working of SUBSCRIBE. Subscriptions in SIP are time limited, and last forever in XMPP, as a result, sip<->xmpp gateway may need to generate several SIP subscribes in response to a single XMPP subscribe. Perhaps it's worthwhile to note that only the Dialog Creating and Dialog Destroying subscriptions will have a signature, and the rest of the in-dialog requests should be considered trusted as well? Regards, Torrey On Tue, Jul 16, 2013 at 5:19 AM, Hadriel Kaplan wrote: > > On Jul 15, 2013, at 4:05 PM, Torrey Searle wrote: > > > I really like your draft, especially the fact that inter networks with > ss7. Just have a initial comment that in the case of the UUI header, the > spec should probably specify that the Protocol Discriminator for the UUI > header should be set to 00 - User Specific Coding. Though it might me an > interesting question if it is possible to use a new value for the protocol > discriminator to easily identify that the value in the UUI header is a > signature. > > Crap, I forgot about the protocol discriminator. I don't mean I forgot to > mention it, I mean I forgot about the byte it takes, not to mention the > type and length bytes. That means there're only 128 bytes available, which > for a 1024-bit private key means all of those 128 bytes will be the > signature. So I'll have to move the key index and timestamp fields into > the Call-Reference param instead. Ugh. > > But anyway, yeah good catch, the discriminator should probably be 0x00. > > > > Also how about the case where bob@example.com gets aliased to an e164 > when reaching the pstn gateway? I assume the pstn gateway would "own" the > e164 and can re-sign the call before forwarding, but would it be > interesting to mention this case in the spec? > > Does that ever happen in the PSTN gateways? I know it happens in some > service providers (like skype for example), but I thought it happened on > some SIP or H.323 system just before it reached the PSTN GW. Regardless, > yes I should mention that in the draft too. > > Thanks for the feedback! > > -hadriel > > --bcaec518701c80c6b504e1b0017b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

Regarding the SIP <->= ;XMPP inter-working of SUBSCRIBE. =A0Subscriptions in SIP are time limited,= and last forever in XMPP, as a result, sip<->xmpp gateway may need t= o generate several SIP subscribes in response to a single XMPP subscribe. = =A0Perhaps it's worthwhile to =A0note that only the Dialog Creating and= Dialog Destroying subscriptions will have a signature, and the rest of the= in-dialog requests should be considered trusted as well?


Regards,
Torrey


On Tue, Jul 16, 2013 at 5:19 AM, Hadriel Kaplan &= lt;hadriel.k= aplan@oracle.com> wrote:

On Jul 15, 2013, at 4:05 PM, Torrey Searle <tsearle@sipstacks.com> wrote:

> I really like your draft, especially the fact that inter networks with= ss7. =A0Just have a initial comment that in the case of the UUI header, th= e spec should probably specify that =A0the Protocol Discriminator for the U= UI header should be set to 00 - User Specific Coding. =A0Though it might me= an interesting question if it is possible to use a new value for the proto= col discriminator to easily identify that the value in the UUI header is a = signature.

Crap, I forgot about the protocol discriminator. =A0I don't mean = I forgot to mention it, I mean I forgot about the byte it takes, not to men= tion the type and length bytes. =A0That means there're only 128 bytes a= vailable, which for a 1024-bit private key means all of those 128 bytes wil= l be the signature. =A0So I'll have to move the key index and timestamp= fields into the Call-Reference param instead. =A0Ugh.

But anyway, yeah good catch, the discriminator should probably be 0x00.


> Also how about the case where bob@e= xample.com gets aliased to an e164 when reaching the pstn gateway? =A0I= assume the pstn gateway would "own" the e164 and can re-sign the= call before forwarding, but would it be interesting to mention this case i= n the spec?

Does that ever happen in the PSTN gateways? =A0I know it happens in s= ome service providers (like skype for example), but I thought it happened o= n some SIP or H.323 system just before it reached the PSTN GW. =A0Regardles= s, yes I should mention that in the draft too.

Thanks for the feedback!

-hadriel


--bcaec518701c80c6b504e1b0017b-- From michael.hammer@yaanatech.com Wed Jul 17 06:30: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 A644C21F9E33 for ; Wed, 17 Jul 2013 06:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 9Lh0JtxTwmX7 for ; Wed, 17 Jul 2013 06:30:03 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6A021F9F00 for ; Wed, 17 Jul 2013 06:30:03 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Wed, 17 Jul 2013 06:30:01 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" Thread-Topic: CA certs (was Re: [stir] Rollout timeframe) Thread-Index: AQHOgp6BIHsNt5mCJk2MVcQCufBZdJlo3CDA Date: Wed, 17 Jul 2013 13:30:00 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC1863C@EX2K10MB1.corp.yaanatech.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com>, <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <084261CE-3F4D-48CE-A5BA-7B9A37E94351@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18417@EX2K10MB1.corp.yaanatech.com> <25FEFC18-0141-4ED3-A35A-C2D75D5968D5@oracle.com> In-Reply-To: <25FEFC18-0141-4ED3-A35A-C2D75D5968D5@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.63] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01CE82D0.32F97220" MIME-Version: 1.0 Cc: "stir@ietf.org" , "Henning.Schulzrinne@fcc.gov" Subject: Re: [stir] CA certs (was Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 13:30:08 -0000 ------=_NextPart_000_0000_01CE82D0.32F97220 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Points to answer: Having to go through a (existing PSTN?) international peering point carrier just prolongs the PSTN hop-by-hop model and not the Internet E2E model. Promiscuous distribution: There can be an app for that. HTTP works really well. :) I realize that passing the certs through a PSTN hop represents a challenge. The narrowly defined PSTN alt-route for "fat stuff that doesn't fit in existing SS7" between PSTN GW proposed earlier could address that, and could even be done without standardization. Mike -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Tuesday, July 16, 2013 11:34 PM To: Michael Hammer Cc: Henning.Schulzrinne@fcc.gov; stir@ietf.org Subject: CA certs (was Re: [stir] Rollout timeframe) On Jul 16, 2013, at 5:51 PM, Michael Hammer wrote: > Yes, much along those lines. > > However, unlike CIDER, you don't need secret trees that have limited > access, and no privacy concerns. What "secret trees"? You mean that CIDER could be deployed as a private DNS? CIDER could be deployed in a private/federated manner, for sure, but it doesn't *have* to be. Each country/anchor can make that decision for themselves. Obviously if a country chooses to keep it private, then they'd have to either figure out how to let other countries validate the numbers, or not have their numbers be validated by other countries. It's not actually impossible to keep your country's CIDER tree private while still letting other countries validate your numbers - because international calls in most countries happen to come in through very specific peering points/carriers, and we could figure out how to make it work. For example, the private country could let just the specific international carriers access its CIDER servers; or it could let just specific DNS resolvers do so under controlled conditions. There are only ~160 country-code admins to have to deal with, so it's not totally crazy. Then again, using HTTP or LDAP or anything else has the same problem - if you don't provide unrestricted access to the certs, then you have to live with the complexities of access control to them from everywhere, including all other countries; or not make them accessible to other countries; or use the same sort of hacks. > The certificates can be promiscuously distributed, How? > You can even have the cert send in-band, with no query to the DNS. Sadly, that we can't do. Or at least the premise has been that we can't expect to do that successfully, and I believe the premise is likely true. > The DB operator has credentials for all the carriers of record. > That can be many if the delegation cuts out some levels of middlemen > and CoR is more granular, but still doable. Sure - it has to have that in CIDER too, to grant access rights for publishing public keys. No matter what, the common root/anchor/whatever has to know about the CoRs, and it's scalable because they know about them already today. > A standard process to register a Tel#/public key pair and get a cert > between carrier of record and DB should not be hard. Agreed. > How the carrier of record manages the creation of public keys and > pairing with telephone numbers and manages that with their customers > does not need to be standardized. Right it doesn't *have* to be standardized, but as it turns out, it could be the exact same protocol as used between the CoR and the DB. Creating a standard protocol for it doesn't mean people must or will use it - it just simplifies things for some people if there is a standard protocol for it. > (Note, the carrier could even create those pairings in advance and > register them with the DB in advance, and distribute only to users > when assigning to users. If you trust the carrier to administer the > number, no reason not to trust them to administer the private key/cert > distribution.) I don't disagree that could happen, but we'd never say so in any IETF documents. It's bad mojo to have private keys passed around. Kinda ruins the non-repudiation aspects. There's "trust" and then there's "Legally-binding Trust". I think even the carriers might prefer you use a private key they can't know about, for example so that if you screw up later they could prove you screwed up and not them. > If one wanted the end-user to generate the Tel#/private key pair, the > CoR could ask them to generate that and submit the public key up > hop-by-hop through the SP chain to the CoR that registers it and > returns a cert. Yup, like CIDER too. Except CIDER skips the "returns a cert" portion. > What gets signed and what passes E2E in-band is still an issue, but at > least a trust basis would be in place. Right, much of the debate has been around how the trust basis would happen, not about what passes E2E. So far there are two proposals for what passes E2E, but no debate about that yet. > And presumable, the SPs that support it won't turn around and > circumvent it by stripping out supporting E2E headers. Right, which means we need to make the info in the headers as benign/uncontroversial as possible. -hadriel ------=_NextPart_000_0000_01CE82D0.32F97220 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NzEzMjk1NlowIwYJKoZIhvcNAQkEMRYEFIXP+B0zKHxw8g9BDbXRpgk07nG0MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEADccxmOBzdnJHR3N1HL2SEkeRqi0KA45fIF7OtJoq 7j46ePiDMzr2BtWbbAqj8nA4M9IUOGmwOfgPFMBiUSlXgUsP2MQ+5gZwTSCG8sj+Vv4AaNXdAtH5 v2N3fzI54mMlZ7F+QgjjandOHfw6MAK4L9erLSBh2NHjlITT+ZVzf6MFTH/tfQRCNIpJwaty1Cud nfS3C7LKs45Hu/lmITsmceQMtbE1VJHor4huSAlSRPfxvdERlAlxgR0TVhlgFeJYF9T7p/ABD9td qllyEJQZWA2R/O02TeSwvmn+DzxUBejoVAi3crnylV/GI8AgJwP+dod5i2uFVaBynF6jIVjm1QAA AAAAAA== ------=_NextPart_000_0000_01CE82D0.32F97220-- From michael.hammer@yaanatech.com Wed Jul 17 06:49: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 8FC0F21F9C55 for ; Wed, 17 Jul 2013 06:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, J_CHICKENPOX_34=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 cXfFQs-YLx9S for ; Wed, 17 Jul 2013 06:49: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 915C621F9AB3 for ; Wed, 17 Jul 2013 06:49: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; Wed, 17 Jul 2013 06:49:47 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" Thread-Topic: CA Certs (was: Re: [stir] Rollout timeframe) Thread-Index: AQHOgoiTjNbaSFT4jEWsFf1ms6QitZloIM1ggACeOgCAACL38A== Date: Wed, 17 Jul 2013 13:49:45 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> In-Reply-To: <1134364F-C428-4C98-91D4-6F33D4271299@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.63] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000A_01CE82D2.F798EAA0" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 13:49:52 -0000 ------=_NextPart_000_000A_01CE82D2.F798EAA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Points: The beauty of the cert is that you don't have to get it from a specific location, so no single point of attack to block it. CRLs wouldn't be checked during a call, that can be done periodically when the user is inactive. A revocation period would be no different that the period of time that an entry in your DNS would be bad. Same issue. Your E2E issue is valid. But, do we design for the past or for the future when most calls will be Internet E2E? (That is, do we do work-arounds for the past or constrain the future signal routing patterns?) Mike -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Wednesday, July 17, 2013 12:38 AM To: Michael Hammer Cc: stir@ietf.org Subject: Re: CA Certs (was: Re: [stir] Rollout timeframe) On Jul 16, 2013, at 10:36 PM, Michael Hammer wrote: > -----Original Message----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > > On Jul 16, 2013, at 4:14 PM, Michael Hammer > > wrote: > >> One place to look to validate. > > Where? Where does the call verifier system get the cert from, when it > receives a call request? Where does it check that both the root CA's > cert and the carrier's cert have not been revoked? > >>> The cert can be provided in-band with the call. It can't. Not if we want to get the stuff through E2E. :( >>> If need be, the certs can be fetched from a known location. What known location? An HTTP server in the cloud? Run by whom? >>> Each carrier > can also cache any cert. How? You mean cache them after they've retrieved them from a previous call? How long do they cache them for, so as not to screw up the ability for the originator/DB to change certs? > The central administrator's cert can also be published and cached > widely so that any Tel# cert can be directly verified. Yup. >>> This does not involve the carrier's cert other than that the central > administrator needs to validate that the carrier's cert used in > updating the DB is up to date and not revoked. Those certs are a > separate matter. If the DB wants, they can use passwords if they want. Sorry, I should have been clearer: I mean the end-entity E.164 cert not the carrier cert. I meant when a call arrives, the verifier goes and gets a cert for the E.164. That cert is signed by a root CA (the central admin cert). The verifier needs to check the root CA cert hasn't been revoked, but let's ignore that part because it's not a check it has to do on every call really. But the verifier has to check the root CA hasn't revoked the end-entity E.164 cert. That's painful. We could ignore that end-entity revocation check too if we decide it's ok for it to be wrong until the cert expiry time. For example if we make those E.164 certs only last a few months or something, we could just take the risk that the cert has been revoked and if we're wrong it would only be a problem for a few months in the worst case. But it wouldn't look good in the press if that E.164 happened to be Citibank's number. And refreshing certs every few months isn't fun either. >>> Revocations are done via Certificate Revocation Lists. Ouch. Those really suck. Although it would be a fascinating case-study to see how CRLs scale when one carrier has its private keys compromised. :) >> Your DNSSEC solution just defines how the central authority maintains >> its knowing of what SP owns what number. > > Sure it does that, but it doesn't "just" do that - that's not even its > main purpose/benefit. It lets the verifier systems retrieve the > public keys, in a highly-efficient, scalable manner; and in such a way > that they don't have to do any additional CRL/OCSP validation. > >>> How many RTTs does your system require versus none? In actual practice? I would expect CIDER to take about one RTT on average, for domestic calls. More for international, but users expect longer PDD for international calls. There is no "none". HTTP takes 2 RTTs best-case for just the TCP+HTTP portion - but you need to do DNS before that to resolve the URL. CIDER gives you the key during that DNS portion. No need to go further. If by "none" you mean put the cert in the signaling, see above/below on that. > It stores the keys in the same place that defines the number > assignments, and when number assignment changes, both the database > entry of the assignment and the database of the keys changes at the > same time. There aren't a bunch of certs floating around in the ether to worry about. > >>> For normal operation they don't float in the ether, they are >>> included in > the signaling between caller and called. No different than the > validation that would be required to be sure that access to your > solution is not spoofed. See above. The premise has so far been that we can't include the certs in the signaling and expect them to get E2E. I agree with that premise, unfortunately. > [as an aside, CIDER is not a "DNSSEC" solution per se - the DNS tree > should be DNSSEC signed, but whether the verifier checks the DNSSEC > parts or not is up to them, and my guess is most won't for calls > within their country, because the threat model of bogus DNS injection > is likely pretty small for STIR in practice] > >>> So, you basically propose a solution that is either unsecure or >>> requires > an equivalent strong security? Need to compare apples to apples here. For sure, but I was just commenting on your using the phrase "Your DNSSEC solution..." above. So I was just commenting on that "DNSSEC" label. But since we're on this topic, the threat model for bogus DNS responses in STIR is far different from the threat model of using bogus certs in STIR. The latter is trivial to accomplish. The former is really hard. >> Delegation updates SP values, Assignment uses SP values to update >> User values. > > I'm not sure I grok that. What do you mean? > >>> Just that it is inherent that the central authority keep track of >>> who > "owns" the number to determine who is allowed to update. You have the > same in your solution. Once, the carrier of record is authenticated, > then the information they provide for that number (public key) can be > used to create/store/return a cert. You have same storage of public > key and association to a number in your solution. Ahh, got it. >>> I am also hoping that the cert-based solution exhibits a higher >>> degree of > shared fate, since it coincides with the signaling, versus dependency > on 5-9's operation for the repository you propose. Right, if we could put the certs in the signaling we'd have fewer things to fail. The bad news is we can't put the certs in the signaling. The good news is DNS is pretty stable and redundantly deployable; and in practice I expect many carriers to have either highly managed connections to the DB, or actual local copies of the thing; and if it can't be reached temporarily, I don't expect calls to fail. -hadriel ------=_NextPart_000_000A_01CE82D2.F798EAA0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NzEzNDk0NFowIwYJKoZIhvcNAQkEMRYEFL5JYBfMUqJJqEIgXKJEPfS9yam6MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEASWwsmEtYBSLnDZEdJAZ6gIS/A5urjc+RMBgb0CU2 iCrm9+dSH9QhnuTEyQriMXWJm2x5Mlky3WgCiGpjKC33vHQw3YJpi5/PmHP+NXBaYYyRpzzITn0v SefIQCXSnIIOXtLKLiDPP5IDIJxO3yeRH0EbZ1tY18ZgVoOFcGJSBKHlovz0V3JDdCXLnpFRJ4fo sstRIeKswUIIC7zpGiHqKA8Jun7JgrfibT+ZKLMfCJ1G1I/j5o8AidHMMqBb8ftiz1XdtBDpvLGS QRblCaLSoy+SUlV5LB0kWgF5MoWchGT+7aopvOjApc0N39/TijcK1dx8XSnVt0A4Q4VmaXMPlgAA AAAAAA== ------=_NextPart_000_000A_01CE82D2.F798EAA0-- From hadriel.kaplan@oracle.com Wed Jul 17 07:13: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 301C921E8064 for ; Wed, 17 Jul 2013 07:13:37 -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.383, BAYES_00=-2.599, J_BACKHAIR_34=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VW3hhbzo82yG for ; Wed, 17 Jul 2013 07:13:30 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8364621E8053 for ; Wed, 17 Jul 2013 07:11:53 -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 r6HEBpdg001652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 17 Jul 2013 14:11:52 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 r6HEBXsV021742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jul 2013 14:11:33 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 r6HEBWx3024756; Wed, 17 Jul 2013 14:11:32 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 17 Jul 2013 07:11:32 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Wed, 17 Jul 2013 10:11:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130712043221.11767.74779.idtracker@ietfa.amsl.com> <1F4B4D44-BD3E-4995-876A-147832C925F9@oracle.com> <7B23E7E8-2432-48B8-A2BF-75653D89936F@oracle.com> To: Torrey Searle X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "stir@ietf.org" Subject: Re: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 17 Jul 2013 14:13:37 -0000 On Jul 17, 2013, at 3:26 AM, Torrey Searle = wrote: > Hello, >=20 > Regarding the SIP <->XMPP inter-working of SUBSCRIBE. Subscriptions = in SIP are time limited, and last forever in XMPP, as a result, = sip<->xmpp gateway may need to generate several SIP subscribes in = response to a single XMPP subscribe. Perhaps it's worthwhile to note = that only the Dialog Creating and Dialog Destroying subscriptions will = have a signature, and the rest of the in-dialog requests should be = considered trusted as well? Yeah I'm cool with that - in fact, I'm not really sure we need = dialog-destroying subscriptions to be supported for IKES. Likewise a = BYE doesn't really need IKES. I mean this STIR stuff is really for the purpose of caller-id = authentication, not in-dialog/in-call message dialog-matching = verification. (and besides, middleboxes need to be able to generate BYEs = successfully) I only put them in the IKES draft to show they could be handled, because = 4474 handles them... but if we move forward with the IKES draft I'd = probably suggest we take the extraneous stuff out. -hadriel From hadriel.kaplan@oracle.com Wed Jul 17 07:14: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 DFA4121F9D2C for ; Wed, 17 Jul 2013 07:14:34 -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 h7dOihAZLjCh for ; Wed, 17 Jul 2013 07:14:28 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5D58D21F9A1E for ; Wed, 17 Jul 2013 07:14: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 r6HEEQov005113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Jul 2013 14:14: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 r6HEEQei022059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jul 2013 14:14:26 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 r6HEEPBk028803; Wed, 17 Jul 2013 14:14:26 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 17 Jul 2013 07:14: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: <00C069FD01E0324C9FFCADF539701DB3BBC1863C@EX2K10MB1.corp.yaanatech.com> Date: Wed, 17 Jul 2013 10:14:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com>, <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <084261CE-3F4D-48CE-A5BA-7B9A37E94351@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18417@EX2K10MB1.corp.yaanatech.com> <25FEFC18-0141-4ED3-A35A-C2D75D5968D5@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1863C@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 List" Subject: Re: [stir] CA certs (was Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 14:14:35 -0000 On Jul 17, 2013, at 9:30 AM, Michael Hammer = wrote: > Having to go through a (existing PSTN?) international peering point = carrier > just prolongs the PSTN hop-by-hop model and not the Internet E2E = model. OK, but STIR is supposed to be about fixing robocalling in the real = world, not the world we might want to exist. > Promiscuous distribution: There can be an app for that. HTTP works = really > well. :) Sure, that's the out-of-band proposal. > I realize that passing the certs through a PSTN hop represents a = challenge. > The narrowly defined PSTN alt-route for "fat stuff that doesn't fit in > existing SS7" between PSTN GW proposed earlier could address that, and = could > even be done without standardization. How could it be done without standardization? -hadriel From michael.hammer@yaanatech.com Wed Jul 17 07:23: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 A0A6A21E805F for ; Wed, 17 Jul 2013 07:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 qmnUF2H5C1at for ; Wed, 17 Jul 2013 07:23:39 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB1721F9E6E for ; Wed, 17 Jul 2013 07:23:39 -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, 17 Jul 2013 07:23:32 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" Thread-Topic: [stir] CA certs (was Re: Rollout timeframe) Thread-Index: AQHOgvfz80Dhf4FpZEepn5n4dnXJlZlo6zEA Date: Wed, 17 Jul 2013 14:23:30 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC18737@EX2K10MB1.corp.yaanatech.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com>, <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <084261CE-3F4D-48CE-A5BA-7B9A37E94351@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18417@EX2K10MB1.corp.yaanatech.com> <25FEFC18-0141-4ED3-A35A-C2D75D5968D5@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1863C@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.63] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0033_01CE82D7.AEB24020" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] CA certs (was Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 14:23:44 -0000 ------=_NextPart_000_0033_01CE82D7.AEB24020 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Note, I pointed out both in-band and out-of-band was possible. As a former PSTN GW vendor, I can say we did lots of things that were standardized. If the two GWs are from the same vendor and if the two carriers have a bilateral agreement, it can be done. I am not saying that having a standard method wouldn't help. Mike -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Wednesday, July 17, 2013 10:14 AM To: Michael Hammer Cc: stir@ietf.org List Subject: Re: [stir] CA certs (was Re: Rollout timeframe) On Jul 17, 2013, at 9:30 AM, Michael Hammer wrote: > Having to go through a (existing PSTN?) international peering point > carrier just prolongs the PSTN hop-by-hop model and not the Internet E2E model. OK, but STIR is supposed to be about fixing robocalling in the real world, not the world we might want to exist. > Promiscuous distribution: There can be an app for that. HTTP works > really well. :) Sure, that's the out-of-band proposal. > I realize that passing the certs through a PSTN hop represents a challenge. > The narrowly defined PSTN alt-route for "fat stuff that doesn't fit in > existing SS7" between PSTN GW proposed earlier could address that, and > could even be done without standardization. How could it be done without standardization? -hadriel ------=_NextPart_000_0033_01CE82D7.AEB24020 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NzE0MjMzMFowIwYJKoZIhvcNAQkEMRYEFI2XMq+VzxHPOyrXABJWeeHsJKQxMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAaYI5aFYcb+kYifmmLcEtZEvUKF0OI5ktYhU5lnnP NzGmmG5S/9dX3InRq8I/ydcsG1ppoOm7vvyeulJbwyylOBCmZMcBIzhlKEOcIzhpBwut8x8uMi/1 X/aWCVPEJyRTadUCkbIiXfdW2FZ425WiMGKYR6Ne4hLvZRnJDZxwo+a7FGw2v+nOwXhHOXkBMbSU 6Favkxfgg7RUEjU2xrNQzEqHzeSTLo6jGd2XsCQern07BLPIv5zdiaEKekR5GM6CvTyWfPPeQJ3I TsnpZ9ox4ftYlXNIgU73TiA2Vlzy3KSOh27pTTFTNWbM5eQmjjbaTQLo4LZvJXKeVU/9dp4okAAA AAAAAA== ------=_NextPart_000_0033_01CE82D7.AEB24020-- From hadriel.kaplan@oracle.com Wed Jul 17 07:49: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 4CF4B21E8053 for ; Wed, 17 Jul 2013 07:49:16 -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 9t4jjv+JdOG5 for ; Wed, 17 Jul 2013 07:49:09 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDCE21E804B for ; Wed, 17 Jul 2013 07:49:00 -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 r6HEmwSi016430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Jul 2013 14:48:59 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 r6HEmvc7002945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jul 2013 14:48: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 r6HEmvUb016407; Wed, 17 Jul 2013 14:48:57 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 17 Jul 2013 07:48: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: <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> Date: Wed, 17 Jul 2013 10:48:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@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] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 14:49:16 -0000 On Jul 17, 2013, at 9:49 AM, Michael Hammer = wrote: > Points: > The beauty of the cert is that you don't have to get it from a = specific > location, so no single point of attack to block it. Yup, agreed. But you still need a location/URL to get it from. =20 Unless you just mean that multiple physical servers can hold the cert - = but that's true for DNS as well, obviously. > CRLs wouldn't be checked during a call, that can be done periodically = when > the user is inactive. OK, but when I said "it would be an interesting case-study" I meant more = that if a large carrier had its private keys compromised, that's a = crap-load of certs to revoke. The model you had was each E.164 has its = own cert, and that end-entity E.164 cert was signed by the one DB = numbering authority for the entire country-code. So if a carrier with 50 = million numbers had its private keys compromised, 50 million certs would = have to be revoked, and added to the CRL. (and 50 million isn't an = exaggerated number, many carriers have more than that already today) > A revocation period would be no different that the period of time that = an > entry in your DNS would be bad. Same issue. How so? The instant an E.164's key is compromised you switch out the = DNS entry. There may be some DNS caches with the old keys, but only for = hours not months. It's a TTL value, not cert validity time. =46rom a DNSSEC perspective, yes you would still be susceptible to bogus = DNS injections/poisoning using the old entry, because the RRSIG RR for = the old entry would be valid still - but it's a lot harder to accomplish = bogus DNS injections/poisoning for a given E.164 number in STIR, than it = is to simply make a phone call claiming the E.164 and using the = compromised cert. > Your E2E issue is valid. But, do we design for the past or for the = future > when most calls will be Internet E2E? > (That is, do we do work-arounds for the past or constrain the future = signal > routing patterns?) I know it's tempting to design for a future you might want to have, but = as far as I know the STIR thing is supposed to be about making it work = and deployable in the world we really have. Personally, that's the = reason I'm spending any time on it - I think RFC 4474 is perfectly fine = for some future E2E world, and doesn't need fixing for that world. If = we want to design for some future thing that might happen someday, = that's cool, but I think we should be up-front about it. We create = working groups for that sort of thing too, but it attracts different = people and has different constraints/timeframes/etc. -hadriel From br@brianrosen.net Wed Jul 17 07:58: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 0C74621E805A for ; Wed, 17 Jul 2013 07:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.306 X-Spam-Level: X-Spam-Status: No, score=-100.306 tagged_above=-999 required=5 tests=[AWL=0.131, 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 gSK3pKk+34YH for ; Wed, 17 Jul 2013 07:58:34 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 7890C21E8056 for ; Wed, 17 Jul 2013 07:58:34 -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=oPoc1pIkyabrGQalyIJyjWEjP28eoxcK7Q+A4l1BTZA=; b=YROAyi4UNWEfkexm7vBCY9/TwF4LBbV6zPphAvO7ojkef6ytA8OHZiIrrZ7Etwy677/d9a2Lst92uwYkl2koO2v5ntMcsAARs99gZ9PF7zL123WB6bc9jYT/ORf0EP/+brpZ845o569I31q+pKON8P2cwCIkkKqBRz9kLRkKbtU=; Received: from neustargw.va.neustar.com ([209.173.53.233]:55184 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UzTBZ-0002NX-Lf; Wed, 17 Jul 2013 10:58:33 -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: <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> Date: Wed, 17 Jul 2013 10:58:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@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" , Michael Hammer Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 14:58:39 -0000 Small note: You would have to keep TTLs for at least U.S. zones under a few minutes = to allow the 15 minute port. I'd actually probably set it at a minute or two. Enough that retries work, not enough for any effective load reduction on = the authoritative servers. Note that you are sure to get a bunch of trawlers looking for TNs that = ported recently. That may be a big problem, both for the server and for = the idea. Brian On Jul 17, 2013, at 10:48 AM, Hadriel Kaplan = wrote: >=20 > On Jul 17, 2013, at 9:49 AM, Michael Hammer = wrote: >=20 >> Points: >> The beauty of the cert is that you don't have to get it from a = specific >> location, so no single point of attack to block it. >=20 > Yup, agreed. But you still need a location/URL to get it from. =20 > Unless you just mean that multiple physical servers can hold the cert = - but that's true for DNS as well, obviously. >=20 >=20 >> CRLs wouldn't be checked during a call, that can be done periodically = when >> the user is inactive. >=20 > OK, but when I said "it would be an interesting case-study" I meant = more that if a large carrier had its private keys compromised, that's a = crap-load of certs to revoke. The model you had was each E.164 has its = own cert, and that end-entity E.164 cert was signed by the one DB = numbering authority for the entire country-code. So if a carrier with 50 = million numbers had its private keys compromised, 50 million certs would = have to be revoked, and added to the CRL. (and 50 million isn't an = exaggerated number, many carriers have more than that already today) >=20 >=20 >=20 >> A revocation period would be no different that the period of time = that an >> entry in your DNS would be bad. Same issue. >=20 > How so? The instant an E.164's key is compromised you switch out the = DNS entry. There may be some DNS caches with the old keys, but only for = hours not months. It's a TTL value, not cert validity time. >=20 > =46rom a DNSSEC perspective, yes you would still be susceptible to = bogus DNS injections/poisoning using the old entry, because the RRSIG RR = for the old entry would be valid still - but it's a lot harder to = accomplish bogus DNS injections/poisoning for a given E.164 number in = STIR, than it is to simply make a phone call claiming the E.164 and = using the compromised cert. >=20 >=20 >> Your E2E issue is valid. But, do we design for the past or for the = future >> when most calls will be Internet E2E? >> (That is, do we do work-arounds for the past or constrain the future = signal >> routing patterns?) >=20 > I know it's tempting to design for a future you might want to have, = but as far as I know the STIR thing is supposed to be about making it = work and deployable in the world we really have. Personally, that's the = reason I'm spending any time on it - I think RFC 4474 is perfectly fine = for some future E2E world, and doesn't need fixing for that world. If = we want to design for some future thing that might happen someday, = that's cool, but I think we should be up-front about it. We create = working groups for that sort of thing too, but it attracts different = people and has different constraints/timeframes/etc. >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From kent@bbn.com Wed Jul 17 08:22: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 DF21C21F8B12 for ; Wed, 17 Jul 2013 08:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npwKLvqkxJHO for ; Wed, 17 Jul 2013 08:22:02 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9734A21F9A4A for ; Wed, 17 Jul 2013 08:22:01 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:56716) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UzTYE-000MYA-4a; Wed, 17 Jul 2013 11:21:58 -0400 Message-ID: <51E6B696.1020708@bbn.com> Date: Wed, 17 Jul 2013 11:21:58 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Brian Rosen References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <51E565A2.80806@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17EE8@EX2K10MB1.corp.yaanatech.com> <51E56EFE.5040106@bbn.com> <30AC5063-E6F6-4230-98B0-3A52D8EF71CA@brianrosen.net> <51E59C3B.9080906@bbn.com> <0B0C46A1-5582-42E6-A6F9-76C1526AF2C5@brianrosen.net> In-Reply-To: <0B0C46A1-5582-42E6-A6F9-76C1526AF2C5@brianrosen.net> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "stir@ietf.org" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 15:22:10 -0000 Brian, Thanks for the clarification wrt number delegation. > In the U.S., there may be many delegations in a path from the North American Number Plan Administrator to the user that has the number. Only the first two of these are captured in the formal delegation databases - NANPA allocates a NPA (area code) to the Pooling Administrator, which delegates a 1000 number block to a carrier. > > That carrier may resell 100 numbers to a SIP provider, who resells 20 of them to another SIP provider who sells 10 of them to an enterprise, who allocates one of those to an employee. Are the delegations at the lower tiers in your example reported to higher tiers? If not, then higher tiers cannot certify the lowest tier number holders, right? > At each step in the delegation (possibly save the last one), there could theoretically be a credential issued. yep. > I would not want to verify the validity of all of these individually to check a source identity. > > Ideally, I'd like to go one place and be able to get one credential that is authoritative for the number. and who would issue that credential, in your example? > That seems possible, even when we have the credential path follow the delegation path. how? > I hear you on data size. But remember, an exabyte hear and an exabyte there, and pretty soon, we're talking real big data stores. I agree that we have to not go overboard, but I also have not heard a description of a consistent, secure approach to this problem. Some folks have said that MITM attacks are not a concern, which runs counter to the model we almost always employ when evaluating protocol security in the IETF. Steve From kent@bbn.com Wed Jul 17 08: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 07C9921F997B for ; Wed, 17 Jul 2013 08:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zd4Cqo46kT9K for ; Wed, 17 Jul 2013 08:32:47 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAEA21F9A5F for ; Wed, 17 Jul 2013 08:32:46 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:56721) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UzTib-0007zZ-0z; Wed, 17 Jul 2013 11:32:41 -0400 Message-ID: <51E6B919.9010507@bbn.com> Date: Wed, 17 Jul 2013 11:32:41 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Henning Schulzrinne References: <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com>, <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "stir@ietf.org" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 15:32:53 -0000 Henning, The model you describe is simple and avoids the cert chaining concerns folks have cited. it does yield a cert-per-number DB, I believe, as you have described it. In Brian's example, the carrier of record may have sold numbers to folks who have sold numbers to other folks, ... In this case, where the carrier of record no longer knows to whom some of these number have been sold. When numbers are sold does the carrier of record had over the private keys for those numbers, or does it revoke the old certs and transitively pass on new cert requests from the lower tier operators, so that only they have the private keys, or something else. Is this process repeated through multiple tiers of operators as numbers are sold or ported? Steve From housley@vigilsec.com Wed Jul 17 08:43:51 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA0321F9343 for ; Wed, 17 Jul 2013 08:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 u2K-zVQ0TeSd for ; Wed, 17 Jul 2013 08:43:40 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 40EC321F9306 for ; Wed, 17 Jul 2013 08:43:40 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id CC016F240BD for ; Wed, 17 Jul 2013 11:44:06 -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 HZdrYtIoSc6n for ; Wed, 17 Jul 2013 11:43:23 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-212-98.washdc.fios.verizon.net [96.241.212.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id C5352F240BB for ; Wed, 17 Jul 2013 11:44:05 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jul 2013 11:43:38 -0400 Message-Id: To: IETF STIR Mail List Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [stir] Call for scribes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 17 Jul 2013 15:43:51 -0000 We are looking for volunteers to take minus and jabber scribe during the = STIR BOF in Berlin. Please volunteer. Thanks in advance, Russ From kent@bbn.com Wed Jul 17 08:44: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 B78AA21F9D2C for ; Wed, 17 Jul 2013 08:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTJnPux11z9z for ; Wed, 17 Jul 2013 08:44:24 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id C441E21F9343 for ; Wed, 17 Jul 2013 08:44:24 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:56724) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UzTtv-0008He-Ii; Wed, 17 Jul 2013 11:44:23 -0400 Message-ID: <51E6BBD7.2070700@bbn.com> Date: Wed, 17 Jul 2013 11:44:23 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Michael Hammer References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <51E59237.8000401@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC181C3@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC181C3@EX2K10MB1.corp.yaanatech.com> Content-Type: multipart/alternative; boundary="------------050604090904070709050205" Cc: "stir@ietf.org" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 15:44:30 -0000 This is a multi-part message in MIME format. --------------050604090904070709050205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit By "give this a rest for now" I think you mean having the last word :-) . Nice try. > Steve, > > My pointing to NP was only to indicate that there are trusted third > parties that are reliable. > > I also did not want to reinvent the number delegation system for the > operational aspects. > My suggestion was precisely to recommend aligning a certification system with the existing number delegation system. > > My focus is on how the called party can validate in near-real-time > (few seconds) the authenticity of the number. > > That in turn needs administrative side that can update in only > slightly longer time (minutes) due to number portability. > > Given that calls can come from anywhere globally, I didn't think > crawling the internet to discover some locally peculiar regime would help. > If number delegation system details vary from one country to the next, and if certification were to parallel that system, some discovery might be needed. The example you cited here is just one case. As a consumer I might be happy if my SP verifies the calling number info and passes it to me, rather than me having to do it myself. I realize that the current charter does not emphasize this model, but it's still just a draft ... You have repeatedly referred to "the central authority" without qualifying the term. presumably you don't envision one central authority for all numbers in the world, right? If you mean a per-country central authority, and if countries manage delegation in a fashion that views such an entity as authoritative for all number assignments (and sub-delegations) in the country, then that makes sense, and is consistent with what I suggested. > > Anyway, I am going to give this a rest for now. > > Mike > > --------------050604090904070709050205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit By "give this a rest for now" I think you mean having the last word :-) . Nice try.

Steve,

 

My pointing to NP was only to indicate that there are trusted third parties that are reliable.

I also did not want to reinvent the number delegation system for the operational aspects.

My suggestion was precisely to recommend aligning a certification system with the
existing number delegation system.

 My focus is on how the called party can validate in near-real-time (few seconds) the authenticity of the number.

That in turn needs administrative side that can update in only slightly longer time (minutes) due to number portability.

Given that calls can come from anywhere globally, I didn’t think crawling the internet to discover some locally peculiar regime would help.

If number delegation system details vary from one country to the next, and if certification
were to parallel that system, some discovery might be needed.

The example you cited here is just one case. As a consumer I might be happy if my SP verifies the calling number info and passes it  to me, rather than me having to do it myself. I realize that the current charter does not emphasize this model, but it's still just a draft ...

You have repeatedly referred to "the central authority" without qualifying the term.
presumably you don't envision one central authority for all numbers in the world, right?
If you mean a per-country central authority, and if countries manage delegation in a
fashion that views such an entity as authoritative for all number assignments (and
sub-delegations) in the country, then that makes sense, and is consistent with what I
suggested.

 Anyway, I am going to give this a rest for now.

 

Mike



--------------050604090904070709050205-- From york@isoc.org Wed Jul 17 08:48: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 12E6521F9A16 for ; Wed, 17 Jul 2013 08:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 sG3WkyrAp8Bk for ; Wed, 17 Jul 2013 08:47:55 -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 E172F21F99FB for ; Wed, 17 Jul 2013 08:47:54 -0700 (PDT) Received: from BLUPR06MB067.namprd06.prod.outlook.com (10.242.187.146) by BLUPR06MB066.namprd06.prod.outlook.com (10.242.187.145) with Microsoft SMTP Server (TLS) id 15.0.731.16; Wed, 17 Jul 2013 15:47:53 +0000 Received: from BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.198]) by BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.139]) with mapi id 15.00.0731.000; Wed, 17 Jul 2013 15:47:53 +0000 From: Dan York To: Russ Housley , IETF STIR Mail List Thread-Topic: [stir] Call for scribes Thread-Index: AQHOgwRyXvFrLydWC0q6tIXA8q6xoJlpJXqA Date: Wed, 17 Jul 2013 15:47:52 +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: 0910AAF391 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(24454002)(377454003)(479174003)(56816003)(74706001)(77096001)(76786001)(77982001)(83072001)(56776001)(47976001)(49866001)(47736001)(81342001)(50986001)(47446002)(54356001)(16406001)(76796001)(51856001)(76482001)(80022001)(63696002)(81542001)(53806001)(558084003)(74662001)(79102001)(65816001)(36756003)(74366001)(74876001)(76176001)(4396001)(59766001)(46102001)(69226001)(54316002)(74502001)(31966008); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB066; H:BLUPR06MB067.namprd06.prod.outlook.com; CLIP:10.255.101.4; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <5F07D329A523DD4E9F0F6F7EB138540D@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org Subject: Re: [stir] Call for scribes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 17 Jul 2013 15:48:00 -0000 On 7/17/13 5:43 PM, "Russ Housley" wrote: >We are looking for volunteers to take minus and jabber scribe during the >STIR BOF in Berlin. Please volunteer. I'll jabber-scribe. It would be great if someone else could be a backup jabber scribe as well. Dan From kent@bbn.com Wed Jul 17 08:55: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 3DB5821F9CB1 for ; Wed, 17 Jul 2013 08:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhZ-6oDuA0ob for ; Wed, 17 Jul 2013 08:55:36 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3AB21E8050 for ; Wed, 17 Jul 2013 08:55:32 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:56725) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UzU4g-0008W4-SU; Wed, 17 Jul 2013 11:55:30 -0400 Message-ID: <51E6BE72.8060500@bbn.com> Date: Wed, 17 Jul 2013 11:55:30 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hadriel Kaplan References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> In-Reply-To: <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "stir@ietf.org" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 15:55:47 -0000 Hadriel, > ... > I think Steven's point is that the web-pki model basically allows any trusted CA to claim any domain name, even though none of them are actually authoritative for domain name assignments. You can think of it as basically creating an alternate-root to DNS - an alternate authority of names - from an SSL/TLS-usage perspective. > > Since browsers trust ~160 CAs, the odds of a trusted CA screwing up not only became high, but once it happened it affected all domain names. It didn't just screw up the validity of domain names DigiNotar happens to certify, but it screwed up ALL of them, because no one knows what domain names DigitNotar could legitimately certify. With DNSSEC, however, the actual authority of domain name assignments is the same entity who actually signs stuff; they are not an alternate authority of names, they *are* the one-and-only authority of the name. If they screw up, they affect only the names signed by them (i.e., the names under their DNS tree branch). And if they screw up, "revocation" is fairly simple for them to perform and have take effect: they just change their DNSSEC entries. > > When it comes to STIR stuff, the point is we can't just trust third-party CAs to certify any E.164 number it cares to; because if they scrwe up, it affectes all E.164 numbers. We have to have some means of tying the certification to the authority that actually authoritatively assigns the numbers. So we need to know that a cert from carrier-X for number +1-603-555-1000 is signed by a CA that actually assigned carrier-X that E.164 number; which means we need to know what numbers the CA can assign - that it's authoritative for that role/decision. Aside from misspelling my name, your characterization of what I said is right! > So... assuming we define some encoding scheme and mechanics for this E.164 stuff to be done in certs... we could have the ITU sign certs of country-code admins indicating the country-code number, and the country-code admins sign certs of carriers indicating the full number, and the carriers sign certs of their customer service providers, and them signing certs of enterprises or end-users. (or more likely we'd skip the ITU level one, and start with country-code level admins) > > But that would require a means of actually retrieving the correct cert, walking the chain of signers, retrieving each of their certs, and checking revocation lists. Meanwhile the caller has hung up the phone because it didn't ring. :) gee, and just when I had become fond of your concise, accurate description of what I was saying :-) ! Several things could make this potentially time consuming process less onerous. First, if carriers performed this checking for their called-party clients, they could cache the cert and CRL data and perform the checks very quickly, during call setup, vouching for the caller ID info. Also, if the delegation chain is short, because it extends only to carriers of record and all certs are issued by them, or by national level authorities (as Henning suggested) then, this need not be a slow process. When the cert path is short, one could send it via SIP, so no need to search for the certs. If revocation status checking is not a critical, realtime requirement, as some others have suggested, then all the certs the called party needs would be in the header. (One could also consider sending OCSP responses to avoid the need for CRL checking.) Anyway, thanks for the very clear message. Steve From michael.hammer@yaanatech.com Wed Jul 17 09:20: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 3769E21E805F for ; Wed, 17 Jul 2013 09:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 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 gNS5V6CyJ4zH for ; Wed, 17 Jul 2013 09:20:44 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id D0C3611E80FA for ; Wed, 17 Jul 2013 09:20: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; Wed, 17 Jul 2013 09:20:40 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) Thread-Index: AQHOgvzGoW2Sqvrxc0GEvdoogk5ro5lpC5ow Date: Wed, 17 Jul 2013 16:20:39 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC18938@EX2K10MB1.corp.yaanatech.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> In-Reply-To: <7CE281BE-CF34-4E12-992C-D07C838D95CB@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.63] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0088_01CE82E8.0BEDCB00" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 16:20:49 -0000 ------=_NextPart_000_0088_01CE82E8.0BEDCB00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Carrier certs: first this only affects the administrative process. Second, there is no limitation of the carrier to one set of credentials. How is that different that if the credentials used to update DNS somehow were determined to be compromised? The net effect is the same. The public keys for users put in DNS by that carrier using that credential might be suspect also. The only difference is the nature of the credential and validation. Cert validity time versus cache age-out time: The two are different. A store can periodically remove and get new credentials for a user from the DB source or a reflection site. This is done all the time and is typical of mobile networks. Mike -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Wednesday, July 17, 2013 10:49 AM To: Michael Hammer Cc: stir@ietf.org Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) On Jul 17, 2013, at 9:49 AM, Michael Hammer wrote: > Points: > The beauty of the cert is that you don't have to get it from a > specific location, so no single point of attack to block it. Yup, agreed. But you still need a location/URL to get it from. Unless you just mean that multiple physical servers can hold the cert - but that's true for DNS as well, obviously. > CRLs wouldn't be checked during a call, that can be done periodically > when the user is inactive. OK, but when I said "it would be an interesting case-study" I meant more that if a large carrier had its private keys compromised, that's a crap-load of certs to revoke. The model you had was each E.164 has its own cert, and that end-entity E.164 cert was signed by the one DB numbering authority for the entire country-code. So if a carrier with 50 million numbers had its private keys compromised, 50 million certs would have to be revoked, and added to the CRL. (and 50 million isn't an exaggerated number, many carriers have more than that already today) > A revocation period would be no different that the period of time that > an entry in your DNS would be bad. Same issue. How so? The instant an E.164's key is compromised you switch out the DNS entry. There may be some DNS caches with the old keys, but only for hours not months. It's a TTL value, not cert validity time. >From a DNSSEC perspective, yes you would still be susceptible to bogus DNS injections/poisoning using the old entry, because the RRSIG RR for the old entry would be valid still - but it's a lot harder to accomplish bogus DNS injections/poisoning for a given E.164 number in STIR, than it is to simply make a phone call claiming the E.164 and using the compromised cert. > Your E2E issue is valid. But, do we design for the past or for the > future when most calls will be Internet E2E? > (That is, do we do work-arounds for the past or constrain the future > signal routing patterns?) I know it's tempting to design for a future you might want to have, but as far as I know the STIR thing is supposed to be about making it work and deployable in the world we really have. Personally, that's the reason I'm spending any time on it - I think RFC 4474 is perfectly fine for some future E2E world, and doesn't need fixing for that world. If we want to design for some future thing that might happen someday, that's cool, but I think we should be up-front about it. We create working groups for that sort of thing too, but it attracts different people and has different constraints/timeframes/etc. -hadriel ------=_NextPart_000_0088_01CE82E8.0BEDCB00 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NzE2MjAzOFowIwYJKoZIhvcNAQkEMRYEFEy5tux8/kb/lu8Pe9BDVa/OXDamMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAALZk38XBQYhgj3tYNlduwFiKur811R52SkaT4amr fAWqmqm1mEEg3VOyZSVCJH78A8RDw+Qywph7Znz/55JGujjefwFOsp8mMFzRvy5+R5We+5rqyBzx ew0XttYfbDvgmUh43CNzGh1GGg9HM5pjSb4iTb91hGMn2ywR/w/PKLbqB/X+TZ5FL2+F4iFKgrp7 gAKH+zehDkw+osyb0WmKxKcKQQ+ZZ2mvDR3RL4yVQzX637uJv/VDJx5J/snqoTm5xlhIx8Gk+JDN M/eNUQPJ/UbMGwje5jVveqm8kxjUJyjo0OY/g1ZyELUh2KbUWZU8/KDQmiWxyb26VEjaGpiTagAA AAAAAA== ------=_NextPart_000_0088_01CE82E8.0BEDCB00-- From michael.hammer@yaanatech.com Wed Jul 17 09:25: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 5963321E805F for ; Wed, 17 Jul 2013 09:25:20 -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.065, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZDDwE33m3+p for ; Wed, 17 Jul 2013 09:25:15 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id CD14021F9E33 for ; Wed, 17 Jul 2013 09:25:13 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Wed, 17 Jul 2013 09:25:13 -0700 From: Michael Hammer To: "kent@bbn.com" Thread-Topic: [stir] Rollout timeframe Thread-Index: AQHOgj0MegkF68FLTUyBdNmNASSKrplnd8uggACAIoD//44WoIAAkRSA//+PYsCAAdNqgP//lbhw Date: Wed, 17 Jul 2013 16:25:13 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC1895A@EX2K10MB1.corp.yaanatech.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <51E59237.8000401@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC181C3@EX2K10MB1.corp.yaanatech.com> <51E6BBD7.2070700@bbn.com> In-Reply-To: <51E6BBD7.2070700@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.63] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_008D_01CE82E8.AF501E10" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 16:25:20 -0000 ------=_NextPart_000_008D_01CE82E8.AF501E10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_008E_01CE82E8.AF501E10" ------=_NextPart_001_008E_01CE82E8.AF501E10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I was trying to get back to other work. J But, it is hard not to answer questions when asked. No single world authority. Likely on a per-national basis. Mike From: Stephen Kent [mailto:kent@bbn.com] Sent: Wednesday, July 17, 2013 11:44 AM To: Michael Hammer Cc: stir@ietf.org Subject: Re: [stir] Rollout timeframe By "give this a rest for now" I think you mean having the last word :-) . Nice try. Steve, My pointing to NP was only to indicate that there are trusted third parties that are reliable. I also did not want to reinvent the number delegation system for the operational aspects. My suggestion was precisely to recommend aligning a certification system with the existing number delegation system. My focus is on how the called party can validate in near-real-time (few seconds) the authenticity of the number. That in turn needs administrative side that can update in only slightly longer time (minutes) due to number portability. Given that calls can come from anywhere globally, I didn't think crawling the internet to discover some locally peculiar regime would help. If number delegation system details vary from one country to the next, and if certification were to parallel that system, some discovery might be needed. The example you cited here is just one case. As a consumer I might be happy if my SP verifies the calling number info and passes it to me, rather than me having to do it myself. I realize that the current charter does not emphasize this model, but it's still just a draft ... You have repeatedly referred to "the central authority" without qualifying the term. presumably you don't envision one central authority for all numbers in the world, right? If you mean a per-country central authority, and if countries manage delegation in a fashion that views such an entity as authoritative for all number assignments (and sub-delegations) in the country, then that makes sense, and is consistent with what I suggested. Anyway, I am going to give this a rest for now. Mike ------=_NextPart_001_008E_01CE82E8.AF501E10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I was trying to get back to other work.  J

 

But, it is hard not to answer questions when = asked.

 

No single world authority.  Likely on a per-national = basis.

 

Mike

 

 

From: Stephen Kent [mailto:kent@bbn.com]
Sent: Wednesday, = July 17, 2013 11:44 AM
To: Michael Hammer
Cc: = stir@ietf.org
Subject: Re: [stir] Rollout = timeframe

 

By = "give this a rest for now" I think you mean having the last = word :-) . Nice = try.

 

Steve,

 

My pointing to NP was only to indicate that there are trusted third = parties that are reliable.

I also did not want to reinvent the number delegation system for the = operational aspects.

My suggestion was precisely to recommend aligning a = certification system with the
existing number delegation = system.

 My focus is on how the called party can validate in = near-real-time (few seconds) the authenticity of the = number.

That in turn needs administrative side that can update in only = slightly longer time (minutes) due to number = portability.

Given that calls can come from anywhere globally, I didn’t = think crawling the internet to discover some locally peculiar regime = would help.

If number = delegation system details vary from one country to the next, and if = certification
were to parallel that system, some discovery might be = needed.

The example you cited here is just one case. As a = consumer I might be happy if my SP verifies the calling number info and = passes it  to me, rather than me having to do it myself. I realize = that the current charter does not emphasize this model, but it's still = just a draft ...

You have repeatedly referred to "the = central authority" without qualifying the term.
presumably you = don't envision one central authority for all numbers in the world, = right?
If you mean a per-country central authority, and if countries = manage delegation in a
fashion that views such an entity as = authoritative for all number assignments (and
sub-delegations) in the = country, then that makes sense, and is consistent with what = I
suggested.

 Anyway, I am going to give this a rest for = now.

 

Mike

 

 

------=_NextPart_001_008E_01CE82E8.AF501E10-- ------=_NextPart_000_008D_01CE82E8.AF501E10 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NzE2MjUxMlowIwYJKoZIhvcNAQkEMRYEFJWhZO6I02ofKj29Vx0jJT5BXTwuMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAeU7+fj8ZY3YvtV7Z64SAs8yqrruTp+ZGih/0keq3 nJUq0z7lVpwgB2YidohhPESrX6LDf1P7Gcn457HbtRFJMBxkSkfgXX/UinRa8tVz3NFqIq6u+U3I LaWCWQ0igJSpiFPZIibQ8JefBBfgEeENojl/iUT1snF33qsb4G3JygoBBzsnF4P817YU1kAW+ASG LPtVGaTxX5nl5JE5QqYIkkq7IMywbpcAzbQv/VuLAxMgAmGPdmdcgNxBL6vR77/yfuH2RW/Q6gXf 5RdLiEWzm371ZoqxX4lxxJP7gieO5opf+Smm62IC5Un9nwZIn74ltPNTqgNqRClzDKFkHPWumAAA AAAAAA== ------=_NextPart_000_008D_01CE82E8.AF501E10-- From hadriel.kaplan@oracle.com Wed Jul 17 09:43: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 8D8CD21F9B0D for ; Wed, 17 Jul 2013 09:43:26 -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 A5Pqt0Aed6EB for ; Wed, 17 Jul 2013 09:43:20 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0F99521F8FA1 for ; Wed, 17 Jul 2013 09:43:19 -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 r6HGhEsL023278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Jul 2013 16:43:14 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 r6HGhD8h004366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jul 2013 16:43:13 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 r6HGhCSj022376; Wed, 17 Jul 2013 16:43:12 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 17 Jul 2013 09:43:12 -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: <51E6BE72.8060500@bbn.com> Date: Wed, 17 Jul 2013 12:43:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <261BD146-4B2C-4528-ADF6-B7FE39F30B21@oracle.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <51E6BE72.8060500@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "stir@ietf.org" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 16:43:26 -0000 Sorry about the name misspelling. :( Other comments inline... On Jul 17, 2013, at 11:55 AM, Stephen Kent wrote: >> But that would require a means of actually retrieving the correct = cert, walking the chain of signers, retrieving each of their certs, and = checking revocation lists. Meanwhile the caller has hung up the phone = because it didn't ring. :) > gee, and just when I had become fond of your concise, accurate = description of what I was saying :-) ! Several things could make this = potentially time consuming process less onerous. > First, if carriers performed this checking for their called-party = clients, they could cache the cert and CRL data and perform the checks = very quickly, during call setup, vouching for Maybe, maybe not - they can certainly cache the country-code one, and = even ones for the bigger/real carriers. It might or might not be = practical to cache ones for all service providers, both the real ones = and the unregulated ones (last time I checked, there are on the order of = ~1000 of them in total so far in the US, but its growing). But I'm pretty sure it's impractical to cache them all if we really = think Enterprises would have their own cert as well. I'm not sure if = it's realistic to expect Enterprises to have certs, but the desire to = support that has been raised for STIR, mostly so the Enterprise could = then sign certs of outsourced call-centers and remote branch offices I = think. > the caller ID info. Also, if the delegation chain is short, because it = extends only to carriers of record and all certs are issued by them, or = by national level authorities (as Henning suggested) then, this need not = be a slow process. Agreed, if there's only one CA signing everything, by definition it's = not a long chain. :) I was more responding to the idea of having a cert signing chain, which = I thought was what people were talking about - that is what they were = talking about at some point. > When the cert path is short, one could send it via SIP, so no need to = search for the certs. Sadly we can't - doubling or tripling the SIP message size will make = deploying it in the current infrastructure essentially untenable, from a = practical perspective. Or at least that's the premise folks stipulated = when the STIR discussion began, and I agree with it. > If revocation status checking is not a critical, realtime requirement, = as some others have suggested, then all the certs the called party needs = would be in the header. (One could also consider sending OCSP responses = to avoid the need for CRL checking.) Yeah, I'm not sure whether revocation is important or not. I think it = depends on how long a compromised key would be usable for. -hadriel From hadriel.kaplan@oracle.com Wed Jul 17 10:22:03 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB0F21F9B07 for ; Wed, 17 Jul 2013 10:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cnow6xXztDw1 for ; Wed, 17 Jul 2013 10:21:55 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id D3A8E21F9C72 for ; Wed, 17 Jul 2013 10:21:55 -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 r6HHLroT003943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Jul 2013 17:21: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 r6HHLqSY009697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jul 2013 17:21:52 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 r6HHLq6e027762; Wed, 17 Jul 2013 17:21:52 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 17 Jul 2013 10:21:51 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Wed, 17 Jul 2013 13:21:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <84432CF7-A220-46F0-B945-F41F09F7061E@oracle.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! ! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "stir@ietf.org List" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 17:22:03 -0000 On Jul 17, 2013, at 10:58 AM, Brian Rosen wrote: > Small note: > You would have to keep TTLs for at least U.S. zones under a few = minutes to allow the 15 minute port. > I'd actually probably set it at a minute or two. I'm not sure if it really matters if the TTL is short, but it doesn't = have to be short - at least not with CIDER. The DNS name uses a "key = index", which identifies which specific public key was used for signing = the call - i.e., a single E.164 can have multiple public keys in DNS. = (it's like a DKIM "selector", but an integer instead of string) That = key index value is sent in the SIP header. It then becomes part of the = generated DNS name used for the lookup. So when a key changes, the DNS = full name changes, and there's no cache collision. You have to do something like that no matter what solution we end up = with (even HTTP), because the carriers have to be able to change their = key whenever they want without affecting in-flight call requests, and = give time for the new key to propagate to the local copies carriers = might have of the whole DB. Plus it lets two or more agents claim the = same phone number, for example the outsourced call-center or medical = doctor scenarios. So when a number gets ported, the new carrier uploads a public key into = a new/unused key index value, and thus there's no collision when = verifiers query for it, and no problem if they have an older key cached = locally. The TTL won't affect it. For example, suppose my number is +1-603-555-1000. My carrier has a = private key for that, and it had uploaded the public key into the CIDER = DB for index "2". When it signs the message, that number "2" gets put = into the STIR header info somewhere (draft-kaplan-stir-ikes-out-00 = describes where it could be encoded, for SIP/SS7/XMPP). When some = verifier receives that message, it sees the "2" and the caller-id of = +1-603-555-1000, and creates a DNS query for the name = "2._cidkey.0.0.0.1.5.5.5.3.0.6.1.cid.example.org". It gets back a TXT = RR with the base64-encoded public key, verifies the message, etc. So suppose I port the number to a new carrier. The porting process = happens, and the new carrier now uploads a new public key into the CIDER = DB, but will now use/get index "3" or "12" or whatever. It then uses = that "3" in its SIP messages. So a verifier will generate a DNS query = for name "3._cidkey.0.0.0.1.5.5.5.3.0.6.1.cid.example.org". Thus = there's no DNS cache hit to worry about. > Note that you are sure to get a bunch of trawlers looking for TNs that = ported recently. That may be a big problem, both for the server and for = the idea. It may be a problem, but it's not a problem for the server or the idea. = For one thing, CIDER can be deployed in a purely private/controlled = manner. That's up to the specific admin of each branch to decide (i.e., = each national authority, or national admin, or whatever). There's = plenty of evidence of private DNS in use, including in the SIP provider = world. But anyway, *any* database-based solution which is deployed as = open/unrestricted query access would have that problem. Using HTTP = doesn't mean people can't write scripts to generate HTTP queries, and = putting certs in HTTP servers certainly doesn't prevent learning when = the cert contents change. It's not the protocol that causes the = issue... it's how it's administered, deployed, and controlled. -hadriel From br@brianrosen.net Wed Jul 17 10: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 8B46C21F9A1C for ; Wed, 17 Jul 2013 10:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.31 X-Spam-Level: X-Spam-Status: No, score=-100.31 tagged_above=-999 required=5 tests=[AWL=0.127, 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 LGC-1pVr1YoC for ; Wed, 17 Jul 2013 10:43:45 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 67D8B21F99E9 for ; Wed, 17 Jul 2013 10:43:45 -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=ADE8f674Dd1EYXqIqwC2WZI3axcN7+tgReq/315hEcc=; b=Mo5+9nS8IlnXRPbU7UD+6M16UXXOG2X0I2151Xhc2kSZ+Iy9cAdFXs/fVwjWCddM1dcGXMupu8WfjP1UHxhGBwp0MEJBOPuh/DIj/UY1xzpsCDPlidepWM1gLs3VFKO5AqXxBTnb3hkEeDIhMahVG7F/NGJzokvGzMjS55+LngA=; Received: from neustargw.va.neustar.com ([209.173.53.233]:54216 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UzVlQ-0001qb-99; Wed, 17 Jul 2013 13:43:44 -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: <51E6B696.1020708@bbn.com> Date: Wed, 17 Jul 2013 13:43:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <594ACC84-6C3A-46FC-A7E9-AD6E46942F74@brianrosen.net> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <51E565A2.80806@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17EE8@EX2K10MB1.corp.yaanatech.com> <51E56EFE.5040106@bbn.com> <30AC5063-E6F6-4230-98B0-3A52D8EF71CA@brianrosen.net> <51E59C3B.9080906@bbn.com> <0B0C46A1-5582-42E6-A6F9-76C1526AF2C5@brianrosen.net> <51E6B696.1020708@bbn.com> To: Stephen Kent 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] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 17:43:50 -0000 On Jul 17, 2013, at 11:21 AM, Stephen Kent wrote: > Brian, >=20 > Thanks for the clarification wrt number delegation. >=20 >=20 >> In the U.S., there may be many delegations in a path from the North = American Number Plan Administrator to the user that has the number. = Only the first two of these are captured in the formal delegation = databases - NANPA allocates a NPA (area code) to the Pooling = Administrator, which delegates a 1000 number block to a carrier. >>=20 >> That carrier may resell 100 numbers to a SIP provider, who resells 20 = of them to another SIP provider who sells 10 of them to an enterprise, = who allocates one of those to an employee. > Are the delegations at the lower tiers in your example reported to = higher tiers? No, not in most cases > If not, then higher tiers cannot certify the lowest tier number = holders, right? Presently, that's correct >> At each step in the delegation (possibly save the last one), there = could theoretically be a credential issued. > yep. >> I would not want to verify the validity of all of these individually = to check a source identity. >>=20 >> Ideally, I'd like to go one place and be able to get one credential = that is authoritative for the number. > and who would issue that credential, in your example? Well, of course, that's the big issue here. I think we are mostly = talking about some kind of per-country DB that issues credentials. At every point, the delegator has to tell the DB about the delegation.=20= It's not clear to me how far we should or need to go in that direction = yet. It certainly makes a whole lot of things easier and more practical = if we do. =20 >> That seems possible, even when we have the credential path follow the = delegation path. > how? >> I hear you on data size. But remember, an exabyte hear and an = exabyte there, and pretty soon, we're talking real big data stores. > I agree that we have to not go overboard, but I also have not heard a = description of > a consistent, secure approach to this problem. Some folks have said = that MITM attacks are > not a concern, which runs counter to the model we almost always employ = when evaluating protocol security in the IETF. Yeah, and we're not of one mind about that. If we stick to the problem we're trying to solve =3D robocalling, = vishing and swatting, there is no MITM to worry about. But, some of us want our solutions to prevent, or at least mitigate = MITM. How far you go gets into trouble with other aspects. An example is the media hijack - alter the SDP and hijack the media. = That's an MITM problem, and the original 4474 work protected against = that. The problem is that in the real world, the SDP is altered most of = the time by various middle boxes for reasons deemed important to the = service providers. That doesn't seem like it's going to change. Jon = has proposed including in the signature a way to know if the SDP has = been altered, but not fail the signature if it had. Given that nearly = all SDP is altered, several folks on the list say that is a waste of = effort. From housley@vigilsec.com Wed Jul 17 12:09: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 5648621F9A05 for ; Wed, 17 Jul 2013 12:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 mN1Gns+RWupF for ; Wed, 17 Jul 2013 12:08:54 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id B662221F9C82 for ; Wed, 17 Jul 2013 12:08:43 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id D0450F240B7; Wed, 17 Jul 2013 15:09:28 -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 20JnkVor0pNI; Wed, 17 Jul 2013 15:08:13 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-212-98.washdc.fios.verizon.net [96.241.212.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 52DCBF2407C; Wed, 17 Jul 2013 15:09:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC18468@EX2K10MB1.corp.yaanatech.com> Date: Wed, 17 Jul 2013 15:08:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0C06D1FA-1F9D-4B5A-8741-7849E2D2B779@vigilsec.com> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> <457ED3A0-D8D1-4420-A2C3-5B07B16AE641@vigilsec.com> <00C069FD01E0324C9FFCADF539701DB3BBC18468@EX2K10MB1.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1085) Cc: "stir@ietf.org" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 17 Jul 2013 19:09:00 -0000 Mike: Included the previous sentence for context, I think we can convey the = same meaning with many fewer words. That is, when a telephone number or range of telephone numbers is delegated to an entity, relevant credentials will be generated (or modified) to reflect such delegation. The mechanism must allow a telephone number holder to further delegate and revoke use of a telephone number without compromising the global delegation scheme. Russ On Jul 16, 2013, at 6:34 PM, Michael Hammer wrote: > "The mechanism(s) must allow a delegated telephone number holder to = locally > sub-delegate and revoke its use=20 > by another delegated telephone number holder without compromising the = global > delegation scheme." From michael.hammer@yaanatech.com Wed Jul 17 12:17: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 B6DF221F8756 for ; Wed, 17 Jul 2013 12:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 jIk5iqd4dvgf for ; Wed, 17 Jul 2013 12:17:31 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id F116911E80CC for ; Wed, 17 Jul 2013 12:17:30 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Wed, 17 Jul 2013 12:17:30 -0700 From: Michael Hammer To: "housley@vigilsec.com" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIBWXEGbn3ibkCpY0NkPYfuGZlgOFKAgAAEgQCAAANtAIAAAaEAgAAGyYCAAAH7AIAABkaA//+MAvCAAISOAIAAAhCAgADroICAAEL9gIAAAeEAgABhRACAAB8HgIAADPeAgAAKzoCABhDlgIAAA2uA//+j5WCAAdacAP//jMgQ Date: Wed, 17 Jul 2013 19:17:29 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC18BCF@EX2K10MB1.corp.yaanatech.com> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> <457ED3A0-D8D1-4420-A2C3-5B07B16AE641@vigilsec.com> <00C069FD01E0324C9FFCADF539701DB3BBC18468@EX2K10MB1.corp.yaanatech.com> <0C06D1FA-1F9D-4B5A-8741-7849E2D2B779@vigilsec.com> In-Reply-To: <0C06D1FA-1F9D-4B5A-8741-7849E2D2B779@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.63] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00F2_01CE8300.BFECAA00" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 17 Jul 2013 19:17:36 -0000 ------=_NextPart_000_00F2_01CE8300.BFECAA00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks, that works for me. Wanted to de-couple local feature changes which could be frequent and numerous. Mike -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Wednesday, July 17, 2013 3:09 PM To: Michael Hammer Cc: stir@ietf.org Subject: Re: [stir] Draft STIR Charter Mike: Included the previous sentence for context, I think we can convey the same meaning with many fewer words. That is, when a telephone number or range of telephone numbers is delegated to an entity, relevant credentials will be generated (or modified) to reflect such delegation. The mechanism must allow a telephone number holder to further delegate and revoke use of a telephone number without compromising the global delegation scheme. Russ On Jul 16, 2013, at 6:34 PM, Michael Hammer wrote: > "The mechanism(s) must allow a delegated telephone number holder to > locally sub-delegate and revoke its use by another delegated telephone > number holder without compromising the global delegation scheme." ------=_NextPart_000_00F2_01CE8300.BFECAA00 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NzE5MTcyOFowIwYJKoZIhvcNAQkEMRYEFLrTpwKwwiw6iPOLPUhUdlJ6D+HQMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAeedWHQ8zhhMRJbnNIz+9n32qAhkdfeZ8UhxkPmW/ I22ex9OLvacKFXtu3rCec7CVuSpH6Y+SPFD1paDvyv9T6tBVIvqILpUQDr0zfV+lF46Jv8FrzLv5 P670qb0ZeSi5KFd65hVZMv6MCDOmAgDBFZ9hv9uwneZG7eOGErkbWJciAGiv6cvF9cJvRJfgWHt0 r6wlTVQ3path4H2OWaebEMv6zLmCkvSKhUW2IM3+k7AB2Qotrp9VciVYbQhOfRlPBTTPrgKav2nH 2TaUkFcHy8xzytgE8e4WgybHVTXyKnp5MDkFo8DuYQBNupmi2QdZzUJq1XNQ6xWtRNJIWfXq2QAA AAAAAA== ------=_NextPart_000_00F2_01CE8300.BFECAA00-- From kent@bbn.com Wed Jul 17 13:28:50 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30CAB21F9C33 for ; Wed, 17 Jul 2013 13:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1g4pXRRIPT5 for ; Wed, 17 Jul 2013 13:28:39 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 29C7021F9C2E for ; Wed, 17 Jul 2013 13:28:39 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:57629) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UzYL0-0000CH-4k; Wed, 17 Jul 2013 16:28:38 -0400 Message-ID: <51E6FE75.4080908@bbn.com> Date: Wed, 17 Jul 2013 16:28:37 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hadriel Kaplan References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <51E6BE72.8060500@bbn.com> <261BD146-4B2C-4528-ADF6-B7FE39F30B21@oracle.com> In-Reply-To: <261BD146-4B2C-4528-ADF6-B7FE39F30B21@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "stir@ietf.org" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 20:28:50 -0000 Hadriel, > Sorry about the name misspelling. :( > Other comments inline... > > On Jul 17, 2013, at 11:55 AM, Stephen Kent wrote: > >>> But that would require a means of actually retrieving the correct cert, walking the chain of signers, retrieving each of their certs, and checking revocation lists. Meanwhile the caller has hung up the phone because it didn't ring. :) >> gee, and just when I had become fond of your concise, accurate description of what I was saying :-) ! Several things could make this potentially time consuming process less onerous. >> First, if carriers performed this checking for their called-party clients, they could cache the cert and CRL data and perform the checks very quickly, during call setup, vouching for > Maybe, maybe not - they can certainly cache the country-code one, and even ones for the bigger/real carriers. It might or might not be practical to cache ones for all service providers, both the real ones and the unregulated ones (last time I checked, there are on the order of ~1000 of them in total so far in the US, but its growing). > > But I'm pretty sure it's impractical to cache them all if we really think Enterprises would have their own cert as well. I'm not sure if it's realistic to expect Enterprises to have certs, but the desire to support that has been raised for STIR, mostly so the Enterprise could then sign certs of outsourced call-centers and remote branch offices I think. In the RPKI context the plan is for every AS operator to acquire and cache all certs CRLs, ROAs, etc. for every other other operator, and to check for changes a few times per day. There are about 35K network operators, world wide. Analysis of the time it takes to do this, using servers in the Amazon cloud (in Tokyo and the US) to represent servers and clients, shows that this is really not a big deal in terms of bandwidth, time, storage, etc. So, it would be useful to have some number to play with to get a sense of how much bigger this system might be. >> the caller ID info. Also, if the delegation chain is short, because it extends only to carriers of record and all certs are issued by them, or by national level authorities (as Henning suggested) then, this need not be a slow process. > Agreed, if there's only one CA signing everything, by definition it's not a long chain. :) > I was more responding to the idea of having a cert signing chain, which I thought was what people were talking about - that is what they were talking about at some point. It's not one CA, but maybe one per country, or two tiers of CA per country, as per Henning's model. But, that still makes of a very short chain. >> When the cert path is short, one could send it via SIP, so no need to search for the certs. > Sadly we can't - doubling or tripling the SIP message size will make deploying it in the current infrastructure essentially untenable, from a practical perspective. Or at least that's the premise folks stipulated when the STIR discussion began, and I agree with it. OK, I didn't see that assumption/assertion in the charter. >> If revocation status checking is not a critical, realtime requirement, as some others have suggested, then all the certs the called party needs would be in the header. (One could also consider sending OCSP responses to avoid the need for CRL checking.) > Yeah, I'm not sure whether revocation is important or not. I think it depends on how long a compromised key would be usable for. > As I mentioned in a previous message, when designing a PKI it's important to have a model of the expected revocation rate when deciding on cert lifetimes. If one has good data on churn for a system prior to engineering a PKI, one can avoid serious mistakes. Steve From br@brianrosen.net Wed Jul 17 13:53: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 092F721F991F for ; Wed, 17 Jul 2013 13:53:21 -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 DK234AtNoaZn for ; Wed, 17 Jul 2013 13:53:16 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 5539B21F8FCE for ; Wed, 17 Jul 2013 13:53:16 -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=9uNj3gxtSx5eiS2sVaAqYITjK6MHh2cdyXAGGYXNIso=; b=FYDDO/Yev0IfgXpI5LLs86JF4OP3Hyx6wiav4pIZ5l4UETO5eSbdHPkuRsV0KdWAsxsIoMyy5ZK/ZY9+aekNGbM8wqf63XlRr54MFStWUjVufwHVn1V5Yif7tsjAzuJJSpRfcuK0ZOJd5bSXd76vXoUM7BKERWzxcHNhmBCGPhE=; Received: from neustargw.va.neustar.com ([209.173.53.233]:58638 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UzYio-0004VC-Uo; Wed, 17 Jul 2013 16:53: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: <51E6FE75.4080908@bbn.com> Date: Wed, 17 Jul 2013 16:53:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3B7C3493-2D1A-434F-9278-EE908107CB7A@brianrosen.net> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <51E6BE72.8060500@bbn.com> <261BD146-4B2C-4528-ADF6-B7FE39F30B21@oracle.com> <51E6FE75 .4080908@bbn.com> To: Stephen Kent 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 Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 20:53:21 -0000 We haven't agreed on a model for credentials yet, but some statistics: There are several billion telephone numbers. I think most experts = believe there are more assigned numbers than people. =20 There are 300-odd country codes There are a few tens of thousands of service providers. If enterprises = get some form of credential, there are potentially high tens of millions In the US, there are 500 million or so records in the portability = database. 15 minute ports for wireless numbers is the norm, and that = includes distribution of the update to the high hundreds or low = thousands of copies of the database. It handles up to about a million = transactions a day, not all of which are ports. Numbers that are = assigned but not in the portability database are in ranges assigned to = carriers. Brian On Jul 17, 2013, at 4:28 PM, Stephen Kent wrote: > Hadriel, >> Sorry about the name misspelling. :( >> Other comments inline... >>=20 >> On Jul 17, 2013, at 11:55 AM, Stephen Kent wrote: >>=20 >>>> But that would require a means of actually retrieving the correct = cert, walking the chain of signers, retrieving each of their certs, and = checking revocation lists. Meanwhile the caller has hung up the phone = because it didn't ring. :) >>> gee, and just when I had become fond of your concise, accurate = description of what I was saying :-) ! Several things could make this = potentially time consuming process less onerous. >>> First, if carriers performed this checking for their called-party = clients, they could cache the cert and CRL data and perform the checks = very quickly, during call setup, vouching for >> Maybe, maybe not - they can certainly cache the country-code one, and = even ones for the bigger/real carriers. It might or might not be = practical to cache ones for all service providers, both the real ones = and the unregulated ones (last time I checked, there are on the order of = ~1000 of them in total so far in the US, but its growing). >>=20 >> But I'm pretty sure it's impractical to cache them all if we really = think Enterprises would have their own cert as well. I'm not sure if = it's realistic to expect Enterprises to have certs, but the desire to = support that has been raised for STIR, mostly so the Enterprise could = then sign certs of outsourced call-centers and remote branch offices I = think. > In the RPKI context the plan is for every AS operator to acquire and = cache all certs > CRLs, ROAs, etc. for every other other operator, and to check for = changes a few times per day. > There are about 35K network operators, world wide. Analysis of the = time it takes to do this, > using servers in the Amazon cloud (in Tokyo and the US) to represent = servers and clients, > shows that this is really not a big deal in terms of bandwidth, time, = storage, etc. So, it would be useful to have some number to play with to = get a sense of how much bigger this system might be. >>> the caller ID info. Also, if the delegation chain is short, because = it extends only to carriers of record and all certs are issued by them, = or by national level authorities (as Henning suggested) then, this need = not be a slow process. >> Agreed, if there's only one CA signing everything, by definition it's = not a long chain. :) >> I was more responding to the idea of having a cert signing chain, = which I thought was what people were talking about - that is what they = were talking about at some point. > It's not one CA, but maybe one per country, or two tiers of CA per = country, as per > Henning's model. But, that still makes of a very short chain. >>> When the cert path is short, one could send it via SIP, so no need = to search for the certs. >> Sadly we can't - doubling or tripling the SIP message size will make = deploying it in the current infrastructure essentially untenable, from a = practical perspective. Or at least that's the premise folks stipulated = when the STIR discussion began, and I agree with it. > OK, I didn't see that assumption/assertion in the charter. >>> If revocation status checking is not a critical, realtime = requirement, as some others have suggested, then all the certs the = called party needs would be in the header. (One could also consider = sending OCSP responses to avoid the need for CRL checking.) >> Yeah, I'm not sure whether revocation is important or not. I think = it depends on how long a compromised key would be usable for. >>=20 > As I mentioned in a previous message, when designing a PKI it's = important to have a > model of the expected revocation rate when deciding on cert lifetimes. = If one has > good data on churn for a system prior to engineering a PKI, one can = avoid serious > mistakes. >=20 > Steve > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From stephen.farrell@cs.tcd.ie Wed Jul 17 13: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 7A67D21F9D56 for ; Wed, 17 Jul 2013 13:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8iVJH540wGP for ; Wed, 17 Jul 2013 13:54:10 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 26AA621F8B12 for ; Wed, 17 Jul 2013 13:54:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6E1E0BEAF; Wed, 17 Jul 2013 21:53:48 +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 e+z3ohDKN73z; Wed, 17 Jul 2013 21:53:47 +0100 (IST) Received: from [10.87.48.9] (unknown [86.45.52.27]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 90FD9BEA1; Wed, 17 Jul 2013 21:53:47 +0100 (IST) Message-ID: <51E7045B.3000308@cs.tcd.ie> Date: Wed, 17 Jul 2013 21:53:47 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Stephen Kent References: <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <51E6BE72.8060500@bbn.com> <261BD146-4B2C-4528-ADF6-B7FE39F30B21@oracle.com> <51E6FE75.4080908@bbn.com> In-Reply-To: <51E6FE75.4080908@bbn.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "stir@ietf.org" , Hadriel Kaplan Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 20:54:18 -0000 Hi Steve, On 07/17/2013 09:28 PM, Stephen Kent wrote: >> > As I mentioned in a previous message, when designing a PKI it's > important to have a > model of the expected revocation rate when deciding on cert lifetimes. > If one has > good data on churn for a system prior to engineering a PKI, one can > avoid serious > mistakes. That's certainly correct. And I do hope that some WG participants (assuming this BoF succeeds as I hope it will) do that modelling. One maybe-relevant quibble though: I don't think the goal here is to engineer an X.509 based PKI - that might be the best answer, (and is certainly a possible answer) but then again it might not, esp if something far more easily deployable that can meet the main requirements suffices. I don't know if there's a real possibility for the latter case (still have to read Hadriel's draft), but I very much do think the putative WG needs to spend time early on examining that question with as much interest as is applied to checking out what kind of PKI might work best. Put another way, I'm fairly sure that a PKI can be designed to meet the requirements here but I'm not at all sure that that PKI would be sufficiently easy to develop and deploy for STIR to succeed. My guess is that a DKIM-like thing (which I guess is what Hadriel is proposing) seems like the main non-PKI based approach worth investigating as an alternative. As of now, I'm not at all sure which approach might turn out better. Sorry if that's all obvious, S. From kent@bbn.com Wed Jul 17 14: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 D1D6521F9C2E for ; Wed, 17 Jul 2013 14:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HU-oyjUaYYl6 for ; Wed, 17 Jul 2013 14:12:36 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B8CEF21F9E89 for ; Wed, 17 Jul 2013 14:12:31 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:57650) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UzZ1R-0000a7-PN; Wed, 17 Jul 2013 17:12:29 -0400 Message-ID: <51E708BD.5070500@bbn.com> Date: Wed, 17 Jul 2013 17:12:29 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Brian Rosen References: <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <51E6BE72.8060500@bbn.com> <261BD146-4B2C-4528-ADF6-B7FE39F30B21@oracle.com> <51E6FE7! 5.4080908@bbn.com> <3B7C3493-2D1A-434F-9278-EE908107CB7A@brianrosen.net> In-Reply-To: <3B7C3493-2D1A-434F-9278-EE908107CB7A@brianrosen.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "stir@ietf.org" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 21:12:41 -0000 Brian, Thanks for the stats. They help frame some of the discussion of scaling. Are the U.S. numbers re wireless portability representative of what one sees on other countries where portability has been available for a few years? In addition to size, there is the rate of churn issue, e.g., what percentage of numbers are "ported" every day, how long does a ported number stay with a new carrier, on average, etc. Also how many countries allow number portability today? Steve From kent@bbn.com Wed Jul 17 14:18: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 3285E21F8F78 for ; Wed, 17 Jul 2013 14:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47CXNnTEGVju for ; Wed, 17 Jul 2013 14:17:54 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0B221F86BE for ; Wed, 17 Jul 2013 14:17:54 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:57651) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UzZ6Y-000Enn-3D; Wed, 17 Jul 2013 17:17:46 -0400 Message-ID: <51E709F9.4090002@bbn.com> Date: Wed, 17 Jul 2013 17:17:45 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Stephen Farrell References: <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <51E6BE72.8060500@bbn.com> <261BD146-4B2C-4528-ADF6-B7FE39F30B21@oracle.com> <51E6FE75.4080908@bbn.com> <51E7045B.3000308@cs.tcd.ie> In-Reply-To: <51E7045B.3000308@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "stir@ietf.org" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 21:18:00 -0000 Stephen, Since you were a major contributor to and proponent of DKIM and since I chaired PKIX for >16 years folks should expect each of us to favor technologies with which we have extensive experience. Since others on the list talked explicitly in terms of certs, I think it fair that we discuss that technology along with other options, right? Steve From br@brianrosen.net Wed Jul 17 14:24: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 8098621F9E6E for ; Wed, 17 Jul 2013 14:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.39 X-Spam-Level: X-Spam-Status: No, score=-99.39 tagged_above=-999 required=5 tests=[AWL=-0.812, BAYES_20=-0.74, 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 uddcVi4VEYmD for ; Wed, 17 Jul 2013 14:24:20 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id CDB3321F9E6A for ; Wed, 17 Jul 2013 14:24: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=xpPLoCGZkrJex/QAN6L3OUuNV/8wlPO0ZbWM8JuB9cY=; b=IiXPAfU0OSRvZNJ8g7CRdQb4TtOEk3hAxujbCooIQpBLI32jZmAr4wTOSRhyVB24bwjdfO6vg1J6QgNAanNsS5/16kqsu5wwegCoudpc0PI3SMTynz+tN1e4oN19g0LJVyoQp9qZJS4xMTqPFkfW4pjrsZMcmYU2dzq1tA5azGE=; Received: from neustargw.va.neustar.com ([209.173.53.233]:55803 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UzZCs-000648-PH; Wed, 17 Jul 2013 17:24:18 -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: <51E708BD.5070500@bbn.com> Date: Wed, 17 Jul 2013 17:24:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9E02481F-0489-4FC1-91FA-0261001E59C7@brianrosen.net> References: <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <51E6BE72.8060500@bbn.com> <261BD146-4B2C-4528-ADF6-B7FE39F30B21@oracle.com> <51E6FE7! 5.4080908@bbn.com> <3B7C3493-2D1A-434F-9278-EE908107CB7A@brianrosen.net> <51 E708BD.5070500@bbn.com> To: Stephen Kent 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] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 21:24:24 -0000 You can get a number ported in New Zealand in seconds I am told. = http://en.wikipedia.org/wiki/Mobile_number_portability has some more = data. It's pretty typical for ports to take days, not minutes in most places, = but that is changing. I don't know what the churn stats are, but I could look them up if it's = important. Seems like the million transactions a day on 500 million = records is an upper bound. Dozens of countries have portability running, I don't think it's a = hundred yet. See above reference. That is also changing fairly fast. =20= Brian On Jul 17, 2013, at 5:12 PM, Stephen Kent wrote: > Brian, >=20 > Thanks for the stats. They help frame some of the discussion of = scaling. > Are the U.S. numbers re wireless portability representative of what > one sees on other countries where portability has been available for > a few years? >=20 > In addition to size, there is the rate of churn issue, e.g., what = percentage > of numbers are "ported" every day, how long does a ported number stay = with a > new carrier, on average, etc. Also how many countries allow number = portability > today? >=20 > Steve >=20 From hadriel.kaplan@oracle.com Wed Jul 17 14: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 BC31421F9815 for ; Wed, 17 Jul 2013 14:28:30 -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 BcWplCdCAvRh for ; Wed, 17 Jul 2013 14:28:24 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 40F4621F918C for ; Wed, 17 Jul 2013 14:28:24 -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 r6HLRHJc012022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Jul 2013 21:27:18 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 r6HLRHar003602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jul 2013 21:27:17 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 r6HLRGNR020172; Wed, 17 Jul 2013 21:27:16 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 17 Jul 2013 14:27:16 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <51E7045B.3000308@cs.tcd.ie> Date: Wed, 17 Jul 2013 17:27:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <51E6BE72.8060500@bbn.com> <261BD146-4B2C-4528-ADF6-B7FE39F30B21@oracle.com> <51E6FE75.4080908@bbn.com> <51E7045B.300! 0308@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "stir@ietf.org" , Stephen Kent Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 21:28:30 -0000 On Jul 17, 2013, at 4:53 PM, Stephen Farrell = wrote: > My guess is that a DKIM-like thing (which I guess is what Hadriel > is proposing) seems like the main non-PKI based approach worth > investigating as an alternative. As of now, I'm not at all sure > which approach might turn out better. Yup, basically CIDER uses a DKIM-style model - for email-style names, = E.164 numbers, and nationally-specific short codes. -hadriel From dhc@dcrocker.net Wed Jul 17 14:31: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 8C1D521F99D7 for ; Wed, 17 Jul 2013 14:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJFW9Eb3KzhM for ; Wed, 17 Jul 2013 14:31:52 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A603F21F9A05 for ; Wed, 17 Jul 2013 14:31: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 r6HLVb2b027487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 17 Jul 2013 14:31:40 -0700 Message-ID: <51E70D16.10802@dcrocker.net> Date: Wed, 17 Jul 2013 14:31:02 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Stephen Kent References: <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <51E6BE72.8060500@bbn.com> <261BD146-4B2C-4528-ADF6-B7FE39F30B21@oracle.com> <51E6FE75.4080908@bbn.com> <51E7045B.3000308@cs.tcd.ie> <51E709F9.4090002@bbn.com> In-Reply-To: <51E709F9.4090002@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 17 Jul 2013 14:31:41 -0700 (PDT) Cc: "stir@ietf.org" , Stephen Farrell Subject: Re: [stir] Rollout timeframe 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, 17 Jul 2013 21:31:57 -0000 On 7/17/2013 2:17 PM, Stephen Kent wrote: > Since you were a major contributor to and proponent of DKIM and since > I chaired PKIX for >16 years folks should expect each of us to favor > technologies > with which we have extensive experience. > > Since others on the list talked explicitly in terms of certs, I think it > fair > that we discuss that technology along with other options, right? One should even look forward to a merit-oriented debate about the choices. Something that might help would be a *non-technical* description of the trust model and functional services that are needed, independent of how they are instantiated. No reference to technology beyond, perhaps, saying "storage" or "transfer". This thread has already touched on a number of these sorts of statements (requirements, ideas, whatever). What I'm suggesting is formulating a complete set into a document -- for now I don't care whether it gets published -- so that everyone can point at it and agree that that is what must be done, whether by a classic credential mechanism, DNS-based KDS, word-of-mouth rumor mill, or the like. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From stephen.farrell@cs.tcd.ie Wed Jul 17 14:59: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 E9F1721F9DFA for ; Wed, 17 Jul 2013 14:59:32 -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 2OAcr3b0A0Ee for ; Wed, 17 Jul 2013 14:59:28 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 19A3421F9DA3 for ; Wed, 17 Jul 2013 14:59:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7F853BEA1; Wed, 17 Jul 2013 22:59:05 +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 HUp4YBVAMTti; Wed, 17 Jul 2013 22:59:04 +0100 (IST) Received: from [10.87.48.9] (unknown [86.42.16.117]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 724CEBE9F; Wed, 17 Jul 2013 22:59:04 +0100 (IST) Message-ID: <51E713A7.2080605@cs.tcd.ie> Date: Wed, 17 Jul 2013 22:59:03 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Stephen Kent References: <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <51E6BE72.8060500@bbn.com> <261BD146-4B2C-4528-ADF6-B7FE39F30B21@oracle.com> <51E6FE75.4080908@bbn.com> <51E7045B.3000308@cs.tcd.ie> <51E709F9.4090002@bbn.com> In-Reply-To: <51E709F9.4090002@bbn.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] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 21:59:33 -0000 On 07/17/2013 10:17 PM, Stephen Kent wrote: > Stephen, > > Since you were a major contributor to and proponent of DKIM and since > I chaired PKIX for >16 years folks should expect each of us to favor > technologies > with which we have extensive experience. Well, I've actually more real experience with X.509 stuff, but sure. (And it is absolutely fair to say that I'm a fan of more easily deployable things these days, much more than I used be anyway, and that's partly down to chairing DKIM.) > Since others on the list talked explicitly in terms of certs, I think it > fair > that we discuss that technology along with other options, right? Oh absolutely. Like I said, certs can certainly do the functional and security job here. IMO, the doubt only relates to whether that ends up more complex than will be deployed. So I'd love to see some early work on both approaches and then for the the WG to pick one. (Assuming both survive and one doesn't wither on the vine.) S. > > Steve > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > From hadriel.kaplan@oracle.com Wed Jul 17 15:09: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 9271921F9D75 for ; Wed, 17 Jul 2013 15:09:39 -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 bxy2Xe6svIpP for ; Wed, 17 Jul 2013 15:09:33 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 19FF221F8C93 for ; Wed, 17 Jul 2013 15:09:33 -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 r6HM9TYL003010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Jul 2013 22:09:31 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 r6HM9SKw020098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jul 2013 22:09:29 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 r6HM9SaY022113; Wed, 17 Jul 2013 22:09:28 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 17 Jul 2013 15:09:28 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <3B7C3493-2D1A-434F-9278-EE908107CB7A@brianrosen.net> Date: Wed, 17 Jul 2013 18:09:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <51E6BE72.8060500@bbn.com> <261BD146-4B2C-4528-ADF6-B7FE39F30B21@oracle.com> <51E6FE7! 5 .4080908@bbn.com> <3B7C3493-2D1A-434F-9278-EE908107CB7A@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 List" Subject: [stir] The number stats (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 22:09:39 -0000 Brian, thanks for the numbers. One question regarding the 300-odd country-codes: how many distinct = numbering plan administrations are there? It's not 300 is it? I mean = there are ~200 countries in the world, and 24 countries/territories fall = under the +1 country-code.[1] I realize there are a dozen or so = non-country-things with country-codes, and another ~30 or so = organizations in the 882 and 883 country-code, but I'm kinda ignoring = them. I'm just trying to figure out how many national voice-service numbering = plan admins there are, which I thought was ~200. No? -hadriel [1] Though of course +1 is split up into separate number admins, but not = 24 of them afaik. On Jul 17, 2013, at 4:53 PM, Brian Rosen wrote: > We haven't agreed on a model for credentials yet, but some statistics: >=20 > There are several billion telephone numbers. I think most experts = believe there are more assigned numbers than people. =20 > There are 300-odd country codes > There are a few tens of thousands of service providers. If = enterprises get some form of credential, there are potentially high tens = of millions >=20 > In the US, there are 500 million or so records in the portability = database. 15 minute ports for wireless numbers is the norm, and that = includes distribution of the update to the high hundreds or low = thousands of copies of the database. It handles up to about a million = transactions a day, not all of which are ports. Numbers that are = assigned but not in the portability database are in ranges assigned to = carriers. >=20 > Brian From br@brianrosen.net Wed Jul 17 15: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 A42E521F9FBD for ; Wed, 17 Jul 2013 15:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.299 X-Spam-Level: X-Spam-Status: No, score=-100.299 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7i6sTlnQkkZn for ; Wed, 17 Jul 2013 15:19:18 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFC721F9F1F for ; Wed, 17 Jul 2013 15:19: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=S8LaBg3MtOuZyQvZSi1aKMQfTkHqvdILFvTBHamCRmQ=; b=NUMOVMLZ740dI1mDNptgdB12Gk+8cIHfvWFFVKEHar2ShHZLKXg0fmGcQKzmzDXYTWey6GlG2WiOtcqP7Y8mIW1zoatPdISSuAgnSVtKFQnWW2yUscGyy2dmYdpeUV2VvEfeRsKZt621CMaqiEwhJ5wSog9rC6YvUaV1nf6aD2Q=; Received: from neustargw.va.neustar.com ([209.173.53.233]:57034 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1Uza45-0005LU-7u; Wed, 17 Jul 2013 18:19: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: Wed, 17 Jul 2013 18:19:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <768E007B-B242-4343-81CB-68E2435F5021@brianrosen.net> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <51E6BE72.8060500@bbn.com> <261BD146-4B2C-4528-ADF6-B7FE39F30B21@oracle.com> <51E6FE7! 5 .4080908@bbn.com> <3B7C3493-2D1A-434F-9278-EE908107CB7A@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 List" Subject: Re: [stir] The number stats (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 22:19:22 -0000 http://www.wtng.info/wtng-cod.html I didn't add up how many there were. I was told 320 or something like = it, but that looks wrong. Don't think the difference between 200 and 300 is significant. Brian On Jul 17, 2013, at 6:09 PM, Hadriel Kaplan = wrote: > Brian, > thanks for the numbers. >=20 > One question regarding the 300-odd country-codes: how many distinct = numbering plan administrations are there? It's not 300 is it? I mean = there are ~200 countries in the world, and 24 countries/territories fall = under the +1 country-code.[1] I realize there are a dozen or so = non-country-things with country-codes, and another ~30 or so = organizations in the 882 and 883 country-code, but I'm kinda ignoring = them. >=20 > I'm just trying to figure out how many national voice-service = numbering plan admins there are, which I thought was ~200. No? >=20 > -hadriel > [1] Though of course +1 is split up into separate number admins, but = not 24 of them afaik. >=20 >=20 >=20 > On Jul 17, 2013, at 4:53 PM, Brian Rosen wrote: >=20 >> We haven't agreed on a model for credentials yet, but some = statistics: >>=20 >> There are several billion telephone numbers. I think most experts = believe there are more assigned numbers than people. =20 >> There are 300-odd country codes >> There are a few tens of thousands of service providers. If = enterprises get some form of credential, there are potentially high tens = of millions >>=20 >> In the US, there are 500 million or so records in the portability = database. 15 minute ports for wireless numbers is the norm, and that = includes distribution of the update to the high hundreds or low = thousands of copies of the database. It handles up to about a million = transactions a day, not all of which are ports. Numbers that are = assigned but not in the portability database are in ranges assigned to = carriers. >>=20 >> Brian >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Wed Jul 17 15:25: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 40D0F21F9956 for ; Wed, 17 Jul 2013 15:25:52 -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 fkRFzshDOo5u for ; Wed, 17 Jul 2013 15:25:46 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id D26B921F8F78 for ; Wed, 17 Jul 2013 15:25:46 -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 r6HMPhe4026698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Jul 2013 22:25: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 r6HMPgVs018464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jul 2013 22:25:43 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 r6HMPgQx029698; Wed, 17 Jul 2013 22:25:42 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 17 Jul 2013 15:25:42 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <768E007B-B242-4343-81CB-68E2435F5021@brianrosen.net> Date: Wed, 17 Jul 2013 18:25:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <51E6BE72.8060500@bbn.com> <261BD146-4B2C-4528-ADF6-B7FE39F30B21@oracle.com> <51E6FE7! ! 5 .4080908@bbn.com> <3B7C3493-2D1A-434F-9278-EE908107CB7A@brianrosen.net> <768E007B-B242-4343-81CB-68E2435F5021@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 List" Subject: Re: [stir] The number stats (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 22:25:52 -0000 On Jul 17, 2013, at 6:19 PM, Brian Rosen wrote: > http://www.wtng.info/wtng-cod.html > I didn't add up how many there were. I was told 320 or something like = it, but that looks wrong. Ah ok - yeah I think it's ~210. > Don't think the difference between 200 and 300 is significant. Nope, me neither - I was just surprised it was so much more than I = remembered. :) -hadriel From kent@bbn.com Thu Jul 18 07:17: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 07F2811E813D for ; Thu, 18 Jul 2013 07:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xWgvOhRrgfJ for ; Thu, 18 Jul 2013 07:16:59 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2201821F9E6B for ; Thu, 18 Jul 2013 07:16:59 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:57733) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Uzp0n-0005hd-5S; Thu, 18 Jul 2013 10:16:53 -0400 Message-ID: <51E7F8D4.8000103@bbn.com> Date: Thu, 18 Jul 2013 10:16:52 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Stephen Farrell References: <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <51E6BE72.8060500@bbn.com> <261BD146-4B2C-4528-ADF6-B7FE39F30B21@oracle.com> <51E6FE75.4080908@bbn.com> <51E7045B.3000308@cs.tcd.ie> <51E709F9.4090002@bbn.com> <51E713A7.2080605@cs.tcd.ie> In-Reply-To: <51E713A7.2080605@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "stir@ietf.org" Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 14:17:05 -0000 Stephen, > On 07/17/2013 10:17 PM, Stephen Kent wrote: >> Stephen, >> >> Since you were a major contributor to and proponent of DKIM and since >> I chaired PKIX for >16 years folks should expect each of us to favor >> technologies >> with which we have extensive experience. > Well, I've actually more real experience with X.509 stuff, but sure. > (And it is absolutely fair to say that I'm a fan of more easily > deployable things these days, much more than I used be anyway, and > that's partly down to chairing DKIM.) I didn't say "more easily deployable" :-) . Steve From dhc@dcrocker.net Thu Jul 18 07:22: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 8DB9321E80F5 for ; Thu, 18 Jul 2013 07:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXOZqbav1Kot for ; Thu, 18 Jul 2013 07:22:15 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id AF1F511E813D for ; Thu, 18 Jul 2013 07:22:15 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r6IELZ9U011690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Jul 2013 07:21:39 -0700 Message-ID: <51E7F9CB.5000007@dcrocker.net> Date: Thu, 18 Jul 2013 07:20:59 -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: Stephen Kent References: <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <51E6BE72.8060500@bbn.com> <261BD146-4B2C-4528-ADF6-B7FE39F30B21@oracle.com> <51E6FE75.4080908@bbn.com> <51E7045B.3000308@cs.tcd.ie> <51E709F9.4090002@bbn.com> In-Reply-To: <51E709F9.4090002@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 18 Jul 2013 07:21:39 -0700 (PDT) Cc: "stir@ietf.org" , Stephen Farrell Subject: Re: [stir] Rollout timeframe 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, 18 Jul 2013 14:22:23 -0000 On 7/17/2013 2:17 PM, Stephen Kent wrote: > > Since you were a major contributor to and proponent of DKIM and since > I chaired PKIX for >16 years folks should expect each of us to favor > technologies with which we have extensive experience. Stephen's dramatically shorter tenure with the DKIM wg might have been because it only needed a few years to get specified and then deployed widely in the global email infrastructure, unlike PKI-based mechanisms, which continue to have challenging administration and very constrained global use... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From kent@bbn.com Thu Jul 18 08:28: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 8333121E8102 for ; Thu, 18 Jul 2013 08:28: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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1pIw6FkcbRU for ; Thu, 18 Jul 2013 08:28:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id E095721E8112 for ; Thu, 18 Jul 2013 08:28:30 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:57932) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Uzq7z-000P7N-4n; Thu, 18 Jul 2013 11:28:23 -0400 Message-ID: <51E80996.1030803@bbn.com> Date: Thu, 18 Jul 2013 11:28:22 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <51E6BE72.8060500@bbn.com> <261BD146-4B2C-4528-ADF6-B7FE39F30B21@oracle.com> <51E6FE75.4080908@bbn.com> <51E7045B.3000308@cs.tcd.ie> <51E709F9.4090002@bbn.com> <51E7F9CB.5000007@dcrocker.net> In-Reply-To: <51E7F9CB.5000007@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "stir@ietf.org" , Dave Crocker , Stephen Farrell Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 15:28:51 -0000 Dave, > On 7/17/2013 2:17 PM, Stephen Kent wrote: >> >> Since you were a major contributor to and proponent of DKIM and since >> I chaired PKIX for >16 years folks should expect each of us to favor >> technologies with which we have extensive experience. > > > Stephen's dramatically shorter tenure with the DKIM wg might have been > because it only needed a few years to get specified and then deployed > widely in the global email infrastructure, unlike PKI-based > mechanisms, which continue to have challenging administration and very > constrained global use... > > d/ since DKIM's goals were much more modest with regard to email security vs. S/MIME's use of PKI, this is a largely irrelevant comparison. But if you really want to start a food fight about security technologies I'm ready. Steve From stephen.farrell@cs.tcd.ie Thu Jul 18 08:35: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 6DAE811E815F for ; Thu, 18 Jul 2013 08:35:51 -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 rFO9uqC8C9LS for ; Thu, 18 Jul 2013 08:35:45 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B338911E814C for ; Thu, 18 Jul 2013 08:34:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C5344BEB2; Thu, 18 Jul 2013 16:33:54 +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 iOMAtZKQz48z; Thu, 18 Jul 2013 16:33:50 +0100 (IST) Received: from [10.87.48.9] (unknown [86.42.16.117]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 313E7BE9A; Thu, 18 Jul 2013 16:33:50 +0100 (IST) Message-ID: <51E80ADD.4000700@cs.tcd.ie> Date: Thu, 18 Jul 2013 16:33:49 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Stephen Kent References: <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <51E6BE72.8060500@bbn.com> <261BD146-4B2C-4528-ADF6-B7FE39F30B21@oracle.com> <51E6FE75.4080908@bbn.com> <51E7045B.3000308@cs.tcd.ie> <51E709F9.4090002@bbn.com> <51E7F9CB.5000007@dcrocker.net> <51E80996.1030803@bbn. com> In-Reply-To: <51E80996.1030803@bbn.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "stir@ietf.org" , Dave Crocker , dcrocker@bbiw.net Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 15:35:51 -0000 On 07/18/2013 04:28 PM, Stephen Kent wrote: > start a food > fight about security technologies I suggest we don't. S. From dhc@dcrocker.net Thu Jul 18 12:45: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 A4E7E21E815A for ; Thu, 18 Jul 2013 12:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0gpWWKv5PhG for ; Thu, 18 Jul 2013 12:45:32 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id BF2A921E8096 for ; Thu, 18 Jul 2013 12:45:32 -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 r6IJjHGJ029047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Jul 2013 12:45:21 -0700 Message-ID: <51E845A9.6030605@dcrocker.net> Date: Thu, 18 Jul 2013 12:44:41 -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: Stephen Kent References: <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <51E6BE72.8060500@bbn.com> <261BD146-4B2C-4528-ADF6-B7FE39F30B21@oracle.com> <51E6FE75.4080908@bbn.com> <51E7045B.3000308@cs.tcd.ie> <51E709F9.4090002@bbn.com> <51E7F9CB.5000007@dcrocker.net> <51E80996.1030803@bbn! .com> In-Reply-To: <51E80996.1030803@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 18 Jul 2013 12:45:23 -0700 (PDT) Cc: "stir@ietf.org" , Stephen Farrell Subject: Re: [stir] Rollout timeframe 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, 18 Jul 2013 19:45:37 -0000 On 7/18/2013 8:28 AM, Stephen Kent wrote: >> Stephen's dramatically shorter tenure with the DKIM wg might have been >> because it only needed a few years to get specified and then deployed ... > since DKIM's goals were much more modest with regard to email security > vs. S/MIME's use > of PKI, this is a largely irrelevant comparison. But if you really want > to start a food > fight about security technologies I'm ready. Steve, Thanks for up-leveling to a point of significant substance, namely the importance of the functional goal in choosing among alternative designs. In the current context, it exactly targets the core question of the functional goal for Caller-ID validation, with eye towards carefully considering the pragmatics of a very constrained mechanism for this very constrained goal. At a significantly more 'meta' level -- which will probably cause Stephen F to roll his eyes now as he always did when I attempted this during the DKIM effort -- it suggests the benefit of formulating and attacking narrower goals with narrower solutions and the detriment of trying, instead, to create broader and more general solutions. Divide and conquer on complex problems is good for humans, as well as computers... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Henning.Schulzrinne@fcc.gov Thu Jul 18 15:49: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 7991321E8152 for ; Thu, 18 Jul 2013 15:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.525, 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 Qp4ngcKKQMdv for ; Thu, 18 Jul 2013 15:49:36 -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 877D821E8145 for ; Thu, 18 Jul 2013 15:49:32 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Hadriel Kaplan' , Brian Rosen Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) Thread-Index: AQHOgoiaZJ964/Jc8k6czqEIJ08Lk5loauiAgAAh1ACAAJo+gIAAEIiAgAACsACAACgJAIABqUjg Date: Thu, 18 Jul 2013 22:49:20 +0000 References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! ! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> <84432CF7-A220-46F0-B945-F41F09F7061E@oracle.com> In-Reply-To: <84432CF7-A220-46F0-B945-F41F09F7061E@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 List" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 22:49:41 -0000 As long as you allow multiple public-private key pairs for one number (whic= h we need for the legitimate spoofing cases anyway), porting isn't a big de= al. The likelihood that the entity that got their number ported away will s= uddenly start spoofing that number seems pretty remote, particularly since = it would be trivial to detect who did it. Thus, rapid key expiration does n= ot appear to be a major issue - nice to have, but we don't have to expire e= very record every 10 minutes. The model we'd want is probably something a b= it different than typical: namely, if the cached cert/public key works, don= e. If there's a mismatch, a new holder may have been added and a query is n= eeded. This would only affect a very small fraction of calls for reasonable= expiration times (days to a week). -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Had= riel Kaplan Sent: Wednesday, July 17, 2013 1:22 PM To: Brian Rosen Cc: stir@ietf.org List Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) On Jul 17, 2013, at 10:58 AM, Brian Rosen wrote: > Small note: > You would have to keep TTLs for at least U.S. zones under a few minutes t= o allow the 15 minute port. > I'd actually probably set it at a minute or two. I'm not sure if it really matters if the TTL is short, but it doesn't have = to be short - at least not with CIDER. The DNS name uses a "key index", wh= ich identifies which specific public key was used for signing the call - i.= e., a single E.164 can have multiple public keys in DNS. (it's like a DKIM = "selector", but an integer instead of string) That key index value is sent= in the SIP header. It then becomes part of the generated DNS name used fo= r the lookup. So when a key changes, the DNS full name changes, and there'= s no cache collision. You have to do something like that no matter what solution we end up with (= even HTTP), because the carriers have to be able to change their key whenev= er they want without affecting in-flight call requests, and give time for t= he new key to propagate to the local copies carriers might have of the whol= e DB. Plus it lets two or more agents claim the same phone number, for exa= mple the outsourced call-center or medical doctor scenarios. From hadriel.kaplan@oracle.com Thu Jul 18 16:02: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 50BBC11E823E for ; Thu, 18 Jul 2013 16:02:28 -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 cPiEEifXR9Di for ; Thu, 18 Jul 2013 16:02:22 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id F397F11E8241 for ; Thu, 18 Jul 2013 16:02:19 -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 r6IN2HFd020959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Jul 2013 23:02:18 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 r6IN2GnX007455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jul 2013 23:02:17 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 r6IN2GV2008121; Thu, 18 Jul 2013 23:02:16 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Jul 2013 16:02:16 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Thu, 18 Jul 2013 19:02:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1E1AA91D-F3C8-4B43-A647-F898B9AB9778@oracle.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! ! ! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> <84432CF7-A220-46F0-B945-F41F09F7061E@oracle.com> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "stir@ietf.org List" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 23:02:28 -0000 Yup, agreed - I was just responding to Brian's concern that using a = DNS-based approach would require low TTL values, in order to support = porting. It doesn't require that. With regards to using certs: I don't think porting a number would = require a cert revocation, but the verifying systems would have to check = revocations, because private keys will get compromised ultimately. -hadriel On Jul 18, 2013, at 6:49 PM, Henning Schulzrinne = wrote: > As long as you allow multiple public-private key pairs for one number = (which we need for the legitimate spoofing cases anyway), porting isn't = a big deal. The likelihood that the entity that got their number ported = away will suddenly start spoofing that number seems pretty remote, = particularly since it would be trivial to detect who did it. Thus, rapid = key expiration does not appear to be a major issue - nice to have, but = we don't have to expire every record every 10 minutes. The model we'd = want is probably something a bit different than typical: namely, if the = cached cert/public key works, done. If there's a mismatch, a new holder = may have been added and a query is needed. This would only affect a very = small fraction of calls for reasonable expiration times (days to a = week). >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Hadriel Kaplan > Sent: Wednesday, July 17, 2013 1:22 PM > To: Brian Rosen > Cc: stir@ietf.org List > Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) >=20 >=20 > On Jul 17, 2013, at 10:58 AM, Brian Rosen wrote: >=20 >> Small note: >> You would have to keep TTLs for at least U.S. zones under a few = minutes to allow the 15 minute port. >> I'd actually probably set it at a minute or two. >=20 > I'm not sure if it really matters if the TTL is short, but it doesn't = have to be short - at least not with CIDER. The DNS name uses a "key = index", which identifies which specific public key was used for signing = the call - i.e., a single E.164 can have multiple public keys in DNS. = (it's like a DKIM "selector", but an integer instead of string) That = key index value is sent in the SIP header. It then becomes part of the = generated DNS name used for the lookup. So when a key changes, the DNS = full name changes, and there's no cache collision. >=20 > You have to do something like that no matter what solution we end up = with (even HTTP), because the carriers have to be able to change their = key whenever they want without affecting in-flight call requests, and = give time for the new key to propagate to the local copies carriers = might have of the whole DB. Plus it lets two or more agents claim the = same phone number, for example the outsourced call-center or medical = doctor scenarios. >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From richard@shockey.us Thu Jul 18 21:36:47 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2EF11E8286 for ; Thu, 18 Jul 2013 21:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.628 X-Spam-Level: X-Spam-Status: No, score=-100.628 tagged_above=-999 required=5 tests=[AWL=-0.964, 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 bYkg9CAUjETf for ; Thu, 18 Jul 2013 21:36:43 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 51B0511E8289 for ; Thu, 18 Jul 2013 21:36:38 -0700 (PDT) Received: (qmail 30951 invoked by uid 0); 19 Jul 2013 04:36:09 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.bluehost.com with SMTP; 19 Jul 2013 04:36:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=kRd+BtoOmZl+R+I/NcPma6dAZ7AgSO2T7LEm7P8B3FA=; b=A0riFU42StzFqESrjjE/fd1sO5QKdG2ZEKtJxR8Mv696S5N5jZKIUjTxKroT1DHdLUChL0fe1nEklKTNELY5ZUJd88f4OgO+rqOd5me2nBYiW0UfIki6ppi2hnpH6trU; Received: from [72.66.111.124] (port=57737 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V02QL-0007YE-C4 for stir@ietf.org; Thu, 18 Jul 2013 22:36:09 -0600 From: "Richard Shockey" To: Date: Fri, 19 Jul 2013 00:36:07 -0400 Message-ID: <01ed01ce8439$7d09f550$771ddff0$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01EE_01CE8417.F5F8A370" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac6EOW4AFnhx4vNwRMatMQG8Xqr3nA== 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] In case you had the slightest doubt of the problem we are trying to solve X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jul 2013 04:36:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01EE_01CE8417.F5F8A370 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is one of the worst. http://www.latimes.com/business/la-fi-phone-hacking-20130719,0,5710787.story 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_01EE_01CE8417.F5F8A370 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is one of the worst…

 

http://www.latimes.com/business/la-fi-phone-hacking-201= 30719,0,5710787.story

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_01EE_01CE8417.F5F8A370-- From bernard.aboba@gmail.com Thu Jul 18 22:46:57 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B660911E82A3 for ; Thu, 18 Jul 2013 22:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ySvvjEDlokEN for ; Thu, 18 Jul 2013 22:46:39 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 501A111E8282 for ; Thu, 18 Jul 2013 22:46:39 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id z10so3871305pdj.3 for ; Thu, 18 Jul 2013 22:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=9hx+m6e3T/nv20rA2yE9O1ddpgQ/N+5EOYVmyuJG8K4=; b=DhGLxMRUsoNUrz42cOgMTBNjvzRqpyTfQvZBtwU+fHB/gYF5Nh28wccKlN9sCWjt21 1qoYlOJma/G35pU3LHCdfoDf1zjxD8frujgvHKfKUQT7elThHKYcQ28MsWO2z4c4aKH0 JDnLTMc3UrNl14+LxHzh6Mwgm/Woy+j6QHDD08AGlrADCbo1bgOXF9s9jc+SEUvYj3ol af7akT7PxHTF+Bgl4QmyG/kIdJmhb+3USHKsFlHTr8BMjX52cPeud2fv6GPbhOpqMhZv 29nSsVSrCAfGdHd16WLB6j4RuQXH7d0lQwhkoleI9LXuEr0Q1y0R5hmC8yMOqGD2flzg fPAQ== X-Received: by 10.66.102.41 with SMTP id fl9mr16698027pab.169.1374212796534; Thu, 18 Jul 2013 22:46:36 -0700 (PDT) Received: from [192.168.1.145] (c-24-16-96-166.hsd1.wa.comcast.net. [24.16.96.166]) by mx.google.com with ESMTPSA id x8sm17451348pbb.39.2013.07.18.22.46.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Jul 2013 22:46:35 -0700 (PDT) References: <01ed01ce8439$7d09f550$771ddff0$@shockey.us> Mime-Version: 1.0 (1.0) In-Reply-To: <01ed01ce8439$7d09f550$771ddff0$@shockey.us> Content-Type: multipart/alternative; boundary=Apple-Mail-BED3B286-511E-4879-883D-DE50D156B931 Content-Transfer-Encoding: 7bit Message-Id: <76055977-247C-42D1-8E4F-2C4EB8A5278C@gmail.com> X-Mailer: iPhone Mail (10B329) From: Bernard Aboba Date: Thu, 18 Jul 2013 22:46:33 -0700 To: Richard Shockey Cc: "" Subject: Re: [stir] In case you had the slightest doubt of the problem we are trying to solve X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jul 2013 05:46:57 -0000 --Apple-Mail-BED3B286-511E-4879-883D-DE50D156B931 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Actually, no. Extortion attacks often use compromised PBXes, so they need n= ot forge caller-identification. Open a PBX to incoming SIP from anywhere and= check the logs. You will see lots of "background radiation" originating fro= m a wide range of addresses. Forget blacklisting - we are way past that now.= =20 On Jul 18, 2013, at 9:36 PM, "Richard Shockey" wrote: > This is one of the worst=E2=80=A6 > =20 > http://www.latimes.com/business/la-fi-phone-hacking-20130719,0,5710787.sto= ry > Richard Shockey > Shockey Consulting > Chairman of the Board of Directors SIP Forum > PSTN Mobile: +1 703.593.2683 > > skype-linkedin-facebook: rshockey101 > http//www.sipforum.org >=20 > =20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail-BED3B286-511E-4879-883D-DE50D156B931 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Actually, no.  Extortion attacks o= ften use compromised PBXes, so they need not forge caller-identification. Op= en a PBX to incoming SIP from anywhere and check the logs. You will see lots= of "background radiation" originating from a wide range of addresses. Forge= t blacklisting - we are way past that now. 

On Jul 18, 20= 13, at 9:36 PM, "Richard Shockey" <= richard@shockey.us> wrote:

<= style>

This is one of the worst=E2=80=A6

 

http://www.lat= imes.com/business/la-fi-phone-hacking-20130719,0,5710787.story

Richard Shockey
Shockey Consulting
Chairman of t= he Board of Directors SIP Forum
PSTN Mobile: +1 703.593.2683
<mailto:richar= d(at)shockey.us>
skype-linkedin-facebook: rshockey101
ht= tp//www.sipforum.org

 

__________________= _____________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailm= an/listinfo/stir
= --Apple-Mail-BED3B286-511E-4879-883D-DE50D156B931-- From hadriel.kaplan@oracle.com Fri Jul 19 07:17: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 228BD11E82B0 for ; Fri, 19 Jul 2013 07:17:59 -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.105, 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 dVMm9ZmbaNuJ for ; Fri, 19 Jul 2013 07:17:54 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC8A11E81E6 for ; Fri, 19 Jul 2013 07:17:53 -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 r6JEHpwV022841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 19 Jul 2013 14:17:52 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 r6JEHnMW012937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 14:17:51 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 r6JEHn10001794; Fri, 19 Jul 2013 14:17:49 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 19 Jul 2013 07:17:49 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_CDA6BC46-CA54-4D3C-A3FE-E0B1EAE87693" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <76055977-247C-42D1-8E4F-2C4EB8A5278C@gmail.com> Date: Fri, 19 Jul 2013 10:17:47 -0400 Message-Id: <27E962B1-B56B-4F59-8175-8EB223DCFD0A@oracle.com> References: <01ed01ce8439$7d09f550$771ddff0$@shockey.us> <76055977-247C-42D1-8E4F-2C4EB8A5278C@gmail.com> To: Bernard Aboba X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "" , Richard Shockey Subject: Re: [stir] In case you had the slightest doubt of the problem we are trying to solve X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jul 2013 14:17:59 -0000 --Apple-Mail=_CDA6BC46-CA54-4D3C-A3FE-E0B1EAE87693 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Yeah, the article is inconsistent and self-contradictory. For example, = it says: "The hospital attack, confirmed by two independent sources familiar with = it, was eventually stopped using a computer firewall filter. " If a computer "firewall" filter could stop it, then it wasn't caused by = caller-id spoofing coming through their SIP/whatever trunk. It was = caused by not restricting communications to only be possible from the = trunk provider. Even a simple router/firewall ACL would have stopped = it. They simply didn't secure their deployment the way everyone should = and could today already do. And the article starts with: "She had picked up the emergency room's phone line, expecting to hear a = dispatcher or a doctor. But instead, an unfamiliar male greeted her by = name and then threatened to paralyze the hospital's phone service if she = didn't pay him hundreds of dollars." That's got nothing to do with "flooding lines". That's just a typical = PBX hacking case - which is a common problem, and has been going on for = decades. This used to happen now and then on Nortel Meridian and Lucent = Merlin/Definity PBXs back in the day, too. The CFCA lists PBX hacking = as the #1 fraud cost worldwide, at over $4 Billion. That's more than = even international revenue share fraud. The good news is if we get STIR deployed it will at least be easier to = track down the culprits, and it may even help prevent some specific = forms of PBX hacks (maybe). But STIR is not a silver bullet to prevent = DoS attacks, and won't overcome the issues with people deploying stuff = in an insecure manner - like, for example not changing the default PBX = password/pin for administration, or not deploying a firewall or SBC = correctly. Only education can help with that. -hadriel On Jul 19, 2013, at 1:46 AM, Bernard Aboba = wrote: > Actually, no. Extortion attacks often use compromised PBXes, so they = need not forge caller-identification. Open a PBX to incoming SIP from = anywhere and check the logs. You will see lots of "background radiation" = originating from a wide range of addresses. Forget blacklisting - we are = way past that now.=20 >=20 > On Jul 18, 2013, at 9:36 PM, "Richard Shockey" = wrote: >=20 >> This is one of the worst=85 >> =20 >> = http://www.latimes.com/business/la-fi-phone-hacking-20130719,0,5710787.sto= ry >> Richard Shockey >> Shockey Consulting >> Chairman of the Board of Directors SIP Forum >> PSTN Mobile: +1 703.593.2683 >> >> skype-linkedin-facebook: rshockey101 >> http//www.sipforum.org >>=20 >> =20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_CDA6BC46-CA54-4D3C-A3FE-E0B1EAE87693 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 "The hospital attack, confirmed by two independent = sources familiar with it, was eventually stopped using a computer = firewall filter. "

If a computer = "firewall" filter could stop it, then it wasn't caused by caller-id = spoofing coming through their SIP/whatever trunk.  It was caused by = not restricting communications to only be possible from the trunk = provider.  Even a simple router/firewall ACL would have stopped it. =  They simply didn't secure their deployment the way everyone should = and could today already do.

And the article = starts with:
"She had picked up the = emergency room's phone line, expecting to hear a dispatcher or a doctor. = But instead, an unfamiliar male greeted her by name and then threatened = to paralyze the hospital's phone service if she didn't pay him hundreds = of dollars."

That's got nothing to do = with "flooding lines".  That's just a typical PBX hacking case - = which is a common problem, and has been going on for decades.  This = used to happen now and then on Nortel Meridian and Lucent = Merlin/Definity PBXs back in the day, too.  The CFCA lists PBX = hacking as the #1 fraud cost worldwide, at over $4 Billion.  That's = more than even international revenue share = fraud.

The good news is if we get STIR deployed = it will at least be easier to track down the culprits, and it may even = help prevent some specific forms of PBX hacks (maybe).  But STIR is = not a silver bullet to prevent DoS attacks, and won't overcome the = issues with people deploying stuff in an insecure manner - like, for = example not changing the default PBX password/pin for = administration, or not deploying a firewall or SBC correctly.  Only = education can help with = that.

-hadriel


= On Jul 19, 2013, at 1:46 AM, Bernard Aboba <bernard.aboba@gmail.com> = wrote:

Actually, no.  Extortion = attacks often use compromised PBXes, so they need not forge = caller-identification. Open a PBX to incoming SIP from anywhere and = check the logs. You will see lots of "background radiation" originating = from a wide range of addresses. Forget blacklisting - we are way past = that now. 

On Jul 18, 2013, at 9:36 PM, "Richard = Shockey" <richard@shockey.us> = wrote:

This is one of the worst=85

 

http://www.latimes.com/business/la-fi-phone-hacking-20130719,0= ,5710787.story

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

 

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

= --Apple-Mail=_CDA6BC46-CA54-4D3C-A3FE-E0B1EAE87693-- From br@brianrosen.net Fri Jul 19 07:22: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 813B811E82A8 for ; Fri, 19 Jul 2013 07:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.305 X-Spam-Level: X-Spam-Status: No, score=-100.305 tagged_above=-999 required=5 tests=[AWL=0.131, 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 FtNeGOg1f2-t for ; Fri, 19 Jul 2013 07:22:13 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id D0C3A11E812C for ; Fri, 19 Jul 2013 07:22: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=PUx8ol1JjOkSmR82nPyofB/98g6L9b7tfKljVk5K67k=; b=AjDY7jFmEoyIvFENfi96bxazYq6ylKEVHua160Z5qP4qOdrNWZ14TzV7cWq52230/ozv69btg1pIOieFiEhwbtXw6pvL/GT7dlD/EjCX786cQXiL0tCuf+iW8Knzr70DSMWV3NYbekXvgJ2bXJ79oSsEV1krtDsfWvVErSelXKE=; Received: from neustargw.va.neustar.com ([209.173.53.233]:53700 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1V0BZS-0007eF-TH; Fri, 19 Jul 2013 10:22:11 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_B87E26B5-7B2E-4A87-8FC7-36806EC70E34" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <27E962B1-B56B-4F59-8175-8EB223DCFD0A@oracle.com> Date: Fri, 19 Jul 2013 10:22:09 -0400 Message-Id: <181B30AE-6CCC-49D3-988D-D566486442DC@brianrosen.net> References: <01ed01ce8439$7d09f550$771ddff0$@shockey.us> <76055977-247C-42D1-8E4F-2C4EB8A5278C@gmail.com> <27E962B1-B56B-4F59-8175-8EB223DCFD0A@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: "" , Richard Shockey , Bernard Aboba Subject: Re: [stir] In case you had the slightest doubt of the problem we are trying to solve X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jul 2013 14:22:23 -0000 --Apple-Mail=_B87E26B5-7B2E-4A87-8FC7-36806EC70E34 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Right. That means we have to be careful when we say we're aiming to stop = robocalling, vishing and swatting. If the vish or swat is accomplished = by compromising a legitimate UA, what we're doing won't help. It's only = when they are impersonating a UA that we may be able to help. Brian On Jul 19, 2013, at 10:17 AM, Hadriel Kaplan = wrote: >=20 > Yeah, the article is inconsistent and self-contradictory. For = example, it says: > "The hospital attack, confirmed by two independent sources familiar = with it, was eventually stopped using a computer firewall filter. " >=20 > If a computer "firewall" filter could stop it, then it wasn't caused = by caller-id spoofing coming through their SIP/whatever trunk. It was = caused by not restricting communications to only be possible from the = trunk provider. Even a simple router/firewall ACL would have stopped = it. They simply didn't secure their deployment the way everyone should = and could today already do. >=20 > And the article starts with: > "She had picked up the emergency room's phone line, expecting to hear = a dispatcher or a doctor. But instead, an unfamiliar male greeted her by = name and then threatened to paralyze the hospital's phone service if she = didn't pay him hundreds of dollars." >=20 > That's got nothing to do with "flooding lines". That's just a typical = PBX hacking case - which is a common problem, and has been going on for = decades. This used to happen now and then on Nortel Meridian and Lucent = Merlin/Definity PBXs back in the day, too. The CFCA lists PBX hacking = as the #1 fraud cost worldwide, at over $4 Billion. That's more than = even international revenue share fraud. >=20 > The good news is if we get STIR deployed it will at least be easier to = track down the culprits, and it may even help prevent some specific = forms of PBX hacks (maybe). But STIR is not a silver bullet to prevent = DoS attacks, and won't overcome the issues with people deploying stuff = in an insecure manner - like, for example not changing the default PBX = password/pin for administration, or not deploying a firewall or SBC = correctly. Only education can help with that. >=20 > -hadriel >=20 >=20 > On Jul 19, 2013, at 1:46 AM, Bernard Aboba = wrote: >=20 >> Actually, no. Extortion attacks often use compromised PBXes, so they = need not forge caller-identification. Open a PBX to incoming SIP from = anywhere and check the logs. You will see lots of "background radiation" = originating from a wide range of addresses. Forget blacklisting - we are = way past that now.=20 >>=20 >> On Jul 18, 2013, at 9:36 PM, "Richard Shockey" = wrote: >>=20 >>> This is one of the worst=85 >>> =20 >>> = http://www.latimes.com/business/la-fi-phone-hacking-20130719,0,5710787.sto= ry >>> Richard Shockey >>> Shockey Consulting >>> Chairman of the Board of Directors SIP Forum >>> PSTN Mobile: +1 703.593.2683 >>> >>> skype-linkedin-facebook: rshockey101 >>> http//www.sipforum.org >>>=20 >>> =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 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_B87E26B5-7B2E-4A87-8FC7-36806EC70E34 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 hadriel.kaplan@oracle.com>= ; wrote:

"The hospital attack, confirmed by two independent = sources familiar with it, was eventually stopped using a computer = firewall filter. "

If a computer = "firewall" filter could stop it, then it wasn't caused by caller-id = spoofing coming through their SIP/whatever trunk.  It was caused by = not restricting communications to only be possible from the trunk = provider.  Even a simple router/firewall ACL would have stopped it. =  They simply didn't secure their deployment the way everyone should = and could today already do.

And the article = starts with:
"She had picked up the = emergency room's phone line, expecting to hear a dispatcher or a doctor. = But instead, an unfamiliar male greeted her by name and then threatened = to paralyze the hospital's phone service if she didn't pay him hundreds = of dollars."

That's got nothing to do = with "flooding lines".  That's just a typical PBX hacking case - = which is a common problem, and has been going on for decades.  This = used to happen now and then on Nortel Meridian and Lucent = Merlin/Definity PBXs back in the day, too.  The CFCA lists PBX = hacking as the #1 fraud cost worldwide, at over $4 Billion.  That's = more than even international revenue share = fraud.

The good news is if we get STIR deployed = it will at least be easier to track down the culprits, and it may even = help prevent some specific forms of PBX hacks (maybe).  But STIR is = not a silver bullet to prevent DoS attacks, and won't overcome the = issues with people deploying stuff in an insecure manner - like, for = example not changing the default PBX password/pin for = administration, or not deploying a firewall or SBC correctly.  Only = education can help with = that.

-hadriel


= On Jul 19, 2013, at 1:46 AM, Bernard Aboba <bernard.aboba@gmail.com> = wrote:

Actually, no.  Extortion = attacks often use compromised PBXes, so they need not forge = caller-identification. Open a PBX to incoming SIP from anywhere and = check the logs. You will see lots of "background radiation" originating = from a wide range of addresses. Forget blacklisting - we are way past = that now. 

On Jul 18, 2013, at 9:36 PM, "Richard = Shockey" <richard@shockey.us> = wrote:

This is one of the worst=85

 

http://www.latimes.com/business/la-fi-phone-hacking-20130719,0= ,5710787.story

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

 

_______________________________________________=
stir mailing list
stir@ietf.org
https://www.ietf.org/m= ailman/listinfo/stir
____________________= ___________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/m= ailman/listinfo/stir

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

= --Apple-Mail=_B87E26B5-7B2E-4A87-8FC7-36806EC70E34-- From bernard.aboba@gmail.com Fri Jul 19 08:04: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 B80BA11E82B3 for ; Fri, 19 Jul 2013 08:04:13 -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 d5NFOA0pgBkk for ; Fri, 19 Jul 2013 08:04:12 -0700 (PDT) Received: from mail-qe0-x234.google.com (mail-qe0-x234.google.com [IPv6:2607:f8b0:400d:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9E911E82B5 for ; Fri, 19 Jul 2013 08:03:54 -0700 (PDT) Received: by mail-qe0-f52.google.com with SMTP id i11so2478917qej.39 for ; Fri, 19 Jul 2013 08:03:54 -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=9oZOwoYLKaN60GI8Ym1lODXLOLuwbLxuPzqVZ/uiglU=; b=jHwRkbsdghH/bEU42ukAe2U3TqlWsAj0/7f009FHI/qhauhTRu9n3qSfigQaQ3Y1Cu liEyixR//zsvk+f2Qz7tyjQ3WTyZX6VUTUp0hT5eb0ZckEUAcJeehB3iVXAK7xQNtDzx bzXnJdNmlooqxSMKj0ISqCWpQ2gbfQk/25hOtoXcH5BBfZSUpWvD25mhPE8yu9TB17ms XPHmeaWt3GjxQjLsZpzfth95laipDpbTVglAP/8nPou/CMYPWHTF0b9XMfBNUs5mRPtt NrshcqKJ8F17ljcBEoEXqlQ+7+jKuiOpaW8yvHcGmz3hWlUmnRU03J+cfTAIFNXOG7YM 0fVw== X-Received: by 10.229.77.91 with SMTP id f27mr4271874qck.31.1374246234066; Fri, 19 Jul 2013 08:03:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.26.131 with HTTP; Fri, 19 Jul 2013 08:03:34 -0700 (PDT) In-Reply-To: <76055977-247C-42D1-8E4F-2C4EB8A5278C@gmail.com> References: <01ed01ce8439$7d09f550$771ddff0$@shockey.us> <76055977-247C-42D1-8E4F-2C4EB8A5278C@gmail.com> From: Bernard Aboba Date: Fri, 19 Jul 2013 08:03:34 -0700 Message-ID: To: Richard Shockey Content-Type: multipart/alternative; boundary=002354471a889db0de04e1dea200 Cc: "" Subject: Re: [stir] In case you had the slightest doubt of the problem we are trying to solve X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jul 2013 15:04:13 -0000 --002354471a889db0de04e1dea200 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable To get an idea of how prevalent this is, take a look at this: http://www.darkreading.com/attacks-breaches/voip-abuse-project-blacklists-a= ttackers/227500994 On Thu, Jul 18, 2013 at 10:46 PM, Bernard Aboba wr= ote: > Actually, no. Extortion attacks often use compromised PBXes, so they nee= d > not forge caller-identification. Open a PBX to incoming SIP from anywhere > and check the logs. You will see lots of "background radiation" originati= ng > from a wide range of addresses. Forget blacklisting - we are way past tha= t > now. > > On Jul 18, 2013, at 9:36 PM, "Richard Shockey" wrote= : > > This is one of the worst=85 **** > > ** ** > > > http://www.latimes.com/business/la-fi-phone-hacking-20130719,0,5710787.st= ory > **** > > 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 > > --002354471a889db0de04e1dea200 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
To get an idea of how prevalent this is, take a look at this:
http://www.darkreading.com/attacks-breach= es/voip-abuse-project-blacklists-attackers/227500994

On Thu, Jul 18, 2013 at 10:46 PM, Bern= ard Aboba <bernard.aboba@gmail.com> wrote:
Actually, no. =A0Extortion attacks often use comprom= ised PBXes, so they need not forge caller-identification. Open a PBX to inc= oming SIP from anywhere and check the logs. You will see lots of "back= ground radiation" originating from a wide range of addresses. Forget b= lacklisting - we are way past that now.=A0

On Jul 18, 2013, at 9:36 PM, "Richard = Shockey" <r= ichard@shockey.us> wrote:

This is one of the worst=85

=A0

http://www.latimes.com/business/la-fi-phone-hacking-20130= 719,0,5710787.story

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

=A0

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

--002354471a889db0de04e1dea200-- From robert.kinder@cox.com Fri Jul 19 08:19: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 8DF8C11E80E3 for ; Fri, 19 Jul 2013 08:19: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=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, 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 Klqi8GqLF+Bg for ; Fri, 19 Jul 2013 08:19:54 -0700 (PDT) Received: from post1.cox.com (post1.cox.com [24.248.74.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA8021F9EA3 for ; Fri, 19 Jul 2013 08:19:54 -0700 (PDT) Received: from ([192.168.74.254]) by post1.cox.com with ESMTP with TLS id J041136010.228877144; Fri, 19 Jul 2013 11:19:49 -0400 Received: from CATL0MS110.corp.cox.com ([fe80::d803:3705:5a33:4091]) by CATL0MS402.corp.cox.com ([10.62.236.89]) with mapi; Fri, 19 Jul 2013 11:19:49 -0400 From: "Kinder, Robert (CCI-Atlanta)" To: Bernard Aboba , Richard Shockey , "" Date: Fri, 19 Jul 2013 11:19:47 -0400 Thread-Topic: [stir] In case you had the slightest doubt of the problem we are trying to solve Thread-Index: Ac6EkU0PxcjU+HUeT1m9pXdnT6trGQAAearQ Message-ID: References: <01ed01ce8439$7d09f550$771ddff0$@shockey.us> <76055977-247C-42D1-8E4F-2C4EB8A5278C@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_CCE172AA625E77409A8B0B96892B1180025DD6ED8BCATL0MS110cor_"; type="multipart/alternative" MIME-Version: 1.0 X-CCI: ESP<0>= SHA:<0> SHA_FLAGS:<0> UHA:<0> ISC:<0> BAYES:<0> SenderID:<0> DKIM:<0> TS:<0> SIG:<> TRU_lotto_spam: <0> TRU_scam_spam: <0> TRU_legal_spam: <0> TRU_profanity_spam: <0> TRU_stock_spam: <0> TRU_money_spam: <0> TRU_spam1: <0> TRU_playsites: <0> TRU_phish_spam: <0> TRU_watch_spam: <0> TRU_medical_spam: <0> TRU_adult_spam: <0> TRU_freehosting: <0> TRU_urllinks: <0> Subject: Re: [stir] In case you had the slightest doubt of the problem we are trying to solve X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jul 2013 15:19:58 -0000 --_004_CCE172AA625E77409A8B0B96892B1180025DD6ED8BCATL0MS110cor_ Content-Type: multipart/alternative; boundary="_000_CCE172AA625E77409A8B0B96892B1180025DD6ED8BCATL0MS110cor_" --_000_CCE172AA625E77409A8B0B96892B1180025DD6ED8BCATL0MS110cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable An in depth review of TDoS: https://krebsonsecurity.com/2013/04/dhs-warns-of-tdos-extortion-attacks-on-= public-emergency-networks/ Robert From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Ber= nard Aboba Sent: Friday, July 19, 2013 11:04 AM To: Richard Shockey Cc: Subject: Re: [stir] In case you had the slightest doubt of the problem we a= re trying to solve To get an idea of how prevalent this is, take a look at this: http://www.darkreading.com/attacks-breaches/voip-abuse-project-blacklists-a= ttackers/227500994 On Thu, Jul 18, 2013 at 10:46 PM, Bernard Aboba > wrote: Actually, no. Extortion attacks often use compromised PBXes, so they need = not forge caller-identification. Open a PBX to incoming SIP from anywhere a= nd check the logs. You will see lots of "background radiation" originating = from a wide range of addresses. Forget blacklisting - we are way past that = now. On Jul 18, 2013, at 9:36 PM, "Richard Shockey" > wrote: This is one of the worst... http://www.latimes.com/business/la-fi-phone-hacking-20130719,0,5710787.stor= y Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683[cid:~WRD000.jpg] skype-linkedin-facebook: rshockey101 http//www.sipforum.org _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_CCE172AA625E77409A8B0B96892B1180025DD6ED8BCATL0MS110cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

An in dep= th review of TDoS:

https://krebsonsecurity.com/2013/04/dhs-war= ns-of-tdos-extortion-attacks-on-public-emergency-networks/

 

Robert

 

 <= /span>

From: stir-bounces@ietf.org [mailto:stir-bounc= es@ietf.org] On Behalf Of Bernard Aboba
Sent: Friday, July= 19, 2013 11:04 AM
To: Richard Shockey
Cc: <stir@iet= f.org>
Subject: Re: [stir] In case you had the slightest doubt= of the problem we are trying to solve

 

To get an idea of how = prevalent this is, take a look at this:

On Thu= , Jul 18, 2013 at 10:46 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:=

Actually, no.  Extortion atta= cks often use compromised PBXes, so they need not forge caller-identificati= on. Open a PBX to incoming SIP from anywhere and check the logs. You will s= ee lots of "background radiation" originating from a wide range o= f addresses. Forget blacklisting - we are way past that now. 


On Jul 18, 2013, at 9:36 PM, "Richard Shockey" <richard@shockey.us>= ; wrote:

This is one of the worst…

 

http:/= /www.latimes.com/business/la-fi-phone-hacking-20130719,0,5710787.story<= o:p>

Richard Shockey
Shockey Consulting
Chairma= n of the Board of Directors SIP Forum
PSTN Mobile: +1 703.593.26833D"Image
<mailto:richard(at)shockey.us>
skype-linkedin-faceb= ook: rshockey101
http//www.sipforum.org

 

__________________________= _____________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listi= nfo/stir

 

= --_000_CCE172AA625E77409A8B0B96892B1180025DD6ED8BCATL0MS110cor_-- --_004_CCE172AA625E77409A8B0B96892B1180025DD6ED8BCATL0MS110cor_ Content-Type: image/jpeg; name="~WRD000.jpg" Content-Description: ~WRD000.jpg Content-Disposition: inline; filename="~WRD000.jpg"; size=823; creation-date="Fri, 19 Jul 2013 15:18:24 GMT"; modification-date="Fri, 19 Jul 2013 15:18:24 GMT" Content-ID: <~WRD000.jpg> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigD//2Q== --_004_CCE172AA625E77409A8B0B96892B1180025DD6ED8BCATL0MS110cor_-- From Henning.Schulzrinne@fcc.gov Fri Jul 19 08:58: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 8998511E814D for ; Fri, 19 Jul 2013 08:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.510, 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 aQYFfnOmzIDE for ; Fri, 19 Jul 2013 08:58:03 -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 897B621E80DD for ; Fri, 19 Jul 2013 08:58:01 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Hadriel Kaplan Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) Thread-Index: AQHOgoiaZJ964/Jc8k6czqEIJ08Lk5loauiAgAAh1ACAAJo+gIAAEIiAgAACsACAACgJAIABqUjggABIKACAANgXqw== Date: Fri, 19 Jul 2013 15:57:56 +0000 References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! ! ! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> <84432CF7-A220-46F0-B945-F41F09F7061E@oracle.com> , <1E1AA91D-F3C8-4B43-A647-F898B9AB9778@oracle.com> In-Reply-To: <1E1AA91D-F3C8-4B43-A647-F898B9AB9778@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 List" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 15:58:09 -0000 Since both revocations and ports are relatively rare and the number of vali= dators is relatively small (thousands, not millions), I suspect that a pub-= sub approach may well be better suited than querying the origin server or D= NS authoritative server for each validation.=0A= =0A= ________________________________________=0A= From: Hadriel Kaplan [hadriel.kaplan@oracle.com]=0A= Sent: Thursday, July 18, 2013 7:02 PM=0A= To: Henning Schulzrinne=0A= Cc: stir@ietf.org List=0A= Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe)=0A= =0A= Yup, agreed - I was just responding to Brian's concern that using a DNS-bas= ed approach would require low TTL values, in order to support porting. It = doesn't require that.=0A= =0A= With regards to using certs: I don't think porting a number would require a= cert revocation, but the verifying systems would have to check revocations= , because private keys will get compromised ultimately.=0A= =0A= -hadriel=0A= =0A= =0A= On Jul 18, 2013, at 6:49 PM, Henning Schulzrinne wrote:=0A= =0A= > As long as you allow multiple public-private key pairs for one number (wh= ich we need for the legitimate spoofing cases anyway), porting isn't a big = deal. The likelihood that the entity that got their number ported away will= suddenly start spoofing that number seems pretty remote, particularly sinc= e it would be trivial to detect who did it. Thus, rapid key expiration does= not appear to be a major issue - nice to have, but we don't have to expire= every record every 10 minutes. The model we'd want is probably something a= bit different than typical: namely, if the cached cert/public key works, d= one. If there's a mismatch, a new holder may have been added and a query is= needed. This would only affect a very small fraction of calls for reasonab= le expiration times (days to a week).=0A= >=0A= > -----Original Message-----=0A= > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of H= adriel Kaplan=0A= > Sent: Wednesday, July 17, 2013 1:22 PM=0A= > To: Brian Rosen=0A= > Cc: stir@ietf.org List=0A= > Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe)=0A= >=0A= >=0A= > On Jul 17, 2013, at 10:58 AM, Brian Rosen wrote:=0A= >=0A= >> Small note:=0A= >> You would have to keep TTLs for at least U.S. zones under a few minutes = to allow the 15 minute port.=0A= >> I'd actually probably set it at a minute or two.=0A= >=0A= > I'm not sure if it really matters if the TTL is short, but it doesn't hav= e to be short - at least not with CIDER. The DNS name uses a "key index", = which identifies which specific public key was used for signing the call - = i.e., a single E.164 can have multiple public keys in DNS. (it's like a DKI= M "selector", but an integer instead of string) That key index value is se= nt in the SIP header. It then becomes part of the generated DNS name used = for the lookup. So when a key changes, the DNS full name changes, and ther= e's no cache collision.=0A= >=0A= > You have to do something like that no matter what solution we end up with= (even HTTP), because the carriers have to be able to change their key when= ever they want without affecting in-flight call requests, and give time for= the new key to propagate to the local copies carriers might have of the wh= ole DB. Plus it lets two or more agents claim the same phone number, for e= xample the outsourced call-center or medical doctor scenarios.=0A= >=0A= >=0A= > _______________________________________________=0A= > stir mailing list=0A= > stir@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/stir=0A= =0A= From hadriel.kaplan@oracle.com Fri Jul 19 10:29: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 EBE8611E815E for ; Fri, 19 Jul 2013 10:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.337 X-Spam-Level: X-Spam-Status: No, score=-6.337 tagged_above=-999 required=5 tests=[AWL=-0.053, 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 7CiNHDVuZS8O for ; Fri, 19 Jul 2013 10:29:34 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 623CE11E8147 for ; Fri, 19 Jul 2013 10:29:09 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6JHT6c8003243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 19 Jul 2013 17:29:07 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 r6JHT5YQ025865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 17:29:06 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 r6JHT58O006937; Fri, 19 Jul 2013 17:29:05 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 19 Jul 2013 10:29: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: Date: Fri, 19 Jul 2013 13:29:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <825EFE8B-555B-47EC-AF5D-55755C2439D5@oracle.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! ! ! ! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> <84432CF7-A220-46F0-B945-F41F09F7061E@oracle.com> , <1E1AA91D-F3C8-4B43-A647-F898B9AB9778@oracle.com> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "stir@ietf.org List" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:29:44 -0000 On Jul 19, 2013, at 11:57 AM, Henning Schulzrinne = wrote: > Since both revocations and ports are relatively rare and the number of = validators is relatively small (thousands, not millions), I suspect that = a pub-sub approach may well be better suited than querying the origin = server or DNS authoritative server for each validation. You don't have to query the DNS authoritative server for each = validation. One of the benefits of DNS is it cleans itself up, and the = threat model for bogus DNS injections for a STIR use-case is really = really small. More importantly, using CIDER with DNSSEC there would be = far fewer root-signing private-key holders to be compromised, and if = they get compromised they don't need to issue new E.164 certs to = everyone they had previously signed certs for, and they can actually set = their signature validity times really short because of that (i.e., they = can re-sign frequently). That means there's no actual need for = certificate revocation, no need for CRLs/OCSP, and the thing actually = *scales*. I appreciate that it's useful if we focus on how to solve the problem = for just one or a couple countries, but deploying whatever STIR ends up = being is going to be a massive undertaking. It may not be much work for = us in the IETF to define in specs, and for 3GPP and others to adopt in = specs... but the work required to evangelize/educate, implement, test, = deploy, troubleshoot, and manage from an ops perspective is going to be = A BIG DEAL. So whatever the STIR thing is, it must be able to scale and be truly = usable on a world-wide international basis. Because other countries = will eventually adopt it and we will want to validate incoming = international calls. International calls already pose problems today, = and for all the work and time STIR will take it would be insane not to = provide a tool which can work internationally. So I think we really do have to consider things from that perspective, = to make sure whatever we do would be usable as well internationally in = the future. I agree that porting isn't a reason to revoke certs. But private key = compromise would be. Private keys are compromised in the real world, = and it's not hard to imagine some carrier somewhere having its E164 cert = keys be compromised by a rogue employee or remote hacker or whatever. = In the worst-case, the largest mobile service provider in the world has = ~700 Million phone subscribers, and it's growing. Hopefully they = wouldn't store all their private keys/certs in any one server anywhere, = but it's not hard to imagine that we could still be talking about tens = of millions of certs needing to be revoked at some point in the future. If STIR uses certs for E.164 numbers, we will have to actually implement = revocation, even just in the US. I simply don't believe we could get = away with not revoking them, if a carrier's keys were compromised and = published on the web, and they included E.164 numbers for Citibank, = Fidelity, American Airlines, etc. It doesn't matter if it causes real = fraud or not - the perception/marketing problem alone would be too = damning. Regardless of the solution we end up with, we have to have some = reasonably believable story for how private keys could be changed and = revoked in a reasonable timeframe, for the various key holders, on a = world-wide basis. -hadriel From hadriel.kaplan@oracle.com Fri Jul 19 10:39: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 09E2F21E80C7 for ; Fri, 19 Jul 2013 10:39:47 -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 mVQFBoyyg5em for ; Fri, 19 Jul 2013 10:39:40 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7E321F8415 for ; Fri, 19 Jul 2013 10:39:40 -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 r6JHddXt020394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 19 Jul 2013 17:39:39 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 r6JHdc3G000153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 19 Jul 2013 17:39:38 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 r6JHdbMU016898 for ; Fri, 19 Jul 2013 17:39:38 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 19 Jul 2013 10:39:37 -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: <27E962B1-B56B-4F59-8175-8EB223DCFD0A@oracle.com> Date: Fri, 19 Jul 2013 13:39:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01ed01ce8439$7d09f550$771ddff0$@shockey.us> <76055977-247C-42D1-8E4F-2C4EB8A5278C@gmail.com> <27E962B1-B56B-4F59-8175-8EB223DCFD0A@oracle.com> To: "stir@ietf.org List" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: Re: [stir] In case you had the slightest doubt of the problem we are trying to solve X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jul 2013 17:39:47 -0000 On Jul 19, 2013, at 10:17 AM, Hadriel Kaplan = wrote: > The good news is if we get STIR deployed it will at least be easier to = track down the culprits, and it may even help prevent some specific = forms of PBX hacks (maybe). But STIR is not a silver bullet to prevent = DoS attacks, and won't overcome the issues with people deploying stuff = in an insecure manner - like, for example not changing the default PBX = password/pin for administration, or not deploying a firewall or SBC = correctly. Only education can help with that. BTW, when I said "it may even help prevent some specific forms of PBX = hacks (maybe)", I didn't mean STIR alone would do it. I just meant = since some forms of PBX hacks are performed by calling the PBX and = pressing specific digits for a PIN, then if we had STIR, we'd at least = be able to track back what the hacker's calling number was when that was = done. I.e., the PBX itself might keep the logs, but even if it doesn't = the service provider will have call detail records. So if you know the = PBX got hacked in the past few hours or day, you can look at who called = the PBX in that time and narrow it down. (this is of course assuming everyone uses STIR, and the PBX doesn't = allow administration for anonymous calls, etc.) -hadriel From michael.hammer@yaanatech.com Fri Jul 19 10:48: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 6E30111E8142 for ; Fri, 19 Jul 2013 10:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.378 X-Spam-Level: X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=-0.094, 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 xo042V6z9WcY for ; Fri, 19 Jul 2013 10:48:20 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 96FF211E80E3 for ; Fri, 19 Jul 2013 10:48:20 -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, 19 Jul 2013 10:48:20 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" , "Henning.Schulzrinne@fcc.gov" Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) Thread-Index: AQHOgvzGoW2Sqvrxc0GEvdoogk5ro5lpa5QAgAAoCgCAAe3VAIAAA5sAgAEbyACAABl1gP//jBDQ Date: Fri, 19 Jul 2013 17:48:18 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC19C60@EX2K10MB1.corp.yaanatech.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! ! ! ! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> <84432CF7-A220-46F0-B945-F41F09F7061E@oracle.com> , <1E1AA91D-F3C8-4B43-A647-F898B9AB9778@oracle.com> <825EFE8B-555B-47EC-AF5D-55755C2439D5@oracle.com> In-Reply-To: <825EFE8B-555B-47EC-AF5D-55755C2439D5@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.110] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_03B3_01CE8486.9F955090" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:48:31 -0000 ------=_NextPart_000_03B3_01CE8486.9F955090 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Both solutions have the characteristics that you outline. If the carrier credentials get compromised, then likely all the public keys in the DNS associated with that carrier are also compromised and hence must be updated, since you don't know what might have been "planted" or not. That could also mean getting new public/private key pairs for every customer that had a public key in the DNS for that carrier. The same liability issues exist. To do this analysis you need to ask how often would the carrier credentials be compromised? Any data to quantify that? You also make assumptions that the carrier has only one set of credentials. If the carrier uses multiple, then divide by that number to get a newer exposure number. Also, those credentials can be rotated and aged out by time. Thus, a compromise would mean restoring the associated DNS entries, or credentials affected by that time frame. Weak strawmen don't help the comparison and discussion. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Friday, July 19, 2013 1:29 PM To: Henning Schulzrinne Cc: stir@ietf.org List Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) On Jul 19, 2013, at 11:57 AM, Henning Schulzrinne wrote: > Since both revocations and ports are relatively rare and the number of validators is relatively small (thousands, not millions), I suspect that a pub-sub approach may well be better suited than querying the origin server or DNS authoritative server for each validation. You don't have to query the DNS authoritative server for each validation. One of the benefits of DNS is it cleans itself up, and the threat model for bogus DNS injections for a STIR use-case is really really small. More importantly, using CIDER with DNSSEC there would be far fewer root-signing private-key holders to be compromised, and if they get compromised they don't need to issue new E.164 certs to everyone they had previously signed certs for, and they can actually set their signature validity times really short because of that (i.e., they can re-sign frequently). That means there's no actual need for certificate revocation, no need for CRLs/OCSP, and the thing actually *scales*. I appreciate that it's useful if we focus on how to solve the problem for just one or a couple countries, but deploying whatever STIR ends up being is going to be a massive undertaking. It may not be much work for us in the IETF to define in specs, and for 3GPP and others to adopt in specs... but the work required to evangelize/educate, implement, test, deploy, troubleshoot, and manage from an ops perspective is going to be A BIG DEAL. So whatever the STIR thing is, it must be able to scale and be truly usable on a world-wide international basis. Because other countries will eventually adopt it and we will want to validate incoming international calls. International calls already pose problems today, and for all the work and time STIR will take it would be insane not to provide a tool which can work internationally. So I think we really do have to consider things from that perspective, to make sure whatever we do would be usable as well internationally in the future. I agree that porting isn't a reason to revoke certs. But private key compromise would be. Private keys are compromised in the real world, and it's not hard to imagine some carrier somewhere having its E164 cert keys be compromised by a rogue employee or remote hacker or whatever. In the worst-case, the largest mobile service provider in the world has ~700 Million phone subscribers, and it's growing. Hopefully they wouldn't store all their private keys/certs in any one server anywhere, but it's not hard to imagine that we could still be talking about tens of millions of certs needing to be revoked at some point in the future. If STIR uses certs for E.164 numbers, we will have to actually implement revocation, even just in the US. I simply don't believe we could get away with not revoking them, if a carrier's keys were compromised and published on the web, and they included E.164 numbers for Citibank, Fidelity, American Airlines, etc. It doesn't matter if it causes real fraud or not - the perception/marketing problem alone would be too damning. Regardless of the solution we end up with, we have to have some reasonably believable story for how private keys could be changed and revoked in a reasonable timeframe, for the various key holders, on a world-wide basis. -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_03B3_01CE8486.9F955090 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx OTE3NDgxN1owIwYJKoZIhvcNAQkEMRYEFJjrb4IHVRwweCktZz9Yb3ma4iADMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAeA3rHuH/1Nv0BkxWk3BmxumpEhtDaKANF8G74ai2 AINhNmkNIH/2u2B9enOZXyEHxOTkO+eRdLqyNQ8mhe6DBDH5HEbJNgP7xMhZELKWX7jjAw3pSRly 5E3fLvWIXq91l0B1iZ/ckU61lNl2K5ZWB/+jaEt+ikEfueT8rMpGE61vKdDp3VRx7Iha5rbrFQO+ XaDvPs2MvOb/mSj7rdjH0LOas/z/UmoFSF9rjnrrARTIOn4OqknPGpXbwyx/ZMNtTQEMFeYqWDKE ulcdYLbrZAR/1KfqkeUCKZ5FFLKkb8/JhtE3EkESt5KhSTB6r+dx3HHFF4bXPQDdcqWNBJKhswAA AAAAAA== ------=_NextPart_000_03B3_01CE8486.9F955090-- From hadriel.kaplan@oracle.com Fri Jul 19 11: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 CCC3A11E8145 for ; Fri, 19 Jul 2013 11:47:28 -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 qoGHfFgXW8DP for ; Fri, 19 Jul 2013 11:47:22 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 44C2211E816E for ; Fri, 19 Jul 2013 11:47:22 -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 r6JIlKAZ016672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 19 Jul 2013 18:47:21 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 r6JIlJmB021749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 18:47:19 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6JIlIGJ001787; Fri, 19 Jul 2013 18:47:18 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 19 Jul 2013 11:47: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: <00C069FD01E0324C9FFCADF539701DB3BBC19C60@EX2K10MB1.corp.yaanatech.com> Date: Fri, 19 Jul 2013 14:47:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! ! ! ! ! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> <84432CF7-A220-46F0-B945-F41F09F7061E@oracle.com> , <1E1AA91D-F3C8-4B43-A647-F898B9AB9778@oracle.com> <825EFE8B-555B-47EC-AF5D-55755C2439D5@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC19C60@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 List" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 18:47:28 -0000 On Jul 19, 2013, at 1:48 PM, Michael Hammer = wrote: > Both solutions have the characteristics that you outline. Nope. I really think you need to read the CIDER draft, and read how = DNSSEC works, and think about it from the perspective of STIR usage. Or = better-yet wait until we get some face-time and powerpoint time to let = me explain the CIDER concept. I know email is a lousy way to = communicate some of these things. :( > If the carrier credentials get compromised, then likely all the public = keys > in the DNS associated with that carrier are also compromised and hence = must > be updated, since you don't know what might have been "planted" or = not. Of course. The private/public key pairs for the E.164 entries need to = be changed, if they're compromised. That's true regardless of whether = they're entries in a DNS or certs. So imagine that happening. With CIDER, the carrier communicates with = the Registry to change its pub-keys. That could happen through a = protocol (the CIDER draft proposes requirements for such a protocol), or = via email or whatever. That part has to happen regardless of DNS = entries or certs. With CIDER, however, there's no need to respond with = new certs, and more importantly the old entries don't need to be = revoked. The old ones will time out, very quickly. It's impractical to = have short expiry for certs. Or by "credentials get compromised" do you mean the credentials used by = the carrier to access its entries in the Registry? That's still the = same problem for both, with a similar result. > That could also mean getting new public/private key pairs for every = customer > that had a public key in the DNS for that carrier. Yes, that could happen for any/either solution. Again, in one solution = it requires revocation - in the other it doesn't. The "revocation" is = implicit. > To do this analysis you need to ask how often would the carrier = credentials > be compromised? Any data to quantify that? I don't understand why that matters. If we're using certs and it = happens once, to a large carrier, hilarity ensues. > You also make assumptions that the carrier has only one set of = credentials. Which "credentials" are you referring to? (sorry, we keep using that = word for different things in this mailing list, so I'm not sure which = ones you mean) > Weak strawmen don't help the comparison and discussion. On the contrary - the CIDER proposal is written down in a draft, for all = to see and read and argue over... and its essentially based on a DKIM = model. I have yet to see a draft that actually describes how a = certificate-based model would actually work, be deployed, scale, and = handle things for E.164. Instead, there appear to be at least two = different proposals for how certificates could be used, across various = emails, with no concrete proposal to compare CIDER against. Which one = of these is the "strawman" exactly? It's very easy to argue against a concrete proposal, when any = counter-proposal is undefined.=20 -hadriel From michael.hammer@yaanatech.com Fri Jul 19 14:33: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 CF21211E8199 for ; Fri, 19 Jul 2013 14:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 RJ3b4uk-uzLn for ; Fri, 19 Jul 2013 14:33:21 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id C10F811E8138 for ; Fri, 19 Jul 2013 14:33:21 -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, 19 Jul 2013 14:33:19 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) Thread-Index: AQHOgvzGoW2Sqvrxc0GEvdoogk5ro5lpa5QAgAAoCgCAAe3VAIAAA5sAgAEbyACAABl1gP//jBDQgACJywD//6q3gA== Date: Fri, 19 Jul 2013 21:33:17 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC19DAC@EX2K10MB1.corp.yaanatech.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! ! ! ! ! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> <84432CF7-A220-46F0-B945-F41F09F7061E@oracle.com> , <1E1AA91D-F3C8-4B43-A647-F898B9AB9778@oracle.com> <825EFE8B-555B-47EC-AF5D-55755C2439D5@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC19C60@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.110] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_042B_01CE84A6.0DA55660" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 21:33:27 -0000 ------=_NextPart_000_042B_01CE84A6.0DA55660 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Inline... -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Friday, July 19, 2013 2:47 PM To: Michael Hammer Cc: stir@ietf.org List Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) On Jul 19, 2013, at 1:48 PM, Michael Hammer wrote: > Both solutions have the characteristics that you outline. Nope. I really think you need to read the CIDER draft, and read how DNSSEC works, and think about it from the perspective of STIR usage. Or better-yet wait until we get some face-time and powerpoint time to let me explain the CIDER concept. I know email is a lousy way to communicate some of these things. :( >> I read your CIDER draft, but am trying to draw out the salient points on where the chain of trust lies and what is really different. Maybe I am missing some key point about what is securing the DNS entry and what is in that entry that needs to be secured and how that relates to the key used to sign the SIP header element. > If the carrier credentials get compromised, then likely all the public > keys in the DNS associated with that carrier are also compromised and > hence must be updated, since you don't know what might have been "planted" or not. Of course. The private/public key pairs for the E.164 entries need to be changed, if they're compromised. That's true regardless of whether they're entries in a DNS or certs. So imagine that happening. With CIDER, the carrier communicates with the Registry to change its pub-keys. That could happen through a protocol (the CIDER draft proposes requirements for such a protocol), or via email or whatever. That part has to happen regardless of DNS entries or certs. With CIDER, however, there's no need to respond with new certs, and more importantly the old entries don't need to be revoked. The old ones will time out, very quickly. It's impractical to have short expiry for certs. >> Maybe you could elaborate more here. The carrier has a public keys used to sign submissions of public key values associated with private keys used by the number holder to sign the number field in the SIP invite. If that carrier private key was compromised, then all the related DNS entries are also thrown into question. So, just updating the carrier public key in the DNS doesn't fix the question of validity of the number-holder data in DNS which could be bogus. So, how do you say that the old entries don't need to be revoked. >> OK, so if they time out you have to generate new public-private key pairs for each number holder, and update both the DNS and the end-user with those values, no? Or by "credentials get compromised" do you mean the credentials used by the carrier to access its entries in the Registry? That's still the same problem for both, with a similar result. >> Yes. > That could also mean getting new public/private key pairs for every > customer that had a public key in the DNS for that carrier. Yes, that could happen for any/either solution. Again, in one solution it requires revocation - in the other it doesn't. The "revocation" is implicit. >> Revocation is revocation. The question is whether there is any difference in how long it takes to get number-holder and the validation point updated. In one case, the new key binding is wrapped in a cert and signed and the CRL list updated. In the other, the key binding is wrapped in a secure DNS setting. Caches of DNS entries or cert DB can then be updated in timely fashion as you mention. > To do this analysis you need to ask how often would the carrier > credentials be compromised? Any data to quantify that? I don't understand why that matters. If we're using certs and it happens once, to a large carrier, hilarity ensues. >> Likewise, once the key securing DNS is compromised, ditto. Note that "large" is related to the number of entries signed, so with smart planning, all "carriers" are small. > You also make assumptions that the carrier has only one set of credentials. Which "credentials" are you referring to? (sorry, we keep using that word for different things in this mailing list, so I'm not sure which ones you mean) >> I was trying to follow your argument about the scope of someone's credentials being compromised. You tell me. > Weak strawmen don't help the comparison and discussion. On the contrary - the CIDER proposal is written down in a draft, for all to see and read and argue over... and its essentially based on a DKIM model. I have yet to see a draft that actually describes how a certificate-based model would actually work, be deployed, scale, and handle things for E.164. Instead, there appear to be at least two different proposals for how certificates could be used, across various emails, with no concrete proposal to compare CIDER against. Which one of these is the "strawman" exactly? It's very easy to argue against a concrete proposal, when any counter-proposal is undefined. >> You missed the point about what is a strawman. My point was that you were making assertions about how the cert model would work, then attacking your portrayal of that model. I wasn't referring to your CIDER approach as a strawman. >> As for having a draft of not, it is obvious that you had been working on this prior to the STIR mail list being formed. So, dumping a fait accompli on the group and suggesting that being first to get a draft out is reason not to consider other possibilities prior to the WG even being formed just doesn't seem very sporting of you. I had hoped that responding to your questions across the various emails had helped clarify some ideas versus confuse you. I guess "concrete" is in the eye of the beholder. -hadriel ------=_NextPart_000_042B_01CE84A6.0DA55660 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx OTIxMzMxNlowIwYJKoZIhvcNAQkEMRYEFAu9gBmh+YMDbBizqNGWWiJHCjRqMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAW8CeuzsA5UtZNWpSpK1FHsImnD+wrlCd0xigvgXw xbQlSzcFe/fYqA3k5ucDlMu1c5iTTtFesu127F9h3smFnCS8avzOIMO8ee7S6iP0esfOVf7TYA2w 3HbeML0kwa/uQHpKYnLkA+DEfvZkUQ6q639orj1gGM6SY/ByhFM/xM22v1HiQul92CZgOwDYiwup W8I3tpB/H27h4JfChrr9TMBKqeEQmtGLUwHsGvq8zWAVS0mh/V+BlQYqb23sMFymqTusTBywW2Uo munVuVJvCeZdYb5mxnJ7TI/RyS/T/9ehT1AXZIqYUCe9uP+2jAlMMucJN6M+fBYTvQD73zdWugAA AAAAAA== ------=_NextPart_000_042B_01CE84A6.0DA55660-- From hadriel.kaplan@oracle.com Fri Jul 19 15: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 6D37221E80B4 for ; Fri, 19 Jul 2013 15:15:56 -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 GX5cF+vEl6SW for ; Fri, 19 Jul 2013 15:15:49 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id DC26C21E8091 for ; Fri, 19 Jul 2013 15:15:49 -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 r6JMFm9e028092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 19 Jul 2013 22:15:49 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 r6JMFltP017167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 22:15:47 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 r6JMFkMf021116; Fri, 19 Jul 2013 22:15:46 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 19 Jul 2013 15:15: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: <00C069FD01E0324C9FFCADF539701DB3BBC19DAC@EX2K10MB1.corp.yaanatech.com> Date: Fri, 19 Jul 2013 18:15:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <25F15A58-80AB-442B-8121-F5144890C829@oracle.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! ! ! ! ! ! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> <84432CF7-A220-46F0-B945-F41F09F7061E@oracle.com> , <1E1AA91D-F3C8-4B43-A647-F898B9AB9778@oracle.com> <825EFE8B-555B-47EC-AF5D-55755C2439D5@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC19C60@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC19DAC@EX2K10MB1.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" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 22:15:56 -0000 I'll respond to the other points separately tonight when I have more = time, but this one is different so I'll just respond quick.. On Jul 19, 2013, at 5:33 PM, Michael Hammer = wrote: >>> As for having a draft of not, it is obvious that you had been = working on > this prior to the STIR mail list being formed. =20 Actually, I wasn't working on it at all before STIR was formed, nor even = when STIR was formed. Some of us had discussed at a very high level, = several years ago, about using DNS/ENUM for caller-id verification. = This was back when we were debating rfc4474's uselessness and trying to = fix it. But it never got into the details or more than just a few = sentences in email on one of the SIP-related mailing lists, at least as = far as I can recall or was involved in. Even at the STIR kickoff meeting in Wash DC a couple months ago, we had = jokingly mentioned it in the meeting, but I had mentally dismissed it as = untenable due to privacy concerns. It was only about a month ago during = the discussions on this list that I realized (or someone else pointed = out) that (1) the contents of the DNS entries don't need to reveal = anything private other than a public key value, and (2) that since we do = use ENUM today in a private-access manner, we could still do that if it = turned out we wanted to keep the databases private in the end. So I wrote up the draft in spurts over the past couple weeks, and only = really got it done the day before submission was due.=20 :) > So, dumping a fait accompli > on the group and suggesting that being first to get a draft out is = reason > not to consider other possibilities prior to the WG even being formed = just > doesn't seem very sporting of you. =20 If anything, it is the opposite situation: the running assumption when = the STIR list was created was we'd be using X.509 certs and HTTP, with = some tweak of RFC 4474. There are also several people on the list who = have allergic reactions to the word "DNS". Trust me, what I'm proposing is NOT a fait accompli, and I'm not = claiming it should be. I'm not at all claiming because I got a draft = submitted that somehow its superior. I'm just saying we can't really = argue much in detail until we see what the alternatives are. We will = really need to spend a long time in meetings going over any proposed = solutions, and chew on them for a while. > I had hoped that responding to your > questions across the various emails had helped clarify some ideas = versus > confuse you. I guess "concrete" is in the eye of the beholder. I appreciate the emails - I'm just having a hard time understanding and = keeping track of the various proposals - there's not just one cert-based = or even HTTP-based proposal. So without having something written down, = it's hard to know what the alternatives are. :) -hadriel From dhc@dcrocker.net Fri Jul 19 16:23: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 26D4221E80CC for ; Fri, 19 Jul 2013 16:23:05 -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 1+fO8U5Cu8JK for ; Fri, 19 Jul 2013 16:23:00 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4E421E80C0 for ; Fri, 19 Jul 2013 16:23:00 -0700 (PDT) Received: from [192.168.197.131] ([67.159.191.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r6JNMtgN024659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Jul 2013 16:22:58 -0700 Message-ID: <51E9C96F.4@dcrocker.net> Date: Fri, 19 Jul 2013 16:19:11 -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: Henning Schulzrinne References: <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! ! ! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> <84432CF7-A220-46F0-B945-F41F09F7061E@oracle.com> , <1E1AA91D-F3C8-4B43-A647-F898B9AB9778@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 19 Jul 2013 16:22:58 -0700 (PDT) Cc: "stir@ietf.org List" Subject: Re: [stir] CA Certs 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, 19 Jul 2013 23:23:05 -0000 On 7/19/2013 8:57 AM, Henning Schulzrinne wrote: > Since both revocations and ports are relatively rare and the number of validators is relatively small (thousands, not millions), Henning, I thought that the operational goal was to permit validation by enterprises and even end-user-systems, and, I guess, even permit /signing/ by such systems. That's not a small total number and the combinatorials -- every pair that might do a SIP call is not a small working set. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From fluffy@cisco.com Fri Jul 19 17:12: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 41A1421E8056 for ; Fri, 19 Jul 2013 17:12:29 -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 T+pd6CDN2DFx for ; Fri, 19 Jul 2013 17:12:23 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0D46721E804C for ; Fri, 19 Jul 2013 17:12:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1232; q=dns/txt; s=iport; t=1374279143; x=1375488743; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XKlV9VxvNbam4oDwSZFOc4RkZO7vFkG0hW/g9aj66JI=; b=LhuSnOz5QBu/jrOtKnhrpn8gyEZWrTrOCfkIAM8nL7d5M0fPw3HSabMt H6jeRzhERA7+CndpZWZAu/KBtUz1c6t8R7Nia+6glLDCHXy6hTsGT3ois G8T61gO/FKQTCRRDzA5x7MMxe5MqaFtQI14QRtX3JLcj9pZ3C1Q3wWEdQ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAPbU6VGtJXG+/2dsb2JhbABRCYMGgQXAS4ERFnSCJAEBAQMBOj8FCwIBCA4UFBAyJQIEDgUIiAIGt1OOVIEIAjEHgxBuA6kqgxKCKg X-IronPort-AV: E=Sophos;i="4.89,705,1367971200"; d="scan'208";a="237157834" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 20 Jul 2013 00:12:22 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6K0CMma028742 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 20 Jul 2013 00:12:22 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Fri, 19 Jul 2013 19:12:21 -0500 From: "Cullen Jennings (fluffy)" To: Brian Rosen Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) - attack model Thread-Index: AQHOhN3Nyd1pmvzigUSCJoYNTaEAaA== Date: Sat, 20 Jul 2013 00:12:21 +0000 Message-ID: References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.91.75] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Hadriel Kaplan , Michael Hammer Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jul 2013 00:12:29 -0000 On Jul 17, 2013, at 7:58 AM, Brian Rosen wrote: > Small note: >=20 > You would have to keep TTLs for at least U.S. zones under a few minutes t= o allow the 15 minute port. >=20 > I'd actually probably set it at a minute or two. Originally I was thinking this way but I slowly came to think this may not = be the case depending on you attack model.=20 Lets say my number was with Verizon then I move it to Sprint. Sure the port= s needs to happen fast but how fast does Verizon need to loose the ability = to impersonate me? That might not have to happen as fast - for example, if = Verizon could continue signing records on my behalf for another 30 days aft= er the port, would that really matter? Sure people have to recognize the ne= w signatures from Sprint very quickly ( like minutes ), but I'm not sure th= e old entities need to loose my trust right away.=20 This is more a question about the attack model and what the requirement is = for how quickly someone that used to be able to assert my identity looses t= hat ability. Perhaps the time is the same as the port time but it seem wort= h thinking about what a model would look like where that time was much high= er.=20 From fluffy@cisco.com Fri Jul 19 17:12: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 B077421E80D8 for ; Fri, 19 Jul 2013 17:12:35 -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 CEViTE3usJzZ for ; Fri, 19 Jul 2013 17:12:29 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id D908C21E8095 for ; Fri, 19 Jul 2013 17:12:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1134; q=dns/txt; s=iport; t=1374279144; x=1375488744; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=X7nzzn8GOTA+UMeuKtj/qZn5xD4o61JDCR3C70sHoaU=; b=DXYW4Q8U6RGarC4n5WWmXeGTopPUbGzVvWIojemt+32bAjzIcRZbbOan sIaT4bnn4vDePqGOXiDjF8O+RM3DG57ewQT7WMYPc8OqAtXxLOV71SwVO H7qwOPMTcQBS3odZMrz1loJP0Uju4FrftPx23EeGIxhUCzm6FsBB/RLQY 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAHnU6VGtJXG+/2dsb2JhbABagwY1UMBLgREWdIIkAQEBAwE6OgUFCwIBCBgKFBAyJQIEDgUIE4dvBrdTj1wCMQeDEG4DqSqDEoFqJBw X-IronPort-AV: E=Sophos;i="4.89,705,1367971200"; d="scan'208";a="236978241" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 20 Jul 2013 00:12:23 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6K0CNHX028790 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 20 Jul 2013 00:12:23 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Fri, 19 Jul 2013 19:12:23 -0500 From: "Cullen Jennings (fluffy)" To: "" Thread-Topic: [stir] response-time window ( was Re: Out-of-band vs. in-band Thread-Index: AQHOeEeD9o9eez0vlkuAOm6Gu/rxipls44WA Date: Sat, 20 Jul 2013 00:12:23 +0000 Message-ID: References: <011501ce7676$79b756c0$6d260440$@shockey.us> <01bc01ce7691$e73f8bc0$b5bea340$@shockey.us> <51D1DC32.1080308@dcrocker.net> <520DE022-7E21-4B31-82E1-D332A2A94E63@oracle.com> <2B0F677F0B95454297753F58D4A07FA30127F61718@FHDP1LUMXC7V31.us.one.verizon.com> <51D4B768.5090503@dcrocker.net> In-Reply-To: <51D4B768.5090503@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.91.75] 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] response-time window ( was Re: 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, 20 Jul 2013 00:12:36 -0000 On Jul 3, 2013, at 4:44 PM, Dave Crocker wrote: > On 7/2/2013 10:57 AM, Henning Schulzrinne wrote: >> Vaguely related: On the government side, we make numerous entity-related= items available to the public via HTTP APIs >=20 >=20 > HTTP-based queries require a tcp open, at least one http exchange, and a = tcp close. I never get the count right, but that's somewhere around 5-7 ro= und-trip times. Since the current requirement is for queries from anywhere= on the net to anywhere on the net, these aggregate round-trip latencies ca= n be significant. Measured in seconds. sort of a tangent but we are seeing solutions coming out for HTTPS transact= ions that work in one round trip (never mind the are called zero round trip= :-) >=20 > My understanding is that verification needs to be performed within the fi= nal stages of call set up. I assume that's a window of less than a second,= and presumably quite a bit less. >=20 > One of the functional requirements that would be helpful to specify is th= e performance window that must be met by the validation mechanism. >=20 From fluffy@cisco.com Fri Jul 19 17:12: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 8D61B21E80DF for ; Fri, 19 Jul 2013 17:12:40 -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 Mkoy+76Pu4Ze for ; Fri, 19 Jul 2013 17:12:33 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 18C3C21E80BA for ; Fri, 19 Jul 2013 17:12:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1331; q=dns/txt; s=iport; t=1374279145; x=1375488745; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cFrtXGh8MRzPr80N2+d3tFocHtxIphL13/kaRe915eQ=; b=WjJcIwhxyW97Q+l6H6FCos3Y7tjF9iTKW46Z95XLiOIB7sJg9D94OGdY /H+dVX8zfMupf3SqsY694MZz1KejjuzsDlOiZ7IY1ra0KC+E3DCJ6cp2Y fqpwGEr4s3VEnjdZYSGPKdSNLHX5QpEAOIJfQ/1soqmgyYZcYHEhdRPLN 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAG7V6VGtJV2Y/2dsb2JhbABagwaBBcBLgREWdIIlAQEEOj8QAgEIIhQQMiUCBA4FCIgIt1SOTQqBBQIxB4MQbgOpKoMSgWgJFyI X-IronPort-AV: E=Sophos;i="4.89,705,1367971200"; d="scan'208";a="237254703" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 20 Jul 2013 00:12:24 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6K0COOt022313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 20 Jul 2013 00:12:24 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Fri, 19 Jul 2013 19:12:24 -0500 From: "Cullen Jennings (fluffy)" To: Hadriel Kaplan Thread-Topic: [stir] Out-of-bound STIR (was: Re: Draft STIR Charter) Thread-Index: AQHOgZ5BHGbMDEgnsE6dB0AkE+0T1JlmqPGAgAD1kICABTLuAA== Date: Sat, 20 Jul 2013 00:12:23 +0000 Message-ID: References: <08F1C268-8FBF-4520-84EF-5B325D085119@oracle.com> In-Reply-To: <08F1C268-8FBF-4520-84EF-5B325D085119@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.91.75] Content-Type: text/plain; charset="us-ascii" Content-ID: <3665A30FFC838B48BE15DF4D88617C0C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF STIR Mail List , "Peterson, Jon" Subject: Re: [stir] Out-of-bound STIR (was: Re: Draft STIR Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jul 2013 00:12:40 -0000 On Jul 16, 2013, at 6:18 AM, Hadriel Kaplan wro= te: >>=20 >> Perhaps more materially, the scope of out-of-band isn't limited to smart >> phones. It includes things like IP PBX makers. At least one IP PBX maker >> has previously come to the IETF with an interest in working on an >> out-of-band mechanism here. >=20 > I would like to talk to them.=20 >From a Cisco point of view, I'm glad to arrange a call with anyone that the= STIR group might want to talk to at Cisco to collect information about PBX= s. (We are #1 market share in this space and I imagine the other large vend= ors might answer any questions folks have too). I imagine that most people = at Cisco will point out that ultimately, I will end up being the main perso= n that needs to decide what Cisco will do here but if anyone would prefer a= n email from the CTO or something, glad to arrange that too.=20 The Cisco Unified Communication Groups is very clear that we would like to = see the industry solve the robo calling problem if at all possible. We are = concerned that the problem will get worse if we don't do something. Note my emails to this list normally represent my opinion but since there w= as a request around the PBX vendors, I thought I would make this offer from= Cisco.=20 =20 From fluffy@cisco.com Fri Jul 19 17:12: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 1956621E80FC for ; Fri, 19 Jul 2013 17:12:44 -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 tS1pYGJNV0IF for ; Fri, 19 Jul 2013 17:12:36 -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 6FF5921E80C9 for ; Fri, 19 Jul 2013 17:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1047; q=dns/txt; s=iport; t=1374279146; x=1375488746; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HGN+8oKCLBay8VDNZGBV2axm84ZpE4DhCf3ybtqR7jQ=; b=HBmhZGpOJuEG3LO5T1qN+1Bppde/IihChtvJr23DGlfdrfUHOMKT+nks 0wGUK64Q3yVlH6fcFV6Fd7XrcwLhKB7pTcjNm5JFGHhprsXgdMwwDkYmp hxwAVrOk3hloxSyitK8n1ILBSfsMxU9HTR2SpTTK0NmZREDFbWBLs+2+N s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAHnU6VGtJXG9/2dsb2JhbABagwaBBcBLgREWdIIkAQEBAwE6PwULAgEIIhQQMiUCBA4FCIgCBrdTj1wCMQeDEG4DqSqDEoIq X-IronPort-AV: E=Sophos;i="4.89,705,1367971200"; d="scan'208";a="237146485" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 20 Jul 2013 00:12:26 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6K0CPkh020955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 20 Jul 2013 00:12:25 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Fri, 19 Jul 2013 19:12:24 -0500 From: "Cullen Jennings (fluffy)" To: Russ Housley Thread-Topic: [stir] Draft STIR Charter - Privacy Thread-Index: AQHOhN3PcAIxOxoR50yqZNGl2UuG3Q== Date: Sat, 20 Jul 2013 00:12:24 +0000 Message-ID: References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> <457ED3A0-D8D1-4420-A2C3-5B07B16AE641@vigilsec.com> In-Reply-To: <457ED3A0-D8D1-4420-A2C3-5B07B16AE641@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.91.75] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF STIR Mail List Subject: Re: [stir] Draft STIR Charter - Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 00:12:44 -0000 The number one problem with VIPR is a privacy issue where one person can le= arn about if Alice is calling Bob. I want to make sure we are thinking ab= out the privacy issues form the start.=20 So consider the text from the charter of=20 On Jul 16, 2013, at 1:33 PM, Russ Housley wrote: > This working group will define a deployable > mechanism that verifies the authorization of the calling party to use > a particular telephone number. I think we need to add a bit more to the text above. I would suggest someth= ing along the lines of saying who can do this verification. I think it nee= ds to be some network device or endpoint authorized by the called party. Pe= rhaps there is some other way to phrase the privacy issues.=20 To provide a very specific use case, I don't want EKR or some random transi= t provider to be be able to figure out if I am calling EKR's wife or not. I= f we fail to have this property, I don't believe this work will be deployed= - particularly in the EU.=20 From fluffy@cisco.com Fri Jul 19 17:12: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 7311021E80C0 for ; Fri, 19 Jul 2013 17:12:47 -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 602lSB64mHuB for ; Fri, 19 Jul 2013 17:12:40 -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 716F521E80CC for ; Fri, 19 Jul 2013 17:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8839; q=dns/txt; s=iport; t=1374279147; x=1375488747; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LQY+/2mSIqbpwjKr4rR7jo6EG1p9CsfdEqmN4AhQh2E=; b=O46GDyIQWoTCv5R4vR3IKfyAdcCldBbn11FD0h7CUihTbpS9EMQpj4Ir bSN9WvR0hwK1oMScxS63d5KNevScn650U7fMtI0KbKjL4AJiz3R/OqkcL 9o8WP0n3ScVjRm/Dl34YJSlAVOvdUcx7rGv30dDbRhfbROevd/RyQ6k9p A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAHnU6VGtJXG9/2dsb2JhbABRCYMGNVDAS4ERFnSCJAEBAQMBAQEBNy0HCwULAgEIIgISECcLJQIEDgUIE4dvBgy3R45NB4EIAjEHgxBuA5QGhQCQJIMSgWoHFwYc X-IronPort-AV: E=Sophos;i="4.89,705,1367971200"; d="scan'208";a="237194786" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 20 Jul 2013 00:12:26 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6K0CQaw020962 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 20 Jul 2013 00:12:26 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Fri, 19 Jul 2013 19:12:25 -0500 From: "Cullen Jennings (fluffy)" To: IETF STIR Mail List Thread-Topic: [stir] Draft STIR Charter - out of band Thread-Index: AQHOhN3PqXoTPOIuxkG+0J9PAbgZkQ== Date: Sat, 20 Jul 2013 00:12:24 +0000 Message-ID: References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> <457ED3A0-D8D1-4420-A2C3-5B07B16AE641@vigilsec.com> In-Reply-To: <457ED3A0-D8D1-4420-A2C3-5B07B16AE641@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.91.75] Content-Type: text/plain; charset="us-ascii" Content-ID: <9A002DD4A3073C42915850182DFC6711@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Russ Housley Subject: Re: [stir] Draft STIR Charter - 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, 20 Jul 2013 00:12:48 -0000 I'm listening to the arguments for in band or out of band but right now I a= m pretty skeptical that doing in-band before out-of-band is the right order= . I suspect we need them both. Let me say a bit more=20 Mobile phones could have done wideband audio long ago, but they did not. Th= ere was no incentive for them to do it since there was no alternative that = could do do wideband and had the same mobility properties. Then along came = smart phones and started providing much better audio quality using things l= ike Skype. Suddenly there was an incentive to do wideband audio on mobile p= hones and you are starting to see that deploy.=20 So lets talk about carrier to carrier SIP interconnects. Unless there is an= real incentive, I sort of doubt that they will initially do a lot more tha= n the SS7 interconnects they replace. No incentive and complicated to chang= e the business agreements in place. Particularly for interconnects between = say Nigeria and US.=20 However, there is a great incentive for smartphones to implement an out of = band solutions even it only works to other smartphones. Once that existed, = there would be an incentive for non smart phones to get an equivalent level= of service and that would most likely be done with a in band solution but = at that point there is an incentive to deploy in band.=20 A solution that only worked for smart phones is clearly not as useful as on= e that works for all phones, but doing both at the same time seems the most= likely way to me to get either of them to deploy.=20 Sure it would be better for the non over the top service providers if there= was only a solution that worked for the carrier a telephone numbers was de= legated down to form a nation level, but as apple showed with iMessage, it = can be better for the users to have two ways to send a SMS messages to anot= her user. One way that goes thought the provider that the phone number was = delegated to, and one way that goes around the the carrier the phone number= was delegated to.=20 So, I'd like to see the charter changed to work on both in-band and out-of-= band at the same time.=20 On Jul 16, 2013, at 1:33 PM, Russ Housley wrote: > I have tried to pull all of the discussion into an updated charter. I ha= ve also attached a diff to make it easier to review. >=20 > Russ >=20 >=20 >=20 > =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D >=20 >=20 > Name: Secure Telephone Identity Revisited (stir) > Area: RAI >=20 > Chairs: TBD > Area Advisor: Richard Barnes >=20 > Mailing list: stir@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/stir >=20 > 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. As with email, the claimed source identity of a SIP > request is not verified, and this permits unauthorized use of source > identities as part of deceptive and coercive activities, such as > robocalling (bulk unsolicited commercial communications), vishing > (voicemail hacking, and impersonating banks) and swatting (impersonating > callers to emergency services to stimulate unwarranted large scale law > enforcement deployments). This working group will define a deployable > mechanism that verifies the authorization of the calling party to use > a particular telephone number. >=20 > SIP is one of the main VoIP technologies used by parties that want to > present an incorrect origin, in this context an origin telephone number. > Several previous efforts have tried to secure the origins of SIP > communications, including RFC 3325, RFC 4474, and the VIPR working group. > To date, however, true validation of the source of SIP calls has not seen > any appreciable deployment. Several factors contributed to this lack of > success, including: failure of the problem to be seen as critical at the > time; lack of any technical means of producing a proof of authority over > telephone numbers; misalignment of the mechanisms proposed by RFC 4474 > with the complex deployment environment that has emerged for SIP; lack of > end-to-end SIP session establishment; and inherent operational problems > with a transitive trust model. To make deployment of this solution more > likely, consideration must be given to latency, real-time performance, > computational overhead, and administrative overhead for the legitimate > call source and all verifiers. >=20 > As its first work item, the working group will specify a SIP header-based > authorization mechanism to verify the originator of a SIP session is > authorized to use the claimed source telephone number, where the session > is established with SIP end to end. This is called an in-band mechanism. > The mechanism will use a canonical telephone number representation > specified by the working group, including any mappings that might be > needed between the SIP header fields and the canonical telephone number > representation. The working group will consider choices for protecting > identity information and credentials used, but will likely be based on a > digital signature mechanism that covers a set of information in the SIP > header fields, and verification will employ a credential that contains > the public key and is associated with the one or more telephone numbers. > In order to be authoritative, credentials used with this mechanism will > be derived from existing telephone number assignment and delegation > models. That is, when a telephone number or range of telephone numbers > is delegated to an entity, relevant credentials will be generated (or > modified) to reflect such delegation. The mechanism must allow parties > who are not delegated a telephone number, but are authorized by the > entity who is delegated the number, to place calls using the identity. >=20 > After completing the in-band mechanism, the working group will consider > session establishment where there are one or more non-SIP hops, most > likely using an out-of-band authorization mechanism. However, the > in-band and the out-of-band mechanisms should share as much in common as > possible, especially the credentials. >=20 > Expansion of the authorization mechanism to identities using the > user@domain form deferred since the main focus of the working group is to > develop a solution for telephone numbers. >=20 > The working group will coordinate with the Security Area on credential > management. >=20 > The working group will coordinate with other working groups in the RAI > Area regarding signaling through existing deployments. >=20 > Authentication and authorization of identity is closely linked to > privacy, and these security features frequently come at the cost of > privacy. 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 > 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 > The working group will deliver the following: >=20 > - A problem statement detailing the deployment environment and > situation that motivate work on secure telephone identity >=20 > - A mechanism document describing the SIP end-to-end with telephone > number-based identities=20 >=20 > - A document describing the credentials required to support > telephone number identity authentication >=20 > - A fallback mechanism to allow out-of-band identity establishment > during call setup >=20 > Milestones >=20 > Sep 2013 Submit problem statement for Informational > Nov 2013 Submit in-band mechanism for Proposed Standard > Feb 2014 Submit credential specification for Proposed Standard > Jun 2014 Submit fallback for Proposed Standard >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From md3135@att.com Fri Jul 19 17:52: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 F14C511E81CC for ; Fri, 19 Jul 2013 17:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBQ2Y2zSG8Lc for ; Fri, 19 Jul 2013 17:51:53 -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 D63BF11E8160 for ; Fri, 19 Jul 2013 17:51:52 -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 82fd9e15.2aaac3206940.9160924.00-540.25426220.nbfkord-smmo05.seg.att.com (envelope-from ); Sat, 20 Jul 2013 00:51:52 +0000 (UTC) X-MXL-Hash: 51e9df2845cddbc9-a8d4f12af83bd91e20bddcb5ec28220b7415fc27 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 72fd9e15.0.9160914.00-230.25426192.nbfkord-smmo05.seg.att.com (envelope-from ); Sat, 20 Jul 2013 00:51:52 +0000 (UTC) X-MXL-Hash: 51e9df2841650e2f-7e7882d2d4f78737c46e2cf9b1d990b1102efc4d 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 r6K0ppiD030816; Fri, 19 Jul 2013 20:51:51 -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 r6K0phKp030743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 20:51:45 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Sat, 20 Jul 2013 00:51:36 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; Fri, 19 Jul 2013 20:51:37 -0400 From: "DOLLY, MARTIN C" To: "Cullen Jennings (fluffy)" , IETF STIR Mail List Thread-Topic: [stir] Draft STIR Charter - out of band Thread-Index: AQHOhN3PqXoTPOIuxkG+0J9PAbgZkZlstW2Q Date: Sat, 20 Jul 2013 00:51:36 +0000 Message-ID: References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> <457ED3A0-D8D1-4420-A2C3-5B07B16AE641@vigilsec.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.92.144] 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=Hb+juF48 c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=kPTvEunjN3AA:10 a=rXGSGp4d_bsA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=XQAI-qniSKoA:10 a=48vgC7mUAAAA:8 a=tGX7uwomAAAA:8] X-AnalysisOut: [ a=fHwox6dvN5uczF9F_1YA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=nY38QUQankMA:10 a=cgXXSQ_a7OZa3qZJ:21 a=4_TdwX6N05LW] X-AnalysisOut: [lid7:21] Cc: Russ Housley Subject: Re: [stir] Draft STIR Charter - 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, 20 Jul 2013 00:52:00 -0000 What? Out of band before In band. What air are you breathing..... sorry fl= uf... you are off base on this... let's think economic deployable... To date I have been nice but you bring out the best, this has been a USA sy= nergic discussion, no consideration to international, so IETF is going yiel= d to the ITU.....a(xx)=20 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Cul= len Jennings (fluffy) Sent: Friday, July 19, 2013 8:12 PM To: IETF STIR Mail List Cc: Russ Housley Subject: Re: [stir] Draft STIR Charter - out of band I'm listening to the arguments for in band or out of band but right now I a= m pretty skeptical that doing in-band before out-of-band is the right order= . I suspect we need them both. Let me say a bit more=20 Mobile phones could have done wideband audio long ago, but they did not. Th= ere was no incentive for them to do it since there was no alternative that = could do do wideband and had the same mobility properties. Then along came = smart phones and started providing much better audio quality using things l= ike Skype. Suddenly there was an incentive to do wideband audio on mobile p= hones and you are starting to see that deploy.=20 So lets talk about carrier to carrier SIP interconnects. Unless there is an= real incentive, I sort of doubt that they will initially do a lot more tha= n the SS7 interconnects they replace. No incentive and complicated to chang= e the business agreements in place. Particularly for interconnects between = say Nigeria and US.=20 However, there is a great incentive for smartphones to implement an out of = band solutions even it only works to other smartphones. Once that existed, = there would be an incentive for non smart phones to get an equivalent level= of service and that would most likely be done with a in band solution but = at that point there is an incentive to deploy in band.=20 A solution that only worked for smart phones is clearly not as useful as on= e that works for all phones, but doing both at the same time seems the most= likely way to me to get either of them to deploy.=20 Sure it would be better for the non over the top service providers if there= was only a solution that worked for the carrier a telephone numbers was de= legated down to form a nation level, but as apple showed with iMessage, it = can be better for the users to have two ways to send a SMS messages to anot= her user. One way that goes thought the provider that the phone number was = delegated to, and one way that goes around the the carrier the phone number= was delegated to.=20 So, I'd like to see the charter changed to work on both in-band and out-of-= band at the same time.=20 On Jul 16, 2013, at 1:33 PM, Russ Housley wrote: > I have tried to pull all of the discussion into an updated charter. I ha= ve also attached a diff to make it easier to review. >=20 > Russ >=20 >=20 >=20 > =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D >=20 >=20 > Name: Secure Telephone Identity Revisited (stir) > Area: RAI >=20 > Chairs: TBD > Area Advisor: Richard Barnes >=20 > Mailing list: stir@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/stir >=20 > 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. As with email, the claimed source identity of a SIP > request is not verified, and this permits unauthorized use of source > identities as part of deceptive and coercive activities, such as > robocalling (bulk unsolicited commercial communications), vishing > (voicemail hacking, and impersonating banks) and swatting (impersonating > callers to emergency services to stimulate unwarranted large scale law > enforcement deployments). This working group will define a deployable > mechanism that verifies the authorization of the calling party to use > a particular telephone number. >=20 > SIP is one of the main VoIP technologies used by parties that want to > present an incorrect origin, in this context an origin telephone number. > Several previous efforts have tried to secure the origins of SIP > communications, including RFC 3325, RFC 4474, and the VIPR working group. > To date, however, true validation of the source of SIP calls has not seen > any appreciable deployment. Several factors contributed to this lack of > success, including: failure of the problem to be seen as critical at the > time; lack of any technical means of producing a proof of authority over > telephone numbers; misalignment of the mechanisms proposed by RFC 4474 > with the complex deployment environment that has emerged for SIP; lack of > end-to-end SIP session establishment; and inherent operational problems > with a transitive trust model. To make deployment of this solution more > likely, consideration must be given to latency, real-time performance, > computational overhead, and administrative overhead for the legitimate > call source and all verifiers. >=20 > As its first work item, the working group will specify a SIP header-based > authorization mechanism to verify the originator of a SIP session is > authorized to use the claimed source telephone number, where the session > is established with SIP end to end. This is called an in-band mechanism. > The mechanism will use a canonical telephone number representation > specified by the working group, including any mappings that might be > needed between the SIP header fields and the canonical telephone number > representation. The working group will consider choices for protecting > identity information and credentials used, but will likely be based on a > digital signature mechanism that covers a set of information in the SIP > header fields, and verification will employ a credential that contains > the public key and is associated with the one or more telephone numbers. > In order to be authoritative, credentials used with this mechanism will > be derived from existing telephone number assignment and delegation > models. That is, when a telephone number or range of telephone numbers > is delegated to an entity, relevant credentials will be generated (or > modified) to reflect such delegation. The mechanism must allow parties > who are not delegated a telephone number, but are authorized by the > entity who is delegated the number, to place calls using the identity. >=20 > After completing the in-band mechanism, the working group will consider > session establishment where there are one or more non-SIP hops, most > likely using an out-of-band authorization mechanism. However, the > in-band and the out-of-band mechanisms should share as much in common as > possible, especially the credentials. >=20 > Expansion of the authorization mechanism to identities using the > user@domain form deferred since the main focus of the working group is to > develop a solution for telephone numbers. >=20 > The working group will coordinate with the Security Area on credential > management. >=20 > The working group will coordinate with other working groups in the RAI > Area regarding signaling through existing deployments. >=20 > Authentication and authorization of identity is closely linked to > privacy, and these security features frequently come at the cost of > privacy. 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 > 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 > The working group will deliver the following: >=20 > - A problem statement detailing the deployment environment and > situation that motivate work on secure telephone identity >=20 > - A mechanism document describing the SIP end-to-end with telephone > number-based identities=20 >=20 > - A document describing the credentials required to support > telephone number identity authentication >=20 > - A fallback mechanism to allow out-of-band identity establishment > during call setup >=20 > Milestones >=20 > Sep 2013 Submit problem statement for Informational > Nov 2013 Submit in-band mechanism for Proposed Standard > Feb 2014 Submit credential specification for Proposed Standard > Jun 2014 Submit fallback for Proposed Standard >=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 Fri Jul 19 19:46: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 1155721E808D for ; Fri, 19 Jul 2013 19:46:45 -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 I4Itlfw22ffC for ; Fri, 19 Jul 2013 19:46:38 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 814A421F964C for ; Fri, 19 Jul 2013 19:46:38 -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 r6K2kPUt019605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 20 Jul 2013 02:46:26 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 r6K2kPMT028738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Jul 2013 02:46:25 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 r6K2kPE3007668; Sat, 20 Jul 2013 02:46:25 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 19 Jul 2013 19: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: Fri, 19 Jul 2013 22:46:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <94159EA4-C1B2-49B7-A63E-F87F4178806A@oracle.com> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> <457ED3A0-D8D1-4420-A2C3-5B07B16AE641@vigilsec.com> To: Cullen Jennings (fluffy) X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: IETF STIR Mail List Subject: Re: [stir] Draft STIR Charter - Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 02:46:45 -0000 On Jul 19, 2013, at 8:12 PM, Cullen Jennings (fluffy) = wrote: >=20 > The number one problem with VIPR is a privacy issue where one person = can learn about if Alice is calling Bob. I want to make sure we are = thinking about the privacy issues form the start.=20 Wow. If you think that was what doomed VIPR then we are in very = different worlds. Or do you just mean that was the concern you guys = focused on solving for it? Obviously we do have to seriously consider = privacy for STIR, but we don't have to go beyond what privacy you have = now. We're not here to solve other problems, and trying to solve other = problems is what gets us in trouble with getting things defined in such = a way that people can and want to use it (e.g., rfc4474). We can't = introduce new problems, but the problem we're trying to solve is source = number validation. > I think we need to add a bit more to the text above. I would suggest = something along the lines of saying who can do this verification. I = think it needs to be some network device or endpoint authorized by the = called party. Perhaps there is some other way to phrase the privacy = issues.=20 >=20 > To provide a very specific use case, I don't want EKR or some random = transit provider to be be able to figure out if I am calling EKR's wife = or not. If we fail to have this property, I don't believe this work will = be deployed - particularly in the EU.=20 Umm... they can figure that out *today*. That's not a problem we've = been tasked to solve, nor is it one we should try to solve. Not only is = that data clearly available to them, there's an entire industry around = storing and analyzing that data, usually for things related to billing. = It's called "Call Detail Records". Perhaps you've heard of it? ;) Or do you mean you don't want providers that are themselves not in the = call signaling path to figure it out? I'm cool with that. I think that = would certainly be something for the out-of-band to worry about, but I = don't see how the in-band would have such a problem. -hadriel From michael.hammer@yaanatech.com Fri Jul 19 21:16: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 C8D6B21E80C9 for ; Fri, 19 Jul 2013 21:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 K26k7PlxLoXY for ; Fri, 19 Jul 2013 21:16: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 E749511E81DD for ; Fri, 19 Jul 2013 21:16:29 -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, 19 Jul 2013 21:16:27 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) Thread-Index: AQHOgvzGoW2Sqvrxc0GEvdoogk5ro5lpa5QAgAAoCgCAAe3VAIAAA5sAgAEbyACAABl1gP//jBDQgACJywD//6q3gIAAj4gA///vQ+A= Date: Sat, 20 Jul 2013 04:16:25 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC19E91@EX2K10MB1.corp.yaanatech.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! ! ! ! ! ! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> <84432CF7-A220-46F0-B945-F41F09F7061E@oracle.com> , <1E1AA91D-F3C8-4B43-A647-F898B9AB9778@oracle.com> <825EFE8B-555B-47EC-AF5D-55755C2439D5@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC19C60@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC19DAC@EX2K10MB1.corp.yaanatech.com> <25F15A58-80AB-442B-8121-F5144890C829@oracle.com> In-Reply-To: <25F15A58-80AB-442B-8121-F5144890C829@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.110] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_048A_01CE84DE.5EE6C030" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 04:16:39 -0000 ------=_NextPart_000_048A_01CE84DE.5EE6C030 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Fair enough. I need to stop writing emails and write a draft. :) Have a good weekend. Mike -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Friday, July 19, 2013 6:16 PM To: Michael Hammer Cc: stir@ietf.org Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) I'll respond to the other points separately tonight when I have more time, but this one is different so I'll just respond quick.. On Jul 19, 2013, at 5:33 PM, Michael Hammer wrote: >>> As for having a draft of not, it is obvious that you had been >>> working on > this prior to the STIR mail list being formed. Actually, I wasn't working on it at all before STIR was formed, nor even when STIR was formed. Some of us had discussed at a very high level, several years ago, about using DNS/ENUM for caller-id verification. This was back when we were debating rfc4474's uselessness and trying to fix it. But it never got into the details or more than just a few sentences in email on one of the SIP-related mailing lists, at least as far as I can recall or was involved in. Even at the STIR kickoff meeting in Wash DC a couple months ago, we had jokingly mentioned it in the meeting, but I had mentally dismissed it as untenable due to privacy concerns. It was only about a month ago during the discussions on this list that I realized (or someone else pointed out) that (1) the contents of the DNS entries don't need to reveal anything private other than a public key value, and (2) that since we do use ENUM today in a private-access manner, we could still do that if it turned out we wanted to keep the databases private in the end. So I wrote up the draft in spurts over the past couple weeks, and only really got it done the day before submission was due. :) > So, dumping a fait accompli > on the group and suggesting that being first to get a draft out is > reason not to consider other possibilities prior to the WG even being > formed just doesn't seem very sporting of you. If anything, it is the opposite situation: the running assumption when the STIR list was created was we'd be using X.509 certs and HTTP, with some tweak of RFC 4474. There are also several people on the list who have allergic reactions to the word "DNS". Trust me, what I'm proposing is NOT a fait accompli, and I'm not claiming it should be. I'm not at all claiming because I got a draft submitted that somehow its superior. I'm just saying we can't really argue much in detail until we see what the alternatives are. We will really need to spend a long time in meetings going over any proposed solutions, and chew on them for a while. > I had hoped that responding to your > questions across the various emails had helped clarify some ideas > versus confuse you. I guess "concrete" is in the eye of the beholder. I appreciate the emails - I'm just having a hard time understanding and keeping track of the various proposals - there's not just one cert-based or even HTTP-based proposal. So without having something written down, it's hard to know what the alternatives are. :) -hadriel ------=_NextPart_000_048A_01CE84DE.5EE6C030 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcy MDA0MTYyNVowIwYJKoZIhvcNAQkEMRYEFLPKJX7mTXgpryIhytvbo9BXDcRIMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEABu4FhJvsSaTfpPytS5Sg8jQPNSIZyZFbSjcQG01r u221EGWm41DpZb3mZzoJbXmmWL3oQPIlOur8GmaZr+nT89A4HMacHHAZEYcxvfAYLT1A6hXuoFvB +dwBajqZoOUY69PGS+k0aLM4Eaj7JJoKjfXv5YVaqeUhtoBLAslDZp0TJShqe05Gx8K9EHGxO0PD uISUlXrc4bMEdigRhWxWGleNSdem3Xnum1fqaeg0EOSYW00Kgr0mOibc5hgLISBP0RKVUusXLQY9 Fbv9fu6raaymz367R+X5eGvV9RJ4tq1rxqeJjLlUreRY5AiF4/DBrUAXVYz034Gsg0CymOJ/PwAA AAAAAA== ------=_NextPart_000_048A_01CE84DE.5EE6C030-- From hadriel.kaplan@oracle.com Fri Jul 19 21:55: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 416B711E81DD for ; Fri, 19 Jul 2013 21:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.5 X-Spam-Level: X-Spam-Status: No, score=-6.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHkClSj0+xpA for ; Fri, 19 Jul 2013 21:55:03 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 91A9511E81DF for ; Fri, 19 Jul 2013 21:55:03 -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 r6K4t1Wn020912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 20 Jul 2013 04:55:02 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 r6K4sxXL010625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Jul 2013 04:55:00 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 r6K4sxas013392; Sat, 20 Jul 2013 04:54:59 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 19 Jul 2013 21:54: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: <00C069FD01E0324C9FFCADF539701DB3BBC19DAC@EX2K10MB1.corp.yaanatech.com> Date: Sat, 20 Jul 2013 00:54:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! ! ! ! ! ! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> <84432CF7-A220-46F0-B945-F41F09F7061E@oracle.com> , <1E1AA91D-F3C8-4B43-A647-F898B9AB9778@oracle.com> <825EFE8B-555B-47EC-AF5D-55755C2439D5@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC19C60@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC19DAC@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] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 04:55:10 -0000 On Jul 19, 2013, at 5:33 PM, Michael Hammer = wrote: >>> I read your CIDER draft, but am trying to draw out the salient = points on > where the chain of trust lies and what is really different. Maybe I = am > missing some key point about what is securing the DNS entry and what = is in > that entry that needs to be secured and how that relates to the key = used to > sign the SIP header element. Right, so the basic gist is the private key used to sign SIP request = caller-ids with, has its public key counterpart in a DNS TXT RR. It may = be The Public DNS, or it may be a controlled-access private or federated = one. Regardless, the public key remains in a DNS, and it's retrieved by = the verifier using the DNS protocol. Let's call that public key the = "CID Key", for Caller-ID key. Let's call the entity who uploaded the = CID Key into DNS the "Assignee". The DNS TTL for the entry is likely quite short... say 30 minutes or = even less. Thus DNS caches will time it out in 30 minutes. There's not = much point in caching them longer, because it's rare for source call = numbers to be used frequently enough to make it worth caching for = longer. Even for those that are "worth it", a DNS query every 30 = minutes for the frequent ones isn't a big deal. It might be a lot = shorter TTL even, but that's all up to the admin to decide anyway. That = TTL actually has nothing to do with how long a DNSSEC signature is valid = for, but it's useful to keep the TTL short purely to force DNS caches to = flush and check DNS again. =46rom a DNSSEC perspective, what's securing the DNS entry is a = signature, using a private key of the admin, with the public key also = being available in DNS. There's actually a chained signing model for = DNS subdomain hierarchies, but in our case you can skip it so long as = the public key value matches the country-code's, so I'll ignore it for = now. Fundamentally, it's essentially the same concept as what you = described: having all certs signed by the country-code admin. In this = case, all the TXT RRs are signed by the country-code admin. Let's call = the DNS admin's public key the "DNS Key", and call the signature of the = TXT RR (containing the CID Key) a "RR Signature". The RR Signature is = sent back in a resource record along with the TXT RR, in the same DNS = answer packet, when you query DNS for the TXT RR. So it's similar to a cert when DNS is queried/answered, but there's no = point in giving a "cert" back to the Assignee, because it serves no = purpose. No one gets a "cert" from the Assignee - they get it from DNS. = Because they can get it from DNS, the DNS admin can actually set the RR = Signature expiry time to be relatively short. Let's say one week. They = can do that because they can re-sign the TXT RR (generate a new RR = Signature) without communicating that change to the Assignee at all. = The Assignee never has to upload a fresh CID key again, until their key = is compromised or their E.164 number ports out. Meanwhile the DNS admin = can re-sign again and again. Even if the DNS admin's DNS Key is = compromised, they can change it and re-sign without having to have the = Assignees do anything. If the Assignee's CID key is compromised, the Assignee uploads a new CID = Key to the DNS admin, replacing the old one. TTL expiry cleans out the = old caches, triggering a fresh query to the DNS. Thus we don't need = revocations. For those concerned with DNS injection attacks using a = compromised key, or broken caches holding on to old DNS answers using a = compromised DNS Key, the RR Signature itself only lasts a week. I should mention that the CIDER draft currently expects the STIR = verifier systems to be client stub resolvers. In other words, the SIP = system performing STIR verification wouldn't actually do the DNS tree = walking or DNSSEC validation; their local DNS servers would do it on = their behalf. =46rom a security perspective it means the verifier needs = to trust its local DNS resolvers, but for the STIR use-case that seems = reasonable. The benefit being that you can basically off-load the work, = use a private or federated DNS model, and so that a carrier can use = specialized systems or rules to do that stuff if they want to. (such = systems already exist for private ENUM use today, for similar = call-signaling purposes, though they don't use DNSSEC) I also expect there to be local actual copies of the entire DNS tree for = a country-code; for example large US carriers would likely have a local = copy for all US numbers; Canadian carriers for Canada numbers; etc. = Their local copy is not authoritative, but it's a slave synchronizing = stuff from the master run by the country-code admin or a = commonly-agreed-upon admin. That's what happens today in NPAC, for = example. Smaller carriers, or non-regulated providers, or Enterprises, = or whatever - they can just access the master using DNS, or through = their upstream carrier, or a third party middleman. The reason I = mention this is that these local copies don't need to deal with DNSSEC = at all - they have a synchronized copy of the master over some secure = channel, so the DNSSEC stuff isn't necessary for their local copy. The reason that the last part is different for certs, is that so far the = proposals for using certs has been based on rfc4474: that the caller = identifies the HTTP URL to go get the cert from, by putting the URL in = the SIP message in the Identity-Info header field. That means if an = E.164 cert private key is compromised, it's trivial to abuse it - just = generate a SIP INVITE with your own HTTP URL to your site holding the = original cert, and use the compromised private kay to sign the INVITE. = That's why we'd need cert revocations. We couldn't even have short = expiries for the certs, of anything like a week long for example, = because it would require getting a new cert up to the country-code admin = to be re-signed every week. But with DNS, it's not trivial to use a = compromised CID Key: the DNS entry would be changed, and quickly take = effect. So we wouldn't need actual revocations. -hadriel p.s. I didn't mean to spend so much time or focus on the cert revocation = aspect for using CIDER - avoiding revocations isn't really the major = benefit of using CIDER. There are many more benefits to using CIDER. = Right now I'm just trying to figure out what the drawbacks/downsides to = it are, and where/if it would break or be less practical than = alternatives. (for me, the STIR thing is more about practicality for the = target use-cases than anything else) From hadriel.kaplan@oracle.com Fri Jul 19 22:04: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 B928A11E81DD for ; Fri, 19 Jul 2013 22:04:11 -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 3kL7noW-chbo for ; Fri, 19 Jul 2013 22:04:06 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 15B5321F9F50 for ; Fri, 19 Jul 2013 22:04: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 r6K544Bv025742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 20 Jul 2013 05:04:05 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 r6K543ni026727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Jul 2013 05:04:04 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 r6K5439M023402; Sat, 20 Jul 2013 05:04:03 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 19 Jul 2013 22:04: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: Date: Sat, 20 Jul 2013 01:04:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6642171F-7D32-408F-844B-21727086DC85@oracle.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@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 Mail List" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jul 2013 05:04:11 -0000 Nope, I don't think porting numbers requires a cert revocation or = anything logically equivalent. As long as it ages out within a few = months, I think it would be fine. (though as an aside, I still think = CIDER DNS TTLs should be short, but not for this reason) -hadriel On Jul 19, 2013, at 8:12 PM, Cullen Jennings (fluffy) = wrote: > On Jul 17, 2013, at 7:58 AM, Brian Rosen wrote: >=20 >> Small note: >> You would have to keep TTLs for at least U.S. zones under a few = minutes to allow the 15 minute port. >> I'd actually probably set it at a minute or two. >=20 > Originally I was thinking this way but I slowly came to think this may = not be the case depending on you attack model.=20 >=20 > Lets say my number was with Verizon then I move it to Sprint. Sure the = ports needs to happen fast but how fast does Verizon need to loose the = ability to impersonate me? That might not have to happen as fast - for = example, if Verizon could continue signing records on my behalf for = another 30 days after the port, would that really matter? Sure people = have to recognize the new signatures from Sprint very quickly ( like = minutes ), but I'm not sure the old entities need to loose my trust = right away.=20 >=20 > This is more a question about the attack model and what the = requirement is for how quickly someone that used to be able to assert my = identity looses that ability. Perhaps the time is the same as the port = time but it seem worth thinking about what a model would look like where = that time was much higher.=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Fri Jul 19 23:35: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 AB96C11E8116 for ; Fri, 19 Jul 2013 23:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ug00bRQ3RdR for ; Fri, 19 Jul 2013 23:35:06 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2EACC11E80E4 for ; Fri, 19 Jul 2013 23:35:06 -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 r6K6Z4gE005285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 20 Jul 2013 06:35:05 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 r6K6Z2TG026339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Jul 2013 06:35:04 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 r6K6Z2jQ016878; Sat, 20 Jul 2013 06:35:02 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 19 Jul 2013 23:35: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: Sat, 20 Jul 2013 02:34:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8D3E41B3-6A3B-4982-8193-C975A3C867BB@oracle.com> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> <457ED3A0-D8D1-4420-A2C3-5B07B16AE641@vigilsec.com> To: Cullen Jennings (fluffy) X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: IETF STIR Mail List Subject: Re: [stir] Draft STIR Charter - 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, 20 Jul 2013 06:35:12 -0000 On Jul 19, 2013, at 8:12 PM, Cullen Jennings (fluffy) = wrote: > Mobile phones could have done wideband audio long ago, but they did = not. There was no incentive for them to do it since there was no = alternative that could do do wideband and had the same mobility = properties. Then along came smart phones and started providing much = better audio quality using things like Skype. Suddenly there was an = incentive to do wideband audio on mobile phones and you are starting to = see that deploy.=20 OK, you think Skype is the incentive for providing wideband audio. = Might I suggest that if that were the case, that the reason it was an = incentive is because Skype represented a threat to carrier's business = models? How is Apple/Android/whatever providing out-of-band caller-id = validation a threat to a carrier's business model? If anything, it = would relieve some pressure on the carriers. The "threat" right now is an FCC mandate, or even just a general loss of = trust in the PSTN system. The last thing they want is for voice service = to become like email, with constant spam and phishing attacks. = Carrier's aren't idiots. It takes time for things to reach a level that = can overcome the inertia, but I think we're reaching that point. > So lets talk about carrier to carrier SIP interconnects. Unless there = is an real incentive, I sort of doubt that they will initially do a lot = more than the SS7 interconnects they replace. No incentive and = complicated to change the business agreements in place. Particularly for = interconnects between say Nigeria and US.=20 > However, there is a great incentive for smartphones to implement an = out of band solutions even it only works to other smartphones. Once that = existed, there would be an incentive for non smart phones to get an = equivalent level of service and that would most likely be done with a in = band solution but at that point there is an incentive to deploy in band.=20= That's an interesting psychological motivator. I'm sure Nigeria will be = strongly motivated to deploy secure caller-id because of a smartphone = app proving it can be done.[1] ;) > A solution that only worked for smart phones is clearly not as useful = as one that works for all phones, but doing both at the same time seems = the most likely way to me to get either of them to deploy.=20 Actually, I think it would make deploying an in-band one more = challenging, for various reasons. But I have no crystal ball. > Sure it would be better for the non over the top service providers if = there was only a solution that worked for the carrier a telephone = numbers was delegated down to form a nation level, but as apple showed = with iMessage, it can be better for the users to have two ways to send a = SMS messages to another user. One way that goes thought the provider = that the phone number was delegated to, and one way that goes around the = the carrier the phone number was delegated to.=20 And next you'll be telling us: "oh, and now that we have this way around = them, lets just send SIP over that channel and bypass the carriers". I = understand the personal desire for that. I believe the solution for it = is called VIPR. But I don't think it's helpful in getting an in-band = solution deployed. We don't need to threaten the carriers. Furthermore, I think you're dead wrong about the motivated actors here. = The over-the-top service providers are actually the *cause* of the = problem, as far as I can tell. The "traditional" and regulated = carriers, MSOs, etc., are the ones who want to stop it. > So, I'd like to see the charter changed to work on both in-band and = out-of-band at the same time.=20 Then charter a separate working group for out-of-band, or charter a = separate working group for in-band. At the end of the day, charter items reflect what the working group = spends its time doing - the time in physical meetings, conference calls, = mailing lists, document reviews, etc. It also identifies the target = audience for participation, scope, and work outcome. We've been told we need to get a source identity solution quickly. That = means those of us interested in in-band need to focus on in-band, and = those of us interested in out-of-band need to focus on out-of-band. We = need real face-time/mic-time in meetings, without being rushed by chairs = to move on to next topics/presentations. We need to cut down on email = traffic, so those of us who have other day-jobs can focus on just what = we care about. We need to schedule interims and conference calls, = without worrying about accommodating more people's schedules. In short: = we need focus. I know there's some people overlap, but *every* RAI working group has = people overlap. It's kinda like RTCWEB and CLUE - both have to do with audio and video = multi-stream communication scenarios, but for very different deployment = models/agents/endpoints. It's been challenging for when they intersect = in SDP usage, but I don't think anyone would combine them into one = RTCWEB-CLUE WG and expect to get anything done. -hadriel [1] As it happens, I've been told Nigeria may well be motivated to = provide secure caller-ids... but it's not due to smartphone apps. From dhc@dcrocker.net Sat Jul 20 06: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 7606611E8108 for ; Sat, 20 Jul 2013 06:35:49 -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 14j0mqawnINt for ; Sat, 20 Jul 2013 06:35:44 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8C111E8101 for ; Sat, 20 Jul 2013 06:35:44 -0700 (PDT) Received: from [192.168.0.83] (host-212-159-176-45.static.as13285.net [212.159.176.45]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r6KDZbhO004526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 20 Jul 2013 06:35:42 -0700 Message-ID: <51EA9202.3090406@dcrocker.net> Date: Sat, 20 Jul 2013 14:34:58 +0100 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: <011501ce7676$79b756c0$6d260440$@shockey.us> <01bc01ce7691$e73f8bc0$b5bea340$@shockey.us> <51D1DC32.1080308@dcrocker.net> <520DE022-7E21-4B31-82E1-D332A2A94E63@oracle.com> <2B0F677F0B95454297753F58D4A07FA30127F61718@FHDP1LUMXC7V31.us.one.verizon.com> <51D4B768.5090503@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]); Sat, 20 Jul 2013 06:35:43 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] response-time window ( was Re: 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: Sat, 20 Jul 2013 13:35:49 -0000 On 7/20/2013 1:12 AM, Cullen Jennings (fluffy) wrote: > sort of a tangent but we are seeing solutions coming out for HTTPS transactions that work in one round trip (never mind the are called zero round trip:-) There have been a number of recitations of very low transaction overhead when using an HTTP-based mechanism. (The 'S' just makes it sound sexier, while adding another layer of mechanism.) I'm sure the recitations are accurate, but only within some significant operating constraints. In this case, the essential requirement is going to be -- at the very least -- that the validator already has an open TCP connection and a working session with the server being queried. Fast-path analysis of connection behavior gives best-case numbers and it's always an important part of understanding the overall mix of performance issues. However it's also nearly always irrelevant to the analysis of a zero-context exchange. That is, when the validator makes a first contact with a server. For some very large percentage of likely traffic, maintaining a continuing context amongst major validators and major servers will no doubt give wonderful numbers. When MajorTelcoA's validator queries the server for Major TelcoB. Unfortunately, they aren't the interesting case when designing a global protocol. For the current topic, the interesting case is an enterprise or smartphone validator querying a server for a number the validator has never seen before. That's going to incur all the 5-7 round-trip latencies -- heck, maybe more -- with all of the significantly variable delays we see across the open Internet. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Sat Jul 20 06:52: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 CDB5E11E810A for ; Sat, 20 Jul 2013 06:52:06 -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 ZBhx5tj98VPX for ; Sat, 20 Jul 2013 06:52:01 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E05D311E8101 for ; Sat, 20 Jul 2013 06:52:01 -0700 (PDT) Received: from [192.168.0.83] (host-212-159-176-45.static.as13285.net [212.159.176.45]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r6KDptXY004804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 20 Jul 2013 06:52:00 -0700 Message-ID: <51EA95D4.905@dcrocker.net> Date: Sat, 20 Jul 2013 14:51:16 +0100 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: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@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]); Sat, 20 Jul 2013 06:52:01 -0700 (PDT) Cc: IETF STIR Mail List Subject: Re: [stir] Draft STIR 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: Sat, 20 Jul 2013 13:52:06 -0000 On 7/16/2013 9:21 PM, Russ Housley wrote: > Dave: > >> Meta-point: >> >> The text is only about authentication, but the discussion has been about authorization. For example one might have an authenticated originator value that is not the string displayed as Caller-ID.[*] I understood the purpose of the wg to be ensuring that the displayed string was authorized by its assignee. >> >> If no one cares about this distinction and everyone feels that "authenticate the originator" is sufficiently precise and accurate, fine, but I thought it worth making sure. > > You are correct, and several people agreed with you. However, none of you offered text. So, I have made a stab at updating the charter text to address this point. I'll post it in a minute. Russ, to close the loop on this: 1. The latest draft's vocabulary changes about this look good to me. Thanks for doing that. 2. I didn't offer wording changes because I felt tenuous enough about the issue that I wanted to ask about the issue in the abstract, before worrying about the wording. It's clear to me that there is a legitimate debate one might have between the two vocabulary choices of authentication vs. authorization, apparently even among folks with long-standing security backgrounds (thereby excluding me). (I was impressed to discover that RFC 4949 does list authorization as a vocabulary term! Does that mean the AAA folks have to become only AA?) >> Consideration of out-of-band mechanisms, to deal with transit across non-SIP hops, is deferred. > > I do not see consensus for this position. It is agree that an end-to-end SIP session is the first priority. However, others have said that an out-of-band solution is also needed to address the whole problem. This is the second priority, and the charter text that I will propose says: The latest language about this in the draft charter, and schedule you show in it, is workable I think. That said, I think Hadriel has reminded us of an important point: A draft charter beings as a blank sheet of paper. There are no rights that accrue to whatever the first draft contained. Everything in the charter needs to represent a reasonable consensus amongst those who will do the work (as well as the IESG), even though there's no working group to do a formal consensus process. My own reading of the list, about out-of-band, is that while it might not have clear rough consensus to take it out of the charter, I don't see anything close to a clear consensus to keep it in, either... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Henning.Schulzrinne@fcc.gov Sat Jul 20 14:36: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 7B4B411E80E0 for ; Sat, 20 Jul 2013 14:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.496, 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 6dI3Yfxq3toC for ; Sat, 20 Jul 2013 14:36: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 EC53411E80D1 for ; Sat, 20 Jul 2013 14:36:01 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "dcrocker@bbiw.net" Thread-Topic: [stir] CA Certs Thread-Index: AQHOhNbo8r2ZXD4LVUezhh/O3hUEKZluFxvt Date: Sat, 20 Jul 2013 21:35:29 +0000 References: <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! ! ! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> <84432CF7-A220-46F0-B945-F41F09F7061E@oracle.com> , <1E1AA91D-F3C8-4B43-A647-F898B9AB9778@oracle.com> , <51E9C96F.4@dcrocker.net> In-Reply-To: <51E9C96F.4@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 List" Subject: Re: [stir] CA Certs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jul 2013 21:36:06 -0000 I thought the general consensus was that carriers would do (most) of the va= lidating. If you include the Fortune 500 as other likely validators, that a= dds roughly 500 to the list. =0A= =0A= If we do get larger numbers, hierarchical subscription would work easily, i= .e., the carrier sends an event notification to the business, possibly usin= g the same SIP trunk they already have set up for call signaling.=0A= =0A= I don't see the combinatorial - you have one source of revocation notificat= ions (the database operator), and a smallish number of recipients (the vali= dators).=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: Dave Crocker [dhc@dcrocker.net]=0A= Sent: Friday, July 19, 2013 7:19 PM=0A= To: Henning Schulzrinne=0A= Cc: stir@ietf.org List=0A= Subject: Re: [stir] CA Certs=0A= =0A= On 7/19/2013 8:57 AM, Henning Schulzrinne wrote:=0A= > Since both revocations and ports are relatively rare and the number of va= lidators is relatively small (thousands, not millions),=0A= =0A= =0A= Henning,=0A= =0A= I thought that the operational goal was to permit validation by=0A= enterprises and even end-user-systems, and, I guess, even permit=0A= /signing/ by such systems.=0A= =0A= That's not a small total number and the combinatorials -- every pair=0A= that might do a SIP call is not a small working set.=0A= =0A= d/=0A= =0A= --=0A= Dave Crocker=0A= Brandenburg InternetWorking=0A= bbiw.net=0A= From Henning.Schulzrinne@fcc.gov Sat Jul 20 14:56: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 76DC521E8063 for ; Sat, 20 Jul 2013 14:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.483, 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 scJw8RZdjwD3 for ; Sat, 20 Jul 2013 14:56:31 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id C3EBD11E80F4 for ; Sat, 20 Jul 2013 14:56:30 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "dcrocker@bbiw.net" , "Cullen Jennings (fluffy)" Thread-Topic: [stir] response-time window ( was Re: Out-of-band vs. in-band Thread-Index: AQHOeEeD9o9eez0vlkuAOm6Gu/rxipls44WAgAEK1ACAAEd2KQ== Date: Sat, 20 Jul 2013 21:56:29 +0000 References: <011501ce7676$79b756c0$6d260440$@shockey.us> <01bc01ce7691$e73f8bc0$b5bea340$@shockey.us> <51D1DC32.1080308@dcrocker.net> <520DE022-7E21-4B31-82E1-D332A2A94E63@oracle.com> <2B0F677F0B95454297753F58D4A07FA30127F61718@FHDP1LUMXC7V31.us.one.verizon.com> <51D4B768.5090503@dcrocker.net> , <51EA9202.3090406@dcrocker.net> In-Reply-To: <51EA9202.3090406@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] response-time window ( was Re: 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, 20 Jul 2013 21:56:35 -0000 As discussed in a previous round of this same discussion, the likely case i= s that high-volume validators will cache all (domestic) records; the comple= te database easily fits in a single disk.=0A= =0A= For end system validation on mobile devices, if that were to be used, the p= ost-dial delay is already several seconds, so the additional latency is pro= bably not a major change, particularly if you optimize by caching records f= or numbers in your address book and call log. In all likelihood, good calls= to personal devices are already in your call log or address book, and the = additional delay for an occasional legitimate automated phone call, let alo= ne the unwanted robocall, is not likely to be significant from a user exper= ience. After all, the dentist office appointment reminder robot doesn't car= e whether the call takes a few more seconds to pick up.=0A= =0A= ________________________________________=0A= From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Dave Crock= er [dhc@dcrocker.net]=0A= Sent: Saturday, July 20, 2013 9:34 AM=0A= To: Cullen Jennings (fluffy)=0A= Cc: stir@ietf.org=0A= Subject: Re: [stir] response-time window ( was Re: Out-of-band vs. in-band= =0A= =0A= On 7/20/2013 1:12 AM, Cullen Jennings (fluffy) wrote:=0A= > sort of a tangent but we are seeing solutions coming out for HTTPS transa= ctions that work in one round trip (never mind the are called zero round tr= ip:-)=0A= =0A= =0A= There have been a number of recitations of very low transaction overhead=0A= when using an HTTP-based mechanism. (The 'S' just makes it sound=0A= sexier, while adding another layer of mechanism.)=0A= =0A= I'm sure the recitations are accurate, but only within some significant=0A= operating constraints.=0A= =0A= In this case, the essential requirement is going to be -- at the very=0A= least -- that the validator already has an open TCP connection and a=0A= working session with the server being queried.=0A= =0A= Fast-path analysis of connection behavior gives best-case numbers and=0A= it's always an important part of understanding the overall mix of=0A= performance issues.=0A= =0A= However it's also nearly always irrelevant to the analysis of a=0A= zero-context exchange. That is, when the validator makes a first=0A= contact with a server.=0A= =0A= For some very large percentage of likely traffic, maintaining a=0A= continuing context amongst major validators and major servers will no=0A= doubt give wonderful numbers. When MajorTelcoA's validator queries the=0A= server for Major TelcoB.=0A= =0A= Unfortunately, they aren't the interesting case when designing a global=0A= protocol.=0A= =0A= For the current topic, the interesting case is an enterprise or=0A= smartphone validator querying a server for a number the validator has=0A= never seen before.=0A= =0A= That's going to incur all the 5-7 round-trip latencies -- heck, maybe=0A= more -- with all of the significantly variable delays we see across the=0A= open Internet.=0A= =0A= =0A= d/=0A= =0A= --=0A= Dave Crocker=0A= Brandenburg InternetWorking=0A= bbiw.net=0A= _______________________________________________=0A= stir mailing list=0A= stir@ietf.org=0A= https://www.ietf.org/mailman/listinfo/stir=0A= From Henning.Schulzrinne@fcc.gov Sat Jul 20 15: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 CCE4F11E812A for ; Sat, 20 Jul 2013 15:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=0.471, 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 z4c8i2fNJUKe for ; Sat, 20 Jul 2013 15:14:39 -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 883B511E810D for ; Sat, 20 Jul 2013 15:14:35 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Hadriel Kaplan , Cullen Jennings Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) - attack model Thread-Index: AQHOhN3Wps6+uXc7/EmZZN/+0vrsIZltRmkAgADcG98= Date: Sat, 20 Jul 2013 22:14:34 +0000 References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> , <6642171F-7D32-408F-844B-21727086DC85@oracle.com> In-Reply-To: <6642171F-7D32-408F-844B-21727086DC85@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 Mail List" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jul 2013 22:14:43 -0000 If TTLs are short (below a few hours), essentially every query will be answ= ered by the authoritative server in the DNS model, since legitimate calls d= on't have much locality, from what I can tell.=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, July 20, 2013 1:04 AM=0A= To: Cullen Jennings=0A= Cc: stir@ietf.org Mail List=0A= Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model= =0A= =0A= Nope, I don't think porting numbers requires a cert revocation or anything = logically equivalent. As long as it ages out within a few months, I think = it would be fine. (though as an aside, I still think CIDER DNS TTLs should = be short, but not for this reason)=0A= =0A= -hadriel=0A= =0A= _______________________________________________=0A= stir mailing list=0A= stir@ietf.org=0A= https://www.ietf.org/mailman/listinfo/stir=0A= From hadriel.kaplan@oracle.com Sat Jul 20 16:13: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 87CC721E8091 for ; Sat, 20 Jul 2013 16:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djmXUntEqAEf for ; Sat, 20 Jul 2013 16:12:59 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8685B21E8088 for ; Sat, 20 Jul 2013 16:12:54 -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 r6KNCpPM020901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 20 Jul 2013 23:12:52 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 r6KNCoQw010729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Jul 2013 23:12:50 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 r6KNCnk7003912; Sat, 20 Jul 2013 23:12:49 GMT Received: from [192.168.2.7] (/184.61.127.93) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 20 Jul 2013 16:12:49 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Sat, 20 Jul 2013 19:12:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! ! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> , <6642171F-7D32-408F-844B-21727086DC85@oracle.com> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: Cullen Jennings , "stir@ietf.org Mail List" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jul 2013 23:13:04 -0000 By "authoritative" servers if you mean the CIDER Registry's DNS servers, = sure that could be the case. It's just not that useful to cache = specific E.164 number records (ie, DNS leaf nodes) for very long in the = general case, because the odds of another call from the same number = aren't high enough to make it worth it. And DNS querying is fairly = light-weight and fast, so timing out a cache and re-querying isn't a big = deal. The nice thing is the TTLs for the parent nodes (i.e., the = branches of the tree representing the prefixes) can be longer TTLs, and = even when the TTL expires then one lookup caches it for the next time = period - and since those parents represent ranges of numbers, the odds = get better for cache-hit "locality". There's some further optimization = one could make, but I don't think it's necessary to go into that level = of detail yet. Note that the above is about a public Internet access model; or even a = private/carrier model but for the providers/Enterprises/whatever that = don't have local copies and instead query the CIDER Registry and rely on = simple DNS caches. For the regulated carrier scenarios, regardless of whether it's in The = Public DNS or only available in a private manner, the carriers would get = local synchronized copies of the whole thing - at least for their = country-code branch, for example. For that scenario, their synch = connection to the master would be secure so not need DNSSEC, and it = would use some synch protocol (sub/pub or whatever) so the TTLs we're = talking about don't apply to their copy. For international caller-id validation - which probably wouldn't be in = the carrier's local DB copies for various reasons - if the foreign = country has a restricted-access model then the carriers' local DBs would = either recursively resolve through pre-agreed connections, or use the = master CIDER Registry and it would do it with pre-agreed connections. = That stuff is flexible and based on how other countries want to deploy, = and how the local country handles it.=20 In none of those cases do you need CRL lists or OCSP. The protocol's = mechanics clears the old ones out, either through TTLs or sub/pub; and = the CIDER Registry (the logical equivalent of the root CA for certs) can = keep its signature expiry short and keep re-signing without involving = anyone else. BTW, I'm not saying this is a huge deal - it's just one of the benefits = of DNS is all. (well... I guess it could be a big deal, if the alternative is putting = the HTTP URL in the SIP message a la rfc4474) -hadriel On Jul 20, 2013, at 6:14 PM, Henning Schulzrinne = wrote: > If TTLs are short (below a few hours), essentially every query will be = answered by the authoritative server in the DNS model, since legitimate = calls don't have much locality, from what I can tell. >=20 > ________________________________________ > From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of = Hadriel Kaplan [hadriel.kaplan@oracle.com] > Sent: Saturday, July 20, 2013 1:04 AM > To: Cullen Jennings > Cc: stir@ietf.org Mail List > Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack = model >=20 > Nope, I don't think porting numbers requires a cert revocation or = anything logically equivalent. As long as it ages out within a few = months, I think it would be fine. (though as an aside, I still think = CIDER DNS TTLs should be short, but not for this reason) >=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 From Henning.Schulzrinne@fcc.gov Sat Jul 20 16:20: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 B65CF11E8132 for ; Sat, 20 Jul 2013 16:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.459, 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 P9043CSt82Zi for ; Sat, 20 Jul 2013 16:20:12 -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 5F61C11E8131 for ; Sat, 20 Jul 2013 16:20:11 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Hadriel Kaplan Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) - attack model Thread-Index: AQHOhZ6qERlYeh/quUmQN5CnEkvqq5luMpPp Date: Sat, 20 Jul 2013 23:20:09 +0000 References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! ! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> , <6642171F-7D32-408F-844B-21727086DC85@oracle.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: Cullen Jennings , "stir@ietf.org Mail List" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jul 2013 23:20:16 -0000 I don't see the "benefit" of DNS here. There are two cases, either way:=0A= =0A= (1) A standard DNS hierarchy, with caching, but no synchronization. In that= case, you need short TTLs if you care about revocation. With short TTLs, y= ou get one country-level RTT for every query, even assuming no packet loss.= =0A= =0A= (2) A locally-cached synchronized DNS hierarchy, using some kind of rsync-l= ike mechanism.=0A= =0A= You can get the same two versions for HTTP and certs.=0A= =0A= The locally-cached synchronized DNS has essentially the same overhead as th= e locally-cached HTTP version, since the connection is nailed down.=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: Hadriel Kaplan [hadriel.kaplan@oracle.com]=0A= Sent: Saturday, July 20, 2013 7:12 PM=0A= To: Henning Schulzrinne=0A= Cc: Cullen Jennings; stir@ietf.org Mail List=0A= Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model= =0A= =0A= By "authoritative" servers if you mean the CIDER Registry's DNS servers, su= re that could be the case. It's just not that useful to cache specific E.1= 64 number records (ie, DNS leaf nodes) for very long in the general case, b= ecause the odds of another call from the same number aren't high enough to = make it worth it. And DNS querying is fairly light-weight and fast, so tim= ing out a cache and re-querying isn't a big deal. The nice thing is the TT= Ls for the parent nodes (i.e., the branches of the tree representing the pr= efixes) can be longer TTLs, and even when the TTL expires then one lookup c= aches it for the next time period - and since those parents represent range= s of numbers, the odds get better for cache-hit "locality". There's some f= urther optimization one could make, but I don't think it's necessary to go = into that level of detail yet.=0A= =0A= Note that the above is about a public Internet access model; or even a priv= ate/carrier model but for the providers/Enterprises/whatever that don't hav= e local copies and instead query the CIDER Registry and rely on simple DNS = caches.=0A= =0A= For the regulated carrier scenarios, regardless of whether it's in The Publ= ic DNS or only available in a private manner, the carriers would get local = synchronized copies of the whole thing - at least for their country-code br= anch, for example. For that scenario, their synch connection to the master= would be secure so not need DNSSEC, and it would use some synch protocol (= sub/pub or whatever) so the TTLs we're talking about don't apply to their c= opy.=0A= =0A= For international caller-id validation - which probably wouldn't be in the = carrier's local DB copies for various reasons - if the foreign country has = a restricted-access model then the carriers' local DBs would either recursi= vely resolve through pre-agreed connections, or use the master CIDER Regist= ry and it would do it with pre-agreed connections. That stuff is flexible = and based on how other countries want to deploy, and how the local country = handles it.=0A= =0A= In none of those cases do you need CRL lists or OCSP. The protocol's mecha= nics clears the old ones out, either through TTLs or sub/pub; and the CIDER= Registry (the logical equivalent of the root CA for certs) can keep its si= gnature expiry short and keep re-signing without involving anyone else.=0A= =0A= BTW, I'm not saying this is a huge deal - it's just one of the benefits of = DNS is all.=0A= (well... I guess it could be a big deal, if the alternative is putting the = HTTP URL in the SIP message a la rfc4474)=0A= =0A= -hadriel=0A= =0A= =0A= On Jul 20, 2013, at 6:14 PM, Henning Schulzrinne wrote:=0A= =0A= > If TTLs are short (below a few hours), essentially every query will be an= swered by the authoritative server in the DNS model, since legitimate calls= don't have much locality, from what I can tell.=0A= >=0A= > ________________________________________=0A= > From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Hadriel = Kaplan [hadriel.kaplan@oracle.com]=0A= > Sent: Saturday, July 20, 2013 1:04 AM=0A= > To: Cullen Jennings=0A= > Cc: stir@ietf.org Mail List=0A= > Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model= =0A= >=0A= > Nope, I don't think porting numbers requires a cert revocation or anythin= g logically equivalent. As long as it ages out within a few months, I thin= k it would be fine. (though as an aside, I still think CIDER DNS TTLs shoul= d be short, but not for this reason)=0A= >=0A= > -hadriel=0A= >=0A= > _______________________________________________=0A= > stir mailing list=0A= > stir@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/stir=0A= > _______________________________________________=0A= > stir mailing list=0A= > stir@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/stir=0A= =0A= From hadriel.kaplan@oracle.com Sat Jul 20 17:13: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 7065F21F9FFC for ; Sat, 20 Jul 2013 17:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0OnvBi7hJSZ for ; Sat, 20 Jul 2013 17:13:31 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9D32321E8088 for ; Sat, 20 Jul 2013 17:13: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 r6L0DLkN016932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 21 Jul 2013 00:13:22 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 r6L0DKj0019992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Jul 2013 00:13:21 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 r6L0DKlY019989; Sun, 21 Jul 2013 00:13:20 GMT Received: from [192.168.2.7] (/184.61.127.93) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 20 Jul 2013 17:13: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: Sat, 20 Jul 2013 20:13:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! ! ! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> , <6642171F-7D32-408F-844B-21727086DC85@oracle.com> , To: Henning Schulzrinne X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "stir@ietf.org Mail List" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 21 Jul 2013 00:13:37 -0000 On Jul 20, 2013, at 7:20 PM, Henning Schulzrinne = wrote: > I don't see the "benefit" of DNS here. There are two cases, either = way: >=20 > (1) A standard DNS hierarchy, with caching, but no synchronization. In = that case, you need short TTLs if you care about revocation. With short = TTLs, you get one country-level RTT for every query, even assuming no = packet loss. By "one country-level RTT for every query", do you mean you get one RTT = on average for every call, and the RTT is likely not long on average = because it's to a server in your geographic country? If so, sure that = would likely be the case for public internet access queriers. One RTT = on average, for a public Internet access model is pretty good, BTW. = HTTP really won't have one RTT for such public Internet access, not in = actual practice if this Identity-Info URL model is used. Again, this is = not CIDER's raison d'etre, but just another plus. > (2) A locally-cached synchronized DNS hierarchy, using some kind of = rsync-like mechanism. >=20 > You can get the same two versions for HTTP and certs. No, I really don't believe you can. You can get them if we give up on = the Identity-Info URL thing, and define how HTTP would work without it, = how the international call thing works, and so on. But not if the cert = is served on some random server indicated by the Identity-Info header. > The locally-cached synchronized DNS has essentially the same overhead = as the locally-cached HTTP version, since the connection is nailed down. Define "overhead". Overhead for whom? For the verifier systems HTTP is = more overhead - a trivial amount if the stars align, and more if reality = is included in the equation; but not a massive amount regardless. For = the carriers, HTTP is more cost and operational overhead from a = deployment perspective if reality is included, but again if we ignore = practical realties then it's all equal. So sure, if all carriers in all = nations deploy Google or Facebook style infrastructures and tweak their = verifiers' TCP and HTTP implementations - all for the benefit of = verifying a caller-id - then we're all good-to-go. ;) -hadriel From hadriel.kaplan@oracle.com Sun Jul 21 08:50: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 9305021E8095 for ; Sun, 21 Jul 2013 08:50:30 -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 kh7zB6nh9j51 for ; Sun, 21 Jul 2013 08:50:25 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 049A221E8090 for ; Sun, 21 Jul 2013 08:50: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 r6LFoK5g028531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 21 Jul 2013 15:50:21 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 r6LFoI5g015473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Jul 2013 15:50:19 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 r6LFoHJ4015463; Sun, 21 Jul 2013 15:50:18 GMT Received: from [192.168.2.7] (/184.61.127.93) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 21 Jul 2013 08:50: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: Sun, 21 Jul 2013 11:50:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <04608538-7A05-4F63-AC8F-E9BC63149A01@oracle.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! ! ! ! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> , <6642171F-7D32-408F-844B-21727086DC85@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 Mail List" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 21 Jul 2013 15:50:31 -0000 I've been thinking about your questions and it occurred to me we may be = talking past each other, or I'm not being clear enough. It's hard to = discuss some of this stuff in email, but anyway let me try a different = tack... So far, there is one relatively concrete proposal for how HTTP would be = used: RFC4474 or 4474bis, which use certs signed by someone, and = indicates where to get the cert in an HTTP URL encoded in the SIP = message Identity-Info header. That model has a whole host of issues, = and if by "HTTP" you mean that model, then we could drill-down on the = practical problems I believe it would have. There is another way it could work using HTTP, which is essentially to = copy the CIDER proposal but replace the DNS query-answer with HTTP = query-answer. The verifier would generate its own HTTP URL to resolve, = based on the received identity information in SIP, and we'd define how = it does that, what the cert model and encoding would be, how it gets = secured redirection, how it times out cached copies, how to get the cert = signer's cert, how to time that out, etc. Let's call such a model "HARD = CIDER", for "Http-based Access of Registry Data" or some such.[1] For a Hard Cider model to be used in a public Internet access model, = we'd still be relying on DNS and DNSSEC, to perform resolution of the = HTTP URL in a secure manner. And using a generated HTTP URL implies the = national registries are deployed as a Google/Facebook/Amazon type cloudy = infrastructure with internal horizontal scaling technologies, etc. But = let's ignore that for now. The bigger problem is the target user environment: where we expect to be = using this stuff, in carriers. In practice, HTTP isn't frequently used = by real-time call-handling network devices in most carriers. It is used = by the carrier as a corporation of course, in various other = areas/groups/functions; and it's used in some call-control cases, = usually by application servers providing features for specific users or = calls, in specific scenarios. It's far less common to have it used for = every call, and essentially never gets used by SBCs or X-CSCFs on an = every-call basis. There are a variety of practical reasons for that, = but it doesn't really matter why. What matters is it would be a barrier = to deployability and adoption, in the real world, if we chose it. Arguably, DIAMETER is a far more common protocol for many carriers to = use for this type of stuff than HTTP or even DNS. DIAMETER has its own = challenges in actual carrier deployments, mostly around scalability and = manageability, but we couldn't pick DIAMETER anyway because it's only = used in some carriers and not all carriers, and rarely used by anyone = else. As a protocol, DNS happens to be used by everyone - it's only used as = private ENUM by some carriers not all obviously, but virtually all of = them use DNS for at least hostname resolution, even internally. And DNS = client implementation happens to be available in code in all systems, = whether it be SBCs or X-CSCFs or app servers or whatever; and its = performance, scalability and manageability characteristics happen to be = really good in actual carrier deployments. Having said all that, another way we could go in STIR is to just hedge = our bets and define multiple protocols: DNS, HTTP, and maybe even = DIAMETER. To do that, though, it still has to be deployable as DNS, = still have to be based on the verifier generating the URL and not have = it sent by the originator, still have to specify the caching and = clearing behavior, still have to support both a centralized and = distributed model of database deployment for numbers, etc. We've done = that sort of hedging before in the IETF, rarely - it's a LOT more work, = obviously, but it lets the market decide for itself what to do. If we do hedge our bets, however, I believe the most straight-forward = way to actually do that would be to define the DNS one *first*, and then = figure out the HTTP or DIAMETER mechanics required for doing the same = things accessing stuff from a deployed DNS database infrastructure. = That's because DNS as a protocol already defines the semantics, = mechanics, and database structure; and if its used in a public Internet = access manner then it's The Public DNS. So a use of HTTP or DIAMETER = would need to access it and follow its behavior. And that has some = bizarre deployment expectations for all parties, for example for = international call scenarios, or for an email-style identity model. A more reasonable approach might be to define the DNS model, and then = only define how an HTTP or DIAMETER access to the local DNS resolver = could also work, where the verifier can only be a stub. That's still a = lot of work, and still involves localhost caching rules and such, but at = least it constrains the problem somewhat. -hadriel [1] I don't use the term "hard" to mean it will be hard, but rather = because "hard cider" happens to be a specific form of the drink known as = cider. :) On Jul 20, 2013, at 8:13 PM, Hadriel Kaplan = wrote: >=20 > On Jul 20, 2013, at 7:20 PM, Henning Schulzrinne = wrote: >=20 >> I don't see the "benefit" of DNS here. There are two cases, either = way: >>=20 >> (1) A standard DNS hierarchy, with caching, but no synchronization. = In that case, you need short TTLs if you care about revocation. With = short TTLs, you get one country-level RTT for every query, even assuming = no packet loss. >=20 > By "one country-level RTT for every query", do you mean you get one = RTT on average for every call, and the RTT is likely not long on average = because it's to a server in your geographic country? If so, sure that = would likely be the case for public internet access queriers. One RTT = on average, for a public Internet access model is pretty good, BTW. = HTTP really won't have one RTT for such public Internet access, not in = actual practice if this Identity-Info URL model is used. Again, this is = not CIDER's raison d'etre, but just another plus. >=20 >=20 >> (2) A locally-cached synchronized DNS hierarchy, using some kind of = rsync-like mechanism. >>=20 >> You can get the same two versions for HTTP and certs. >=20 > No, I really don't believe you can. You can get them if we give up on = the Identity-Info URL thing, and define how HTTP would work without it, = how the international call thing works, and so on. But not if the cert = is served on some random server indicated by the Identity-Info header. >=20 >=20 >> The locally-cached synchronized DNS has essentially the same overhead = as the locally-cached HTTP version, since the connection is nailed down. >=20 > Define "overhead". Overhead for whom? For the verifier systems HTTP = is more overhead - a trivial amount if the stars align, and more if = reality is included in the equation; but not a massive amount = regardless. For the carriers, HTTP is more cost and operational = overhead from a deployment perspective if reality is included, but again = if we ignore practical realties then it's all equal. So sure, if all = carriers in all nations deploy Google or Facebook style infrastructures = and tweak their verifiers' TCP and HTTP implementations - all for the = benefit of verifying a caller-id - then we're all good-to-go. ;) >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From philippe.fouquart@orange.com Mon Jul 22 00:59: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 D8CEE21F9E7E for ; Mon, 22 Jul 2013 00:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.108, 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 AJMzaDqhcjyQ for ; Mon, 22 Jul 2013 00:59:22 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id C0CC621F8FDC for ; Mon, 22 Jul 2013 00:58:01 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id CDE262648CF; Mon, 22 Jul 2013 09:56:44 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id AE09723804B; Mon, 22 Jul 2013 09:56: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; Mon, 22 Jul 2013 09:56:44 +0200 From: To: "dcrocker@bbiw.net" , Russ Housley Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIC/Xfx9OM2CUaqk2gsBTAQDJlfoXKAgAAEgQCAAANtAIAAAaIAgAAGyICAAAH7AIAABkaAgAACpACAAA3sAIAAAhCAgADroICAAEL+gIAAAeAAgABhRACAAB8HgIAADPeAgAAKzoCABhDlgIAF3D8AgALe0wA= Date: Mon, 22 Jul 2013 07:56:43 +0000 Message-ID: <9757_1374479804_51ECE5BC_9757_151_1_B5939C6860701C49AA39C5DA5189448B0B5151@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> <51EA95D4.905@dcrocker.net> In-Reply-To: <51EA95D4.905@dcrocker.net> 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: IETF STIR Mail List Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 22 Jul 2013 07:59:35 -0000 > You are correct, and several people agreed with you. However, none of yo= u offered text.=20=20 (Not wanting to reopen the loop) Actually, Henning proposed some language a= nd I, being one of those who struggled with authorization, was fine with it= . But I can live with the latest text on this particular point. (http://www.ietf.org/mail-archive/web/stir/current/msg00911.html) 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 Dav= e Crocker Sent: Saturday, July 20, 2013 3:51 PM To: Russ Housley Cc: IETF STIR Mail List Subject: Re: [stir] Draft STIR Charter On 7/16/2013 9:21 PM, Russ Housley wrote: > Dave: > >> Meta-point: >> >> The text is only about authentication, but the discussion has been = about authorization. For example one might have an authenticated originato= r value that is not the string displayed as Caller-ID.[*] I understood the= purpose of the wg to be ensuring that the displayed string was authorized = by its assignee. >> >> If no one cares about this distinction and everyone feels that "aut= henticate the originator" is sufficiently precise and accurate, fine, but I= thought it worth making sure. > > You are correct, and several people agreed with you. However, none of yo= u offered text. So, I have made a stab at updating the charter text to add= ress this point. I'll post it in a minute. Russ, to close the loop on this: 1. The latest draft's vocabulary changes about this look good to me.=20 Thanks for doing that. 2. I didn't offer wording changes because I felt tenuous enough about=20 the issue that I wanted to ask about the issue in the abstract, before=20 worrying about the wording. It's clear to me that there is a legitimate debate one might have=20 between the two vocabulary choices of authentication vs. authorization,=20 apparently even among folks with long-standing security backgrounds=20 (thereby excluding me). (I was impressed to discover that RFC 4949 does=20 list authorization as a vocabulary term! Does that mean the AAA folks=20 have to become only AA?) >> Consideration of out-of-band mechanisms, to deal with transit acros= s non-SIP hops, is deferred. > > I do not see consensus for this position. It is agree that an end-to-end= SIP session is the first priority. However, others have said that an out-= of-band solution is also needed to address the whole problem. This is the = second priority, and the charter text that I will propose says: The latest language about this in the draft charter, and schedule you=20 show in it, is workable I think. That said, I think Hadriel has reminded us of an important point: A=20 draft charter beings as a blank sheet of paper. There are no rights=20 that accrue to whatever the first draft contained. Everything in the=20 charter needs to represent a reasonable consensus amongst those who will=20 do the work (as well as the IESG), even though there's no working group=20 to do a formal consensus process. My own reading of the list, about out-of-band, is that while it might=20 not have clear rough consensus to take it out of the charter, I don't=20 see anything close to a clear consensus to keep it in, either... d/ --=20 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, 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 Mon Jul 22 01:04: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 A42F421F8415 for ; Mon, 22 Jul 2013 01:04:12 -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 HG0Ho0Jt60WK for ; Mon, 22 Jul 2013 01:04: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 8A6B221F826B for ; Mon, 22 Jul 2013 01:04:04 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id D582B325376; Mon, 22 Jul 2013 10:04:02 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id B5A6627C054; Mon, 22 Jul 2013 10:04:02 +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, 22 Jul 2013 10:04:02 +0200 From: To: Stephen Kent , "stir@ietf.org" Thread-Topic: [stir] Draft STIR Charter Thread-Index: AQHOfkIC/Xfx9OM2CUaqk2gsBTAQDJlfoXKAgAAEgQCAAANtAIAAAaIAgAAGyICAAAH7AIAABkaAgAACpACAAA3sAIAAAhCAgADroICAAEL+gIAAAeAAgABhRACAAB8HgIAADPeAgAAKzoCABGLzgIAAA5aAgAAHEQCAAPRtYIAAVVgAgAkXkHA= Date: Mon, 22 Jul 2013 08:04:01 +0000 Message-ID: <380_1374480242_51ECE772_380_10528_1_B5939C6860701C49AA39C5DA5189448B0B5165@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> <3145728A-87FA-4217-9B93-E14A01307784@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC16DAD@EX2K10MB1.corp.yaanatech.com> <21393_1373964969_51E50AA9_21393_2845_1_B5939C6860701C49AA39C5DA5189448B0B4651@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51E5603C.6010904@bbn.com> In-Reply-To: <51E5603C.6010904@bbn.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.22.74241 Subject: Re: [stir] Draft STIR Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 22 Jul 2013 08:04:16 -0000 Thanks Steve. As I said, I was more concerned about the use of this term gi= ven the context than about its general acception, but the recently proposed= text is fine. (and thanks for the pointer. I wasn't aware of that one)=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 Ste= phen Kent Sent: Tuesday, July 16, 2013 5:01 PM To: stir@ietf.org Subject: Re: [stir] Draft STIR Charter Phillipe, > Charter-wise I would also prefer this phrasing than referring to authenti= cation or "authenticate the originator of a SIP session". From a security terminology perspective, authentication is an=20 appropriate term. For example, RFC 4949 (Internet Security Glossary, v2) defines the term as follows: authenticate (I) Verify (i.e., establish the truth of) an attribute value claimed by or for a system entity or system resource. So, in this context, verifying that the TN asserted by a caller is=20 accurate is a reasonable use of the term. >> "is the caller entitled to use the telephone number in the callerID info= rmation" > Given the context, however, I'm with Dave's "meta point" on this. Using a= uthentication would be confusing for me (mostly because of what the term co= nveys with regard to the network the sip user is registered with): > a) such authentication is generally carried out to provide a service to t= he subscriber with the TN, here the calling party, more rarely the called p= arty; and > b) it implies that the primary piece of information with which you identi= fy the user is indeed the TN, whereas as a rule, [not all but] a large numb= er of networks (SIP-based and others) generally try and separate what you i= dentify/authenticate users with and what other users employ (the TNs) to se= t up a session/call with them - ie precisely try and not use TNs for the pu= rpose of identification/authentication. > Whether a TN or some other form of identifier may be authenticated in=20 the proposed system has a lot to do with who is providing the assertion about the ID. If=20 there is one thing we have learned from the browser trust anchor mess, it's that allowing a=20 third party to make assertions about identities for which it is not authoritative, is a=20 very, very bad idea. That's why. in the RPKI context, the certs are issued only by entities=20 that are authoritative for the resources for which they vouch, and the names that appear in=20 these certs are, intentionally, not human meaningful. Steve _______________________________________________ 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 dhc@dcrocker.net Mon Jul 22 01:34: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 8479E21F965B for ; Mon, 22 Jul 2013 01:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7PrGms-APu4 for ; Mon, 22 Jul 2013 01:33:42 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1F95321E80A1 for ; Mon, 22 Jul 2013 01:10:44 -0700 (PDT) Received: from [192.168.0.83] (host-212-159-176-45.static.as13285.net [212.159.176.45]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r6M8AQBv012124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 22 Jul 2013 01:10:31 -0700 Message-ID: <51ECE8F1.1090508@dcrocker.net> Date: Mon, 22 Jul 2013 09:10:25 +0100 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 Mail List" References: <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! ! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> , <6642171F-7D32-408F-844B-21727086DC85@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]); Mon, 22 Jul 2013 01:10:32 -0700 (PDT) Subject: Re: [stir] CA Certs 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, 22 Jul 2013 08:34:53 -0000 >> If TTLs are short (below a few hours), essentially every query will >> be answered by the authoritative server in the DNS model, since >> legitimate calls don't have much locality, from what I can tell. > > By "authoritative" servers if you mean the CIDER Registry's DNS > servers, sure that could be the case. ... And DNS querying > is fairly light-weight and fast, so timing out a cache and > re-querying isn't a big deal. The nice thing is the TTLs for the > parent nodes (i.e., the branches of the tree representing the > prefixes) can be longer TTLs,... Right. So... The DKIM model is a small enhancement over the original work done by Mark Delany, then at Yahoo, for DomainKeys. It offered the basic innovation of putting public keys directly into the DNS, using the location in the DNS namespace as the de facto cert. I asked him what drove this design choice. His thoughtful response: > There were a number of factors in choosing the DNS model over the CA > approach. > > 1. Control. Key revocation and management is entirely in the control > of the domain owner. We see the mess with revocation in the CA > world. The lag and the lookup imposition just to name two issues. At > high volume this sort of approach is a performance disaster. > > > 2. Cost. DNS records are free. Certs cost money. no news there, but we > were very keen that adoption be as easy as possible and a zero-cost > "cert" is pretty attractive. People say certs are cheap, but they > mostly live in that uncommon place, a first-world country. > > Frankly the CA business model is not well aligned with the security > benefits of certs. It wouldn't surprise me if CAs would want to do the > same IP/Domain binding and premium pricing for wildcard certs that > they do in the HTTP space. > > Note that it never made it into DKIM, but early DomainKeys specs also > hinted at advertising per-user keys in DNS. That is a real cost-saver > and allows cheap peer-to-peer authentication - something I would think > SIP would like to do. > > > 3. Security. With the now common knowledge that TLS is interceptable > with participating CAs, one has to question the whole security premise > of a CA model. > > > 4. Flexibility. You can change your DNS at a whim. Need to change key > lengths, or algorithms in a hurry? Need to spin up a new domain? Try > that with a CA. > > > 5. Orthogonality of trust. Dunno whether this is relevant to your SIP > scenario, but the - always dubious - notion that CAs "assert" who you > are was removed from the equation so that market forces could provide > whatever was needed. One example might be DMARC in the email space. > > Having done the "assertion" dance for certs for non-US entities, I > know the process is largely a farce. > > 6. Adaptation. We were of the belief that such keys could be trivially > extended to other protocols, such as jabber and SIP, with little or no > change (Yahoo Messenger interop with 3rd-parties in particular was a > hot issue back then). I think the earlier specs had various attempts > at codifying exactly how that would work, but not a lot of effort went > into this in the WG. For STIR, I believe the only interesting design risk in a DNS-based approach is whether a DNS namespace can be adequately defined and administered, to match the needs of the STIR function. In terms of any other operational concerns of the approach, DKIM provides a large-scale, multi-administration equivalence existence proof. It covers at least 60% of all email traffic on the net. I believe there is no operational equivalent any other technical approach; if that's not correct, it would help to hear about a global authentication mechanism that supports an equivalent scale of /independent/ (multi-administration) identifier authorizations. The view that creating, deploying and perhaps later modifying the design of a CA-based global infrastructure will be straightforward does not match anything I have ever heard about CA administration and operation, at scale. Creating any global infrastructure is typically a very high risk activity, but CAs have had an especially rocky, long-term history. It would be extremely helpful to see some documentation that demonstrates that that path is lower risk than simply adding some more names and records to the DNS. In terms of public-vs-private operation, the notes that are getting posted on this list seem to vary between a goal of public access and a goal of private access (restricted to a privileged few operators.) The scaling and operational complexity differences between these two operating modes is, of course, fundamental. So it it be helpful to stabilize this requirement for STIR and then be consistent about referring to it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From york@isoc.org Mon Jul 22 05:35: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 237AB21E8089 for ; Mon, 22 Jul 2013 05:35:06 -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 zfyN4txQODW4 for ; Mon, 22 Jul 2013 05:34:59 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by ietfa.amsl.com (Postfix) with ESMTP id 99D1421E8087 for ; Mon, 22 Jul 2013 05:34:58 -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.731.12; Mon, 22 Jul 2013 12:34:51 +0000 Received: from BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.198]) by BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.185]) with mapi id 15.00.0731.000; Mon, 22 Jul 2013 12:34:50 +0000 From: Dan York To: "" Thread-Topic: [stir] CA Certs Thread-Index: AQHOhrZn70bU8Zwx80aL9Nd2hyd985lwokod Date: Mon, 22 Jul 2013 12:34:50 +0000 Message-ID: <582B387D-AB5B-482D-94BB-46F281E77AB6@isoc.org> References: <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! ! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> , <6642171F-7D32-408F-844B-21727086DC85@oracle.com> , <51ECE8F1.1090508@dcrocker.net> In-Reply-To: <51ECE8F1.1090508@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.228.192.171] x-forefront-prvs: 0915875B28 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(377454003)(24454002)(81542001)(77096001)(47976001)(54316002)(49866001)(74706001)(76796001)(74662001)(53806001)(51856001)(63696002)(31966008)(74502001)(19580395003)(74876001)(4396001)(81342001)(59766001)(46102001)(83322001)(76482001)(47446002)(19580405001)(36756003)(66066001)(77982001)(50986001)(80022001)(33656001)(56776001)(47736001)(83072001)(56816003)(76786001)(65816001)(54356001)(79102001)(74366001)(16406001)(69226001)(491001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB065; H:BLUPR06MB067.namprd06.prod.outlook.com; CLIP:198.228.192.171; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org Cc: "stir@ietf.org Mail List" Subject: Re: [stir] CA Certs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 22 Jul 2013 12:35:06 -0000 Dave,=20 On Jul 22, 2013, at 4:35 AM, "Dave Crocker" wrote: > The DKIM model is a small enhancement over the original work done by Mark= Delany, then at Yahoo, for DomainKeys. It offered the basic innovation of= putting public keys directly into the DNS, using the location in the DNS n= amespace as the de facto cert. I asked him what drove this design choice. Very good responses. Thank you for requesting and sharing this feedback.=20 > In terms of public-vs-private operation, the notes that are getting poste= d on this list seem to vary between a goal of public access and a goal of p= rivate access (restricted to a privileged few operators.) The scaling and = operational complexity differences between these two operating modes is, of= course, fundamental. So it it be helpful to stabilize this requirement fo= r STIR and then be consistent about referring to it. While I agree that stabilizing the requirement could be helpful, I would al= so note that as Hadriel mentioned, a benefit of a DNS-based approach is tha= t we don't really have to decide on the public-vs-private aspect right now.= We can construct a system that can be used publicly - and then later if pe= ople want to use it on private networks they an do so. (Although in writing= this I realize that I am effectively indicating the initial requirement sh= ould be "public".) Dan= From michael.hammer@yaanatech.com Mon Jul 22 07:07: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 D057D21E808C for ; Mon, 22 Jul 2013 07:07:18 -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 NBcLLkZOXqFi for ; Mon, 22 Jul 2013 07:07: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 5C4C221F99B0 for ; Mon, 22 Jul 2013 07:07:12 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Mon, 22 Jul 2013 07:07:11 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) Thread-Index: AQHOgvzGoW2Sqvrxc0GEvdoogk5ro5lpa5QAgAAoCgCAAe3VAIAAA5sAgAEbyACAABl1gP//jBDQgACJywD//6q3gIAA/xKAgANB3HA= Date: Mon, 22 Jul 2013 14:07:09 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC1A1BD@EX2K10MB1.corp.yaanatech.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! ! ! ! ! ! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> <84432CF7-A220-46F0-B945-F41F09F7061E@oracle.com> , <1E1AA91D-F3C8-4B43-A647-F898B9AB9778@oracle.com> <825EFE8B-555B-47EC-AF5D-55755C2439D5@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC19C60@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC19DAC@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.71] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0038_01CE86C3.39D072F0" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 14:07:18 -0000 ------=_NextPart_000_0038_01CE86C3.39D072F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi. Thanks for the detailed explanation. One detail that I think you are overlooking is that most calls are between individual that know each other. So, there is advantage in the end system caching the information that allows it to validate a call. Whether that is a cert or a DNS CID key would not be much different, except that, as you note, the DNS cache will likely be lost often. We should design for the majority of cases, not the smaller number of unknown callers. I was thinking that there could be a SIP 1xx series error code whereby the called party could tell the sender it needs a new cert. (That could trigger a display to the user of "Unknown new caller begin verified".) That could also be a point where a DNS cache could be queried as well. There could be an UPDATE message then sent to provide the cert for that call ID. Another detail that you may have some cognitive dissonance on is that the security of the cert or the DNS entry is not secured by the caching system that delivered it to the called party, but by the fact that the signature of a well-known administrator cannot be spoofed. For DNS, garbage in = garbage out. You have proven that a bad CID key can be securely distributed. My concern is about the root source of the CID key. "Even if the DNS admin's DNS Key is compromised, they can change it and re-sign without having to have the Assignees do anything." This is false. You would need to know what Text RRs were signed by that key, invalidate all those CID keys, reissue new public/private key pairs, then sign a new Text RR for however many that was. Problem is there is probably no audit as to what was signed. At least with a cert, you know what admin key signed a cert and can check any that you have to flush out both the admin cert as well as the certs that it signed. Your rfc4474 paragraph applies for both solutions as a compromised end-user private key doesn't even need a URL, just the DNS cache. But, at least in those cases, that is the end-user's bad. Hope that helps, Mike -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Saturday, July 20, 2013 12:55 AM To: Michael Hammer Cc: stir@ietf.org Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) On Jul 19, 2013, at 5:33 PM, Michael Hammer wrote: >>> I read your CIDER draft, but am trying to draw out the salient >>> points on > where the chain of trust lies and what is really different. Maybe I > am missing some key point about what is securing the DNS entry and > what is in that entry that needs to be secured and how that relates to > the key used to sign the SIP header element. Right, so the basic gist is the private key used to sign SIP request caller-ids with, has its public key counterpart in a DNS TXT RR. It may be The Public DNS, or it may be a controlled-access private or federated one. Regardless, the public key remains in a DNS, and it's retrieved by the verifier using the DNS protocol. Let's call that public key the "CID Key", for Caller-ID key. Let's call the entity who uploaded the CID Key into DNS the "Assignee". The DNS TTL for the entry is likely quite short... say 30 minutes or even less. Thus DNS caches will time it out in 30 minutes. There's not much point in caching them longer, because it's rare for source call numbers to be used frequently enough to make it worth caching for longer. Even for those that are "worth it", a DNS query every 30 minutes for the frequent ones isn't a big deal. It might be a lot shorter TTL even, but that's all up to the admin to decide anyway. That TTL actually has nothing to do with how long a DNSSEC signature is valid for, but it's useful to keep the TTL short purely to force DNS caches to flush and check DNS again. >From a DNSSEC perspective, what's securing the DNS entry is a signature, using a private key of the admin, with the public key also being available in DNS. There's actually a chained signing model for DNS subdomain hierarchies, but in our case you can skip it so long as the public key value matches the country-code's, so I'll ignore it for now. Fundamentally, it's essentially the same concept as what you described: having all certs signed by the country-code admin. In this case, all the TXT RRs are signed by the country-code admin. Let's call the DNS admin's public key the "DNS Key", and call the signature of the TXT RR (containing the CID Key) a "RR Signature". The RR Signature is sent back in a resource record along with the TXT RR, in the same DNS answer packet, when you query DNS for the TXT RR. So it's similar to a cert when DNS is queried/answered, but there's no point in giving a "cert" back to the Assignee, because it serves no purpose. No one gets a "cert" from the Assignee - they get it from DNS. Because they can get it from DNS, the DNS admin can actually set the RR Signature expiry time to be relatively short. Let's say one week. They can do that because they can re-sign the TXT RR (generate a new RR Signature) without communicating that change to the Assignee at all. The Assignee never has to upload a fresh CID key again, until their key is compromised or their E.164 number ports out. Meanwhile the DNS admin can re-sign again and again. Even if the DNS admin's DNS Key is compromised, they can change it and re-sign without having to have the Assignees do anything. If the Assignee's CID key is compromised, the Assignee uploads a new CID Key to the DNS admin, replacing the old one. TTL expiry cleans out the old caches, triggering a fresh query to the DNS. Thus we don't need revocations. For those concerned with DNS injection attacks using a compromised key, or broken caches holding on to old DNS answers using a compromised DNS Key, the RR Signature itself only lasts a week. I should mention that the CIDER draft currently expects the STIR verifier systems to be client stub resolvers. In other words, the SIP system performing STIR verification wouldn't actually do the DNS tree walking or DNSSEC validation; their local DNS servers would do it on their behalf. >From a security perspective it means the verifier needs to trust its local DNS resolvers, but for the STIR use-case that seems reasonable. The benefit being that you can basically off-load the work, use a private or federated DNS model, and so that a carrier can use specialized systems or rules to do that stuff if they want to. (such systems already exist for private ENUM use today, for similar call-signaling purposes, though they don't use DNSSEC) I also expect there to be local actual copies of the entire DNS tree for a country-code; for example large US carriers would likely have a local copy for all US numbers; Canadian carriers for Canada numbers; etc. Their local copy is not authoritative, but it's a slave synchronizing stuff from the master run by the country-code admin or a commonly-agreed-upon admin. That's what happens today in NPAC, for example. Smaller carriers, or non-regulated providers, or Enterprises, or whatever - they can just access the master using DNS, or through their upstream carrier, or a third party middleman. The reason I mention this is that these local copies don't need to deal with DNSSEC at all - they have a synchronized copy of the master over some secure channel, so the DNSSEC stuff isn't necessary for their local copy. The reason that the last part is different for certs, is that so far the proposals for using certs has been based on rfc4474: that the caller identifies the HTTP URL to go get the cert from, by putting the URL in the SIP message in the Identity-Info header field. That means if an E.164 cert private key is compromised, it's trivial to abuse it - just generate a SIP INVITE with your own HTTP URL to your site holding the original cert, and use the compromised private kay to sign the INVITE. That's why we'd need cert revocations. We couldn't even have short expiries for the certs, of anything like a week long for example, because it would require getting a new cert up to the country-code admin to be re-signed every week. But with DNS, it's not trivial to use a compromised CID Key: the DNS entry would be changed, and quickly take effect. So we wouldn't need actual revocations. -hadriel p.s. I didn't mean to spend so much time or focus on the cert revocation aspect for using CIDER - avoiding revocations isn't really the major benefit of using CIDER. There are many more benefits to using CIDER. Right now I'm just trying to figure out what the drawbacks/downsides to it are, and where/if it would break or be less practical than alternatives. (for me, the STIR thing is more about practicality for the target use-cases than anything else) ------=_NextPart_000_0038_01CE86C3.39D072F0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcy MjE0MDcwOFowIwYJKoZIhvcNAQkEMRYEFMrn2qEWORCWNdJg9tPLJsnW4je1MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEATOkD0yc26EYtgVMyqgRjadX6aYd5oDUL8Jir/Hzv Bqc2O1ibKsVjO9C8I58IjuVarVByyPa6rPDLhzxtWQ/R+ubGJf8fQaUnJjmqA++O5eiB5IzKvdyh RIU5bwF4I45E4cwSgK37k5uUcm8zUvoLMYVim7vd7T6ABVtjxm8czKtNt3+fBIxkfUhqp3kkAVoX ulJdslPKX+D6HCnh/1TJklr1R/GhLebOXQENRsJrnnL5R/8IHm8nuLnGJhX2UNmqHU/pDonOZGTW 0US495wAWCEUNUWnptHJMQCtPu2KGjVBtcUAjuug2Pxrh1oaZYb7+FEFL+nkli3SRim9dfesXgAA AAAAAA== ------=_NextPart_000_0038_01CE86C3.39D072F0-- From richard@shockey.us Mon Jul 22 07:16: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 5407011E80F5 for ; Mon, 22 Jul 2013 07:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.888 X-Spam-Level: X-Spam-Status: No, score=-101.888 tagged_above=-999 required=5 tests=[AWL=0.377, 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 dzuhmcyj2K7U for ; Mon, 22 Jul 2013 07:15:57 -0700 (PDT) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id C02E311E80AE for ; Mon, 22 Jul 2013 07:15:56 -0700 (PDT) Received: (qmail 21123 invoked by uid 0); 22 Jul 2013 14:15:34 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy13.unifiedlayer.com with SMTP; 22 Jul 2013 14:15: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=acQbDvXmgrM2LuMcVwoaN1Tdu+jJYE0nc0N/9adtRN4=; b=csHwIOTR23D419dutawf+xTmvlf0BJq8qbio4Lcqnp0fN52ICQcB5vzofHPVoRoYl48h8syMtUM2lmQDOxO0GQ5Bm9X4ViWaYFA4WSw6uUhg0JP1Rd/ZzNgEYrSxYMOs; Received: from [72.66.111.124] (port=49378 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V1Gti-0001T9-3Z; Mon, 22 Jul 2013 08:15:34 -0600 From: "Richard Shockey" To: "'DOLLY, MARTIN C'" , "'Cullen Jennings \(fluffy\)'" , "'IETF STIR Mail List'" References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> <457ED3A0-D8D1-4420-A2C3-5B07B16AE641@vigilsec.com> In-Reply-To: Date: Mon, 22 Jul 2013 10:15:31 -0400 Message-ID: <008e01ce86e5$ed693190$c83b94b0$@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: AQMHICSL0Ph6g4RQ+NeWd1GuIq7+jgID3l/wAmxQJugBDpVPmQF3LcagAw+9nYsCW3nj5wKITVPtAZLcFS8CJdWTNwD3PmWRAiSX2eEB8cq/eJY/c+Uw 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: 'Russ Housley' Subject: Re: [stir] Draft STIR Charter - 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: Mon, 22 Jul 2013 14:16:02 -0000 To Brother Marty's point folks have got to understand what Incumbent Carriers ILEC AND MSO's are capable of actually deploying given the existing infrastructure and capital constraints on all parties concerned. The end of the TDM/SS7 PSTN are upon us ... certainly in North America and the US in particular. IMHO any non DNS like in band solution will not deploy within carrier networks cached or otherwise if you believe, as I do that the carriers are an important part of the solution. There is a VAST amount of experience with cached DNS infrastructure in SIP/IMS networks for multiple applications LNP routing etc. There are LOTS of market binders here. If folks want to parallel out of band vs in band fine there may be some limited justification and use cases for this. I'm skeptical but I've been wrong in the past. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C Sent: Friday, July 19, 2013 8:52 PM To: Cullen Jennings (fluffy); IETF STIR Mail List Cc: Russ Housley Subject: Re: [stir] Draft STIR Charter - out of band What? Out of band before In band. What air are you breathing..... sorry fluf... you are off base on this... let's think economic deployable... To date I have been nice but you bring out the best, this has been a USA synergic discussion, no consideration to international, so IETF is going yield to the ITU.....a(xx) -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Cullen Jennings (fluffy) Sent: Friday, July 19, 2013 8:12 PM To: IETF STIR Mail List Cc: Russ Housley Subject: Re: [stir] Draft STIR Charter - out of band I'm listening to the arguments for in band or out of band but right now I am pretty skeptical that doing in-band before out-of-band is the right order. I suspect we need them both. Let me say a bit more Mobile phones could have done wideband audio long ago, but they did not. There was no incentive for them to do it since there was no alternative that could do do wideband and had the same mobility properties. Then along came smart phones and started providing much better audio quality using things like Skype. Suddenly there was an incentive to do wideband audio on mobile phones and you are starting to see that deploy. So lets talk about carrier to carrier SIP interconnects. Unless there is an real incentive, I sort of doubt that they will initially do a lot more than the SS7 interconnects they replace. No incentive and complicated to change the business agreements in place. Particularly for interconnects between say Nigeria and US. However, there is a great incentive for smartphones to implement an out of band solutions even it only works to other smartphones. Once that existed, there would be an incentive for non smart phones to get an equivalent level of service and that would most likely be done with a in band solution but at that point there is an incentive to deploy in band. A solution that only worked for smart phones is clearly not as useful as one that works for all phones, but doing both at the same time seems the most likely way to me to get either of them to deploy. Sure it would be better for the non over the top service providers if there was only a solution that worked for the carrier a telephone numbers was delegated down to form a nation level, but as apple showed with iMessage, it can be better for the users to have two ways to send a SMS messages to another user. One way that goes thought the provider that the phone number was delegated to, and one way that goes around the the carrier the phone number was delegated to. So, I'd like to see the charter changed to work on both in-band and out-of-band at the same time. On Jul 16, 2013, at 1:33 PM, Russ Housley wrote: > I have tried to pull all of the discussion into an updated charter. I have also attached a diff to make it easier to review. > > Russ > > > > = = = = = = = = = = > > > Name: Secure Telephone Identity Revisited (stir) > Area: RAI > > Chairs: TBD > Area Advisor: Richard Barnes > > Mailing list: stir@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/stir > > 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. As with email, the claimed source identity of a SIP > request is not verified, and this permits unauthorized use of source > identities as part of deceptive and coercive activities, such as > robocalling (bulk unsolicited commercial communications), vishing > (voicemail hacking, and impersonating banks) and swatting > (impersonating callers to emergency services to stimulate unwarranted > large scale law enforcement deployments). This working group will > define a deployable mechanism that verifies the authorization of the > calling party to use a particular telephone number. > > SIP is one of the main VoIP technologies used by parties that want to > present an incorrect origin, in this context an origin telephone number. > Several previous efforts have tried to secure the origins of SIP > communications, including RFC 3325, RFC 4474, and the VIPR working group. > To date, however, true validation of the source of SIP calls has not > seen any appreciable deployment. Several factors contributed to this > lack of success, including: failure of the problem to be seen as > critical at the time; lack of any technical means of producing a proof > of authority over telephone numbers; misalignment of the mechanisms > proposed by RFC 4474 with the complex deployment environment that has > emerged for SIP; lack of end-to-end SIP session establishment; and > inherent operational problems with a transitive trust model. To make > deployment of this solution more likely, consideration must be given > to latency, real-time performance, computational overhead, and > administrative overhead for the legitimate call source and all verifiers. > > As its first work item, the working group will specify a SIP > header-based authorization mechanism to verify the originator of a SIP > session is authorized to use the claimed source telephone number, > where the session is established with SIP end to end. This is called an in-band mechanism. > The mechanism will use a canonical telephone number representation > specified by the working group, including any mappings that might be > needed between the SIP header fields and the canonical telephone > number representation. The working group will consider choices for > protecting identity information and credentials used, but will likely > be based on a digital signature mechanism that covers a set of > information in the SIP header fields, and verification will employ a > credential that contains the public key and is associated with the one or more telephone numbers. > In order to be authoritative, credentials used with this mechanism > will be derived from existing telephone number assignment and > delegation models. That is, when a telephone number or range of > telephone numbers is delegated to an entity, relevant credentials will > be generated (or > modified) to reflect such delegation. The mechanism must allow > parties who are not delegated a telephone number, but are authorized > by the entity who is delegated the number, to place calls using the identity. > > After completing the in-band mechanism, the working group will > consider session establishment where there are one or more non-SIP > hops, most likely using an out-of-band authorization mechanism. > However, the in-band and the out-of-band mechanisms should share as > much in common as possible, especially the credentials. > > Expansion of the authorization mechanism to identities using the > user@domain form deferred since the main focus of the working group is > to develop a solution for telephone numbers. > > The working group will coordinate with the Security Area on credential > management. > > The working group will coordinate with other working groups in the RAI > Area regarding signaling through existing deployments. > > Authentication and authorization of identity is closely linked to > privacy, and these security features frequently come at the cost of > privacy. 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. > > 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 > > The working group will deliver the following: > > - A problem statement detailing the deployment environment and > situation that motivate work on secure telephone identity > > - A mechanism document describing the SIP end-to-end with telephone > number-based identities > > - A document describing the credentials required to support > telephone number identity authentication > > - A fallback mechanism to allow out-of-band identity establishment > during call setup > > Milestones > > Sep 2013 Submit problem statement for Informational > Nov 2013 Submit in-band mechanism for Proposed Standard > Feb 2014 Submit credential specification for Proposed Standard > Jun 2014 Submit fallback for Proposed Standard > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From philippe.fouquart@orange.com Mon Jul 22 09: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 2051621E80B0 for ; Mon, 22 Jul 2013 09:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, 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 6XwPs21ugVMi for ; Mon, 22 Jul 2013 09:13:05 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAE121E8093 for ; Mon, 22 Jul 2013 09:13:04 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 510702DC6DE; Mon, 22 Jul 2013 18:13:04 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 3322235C045; Mon, 22 Jul 2013 18:13:04 +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, 22 Jul 2013 18:13:03 +0200 From: To: Brian Rosen , Stephen Kent Thread-Topic: [stir] Rollout timeframe Thread-Index: AQHOgj0Oyp4iMmjcj0yEfylIBYT8bplnWHsAgAAIk4CAAAXGgIAAJ7UAgAFXlQCAAA1RAIAAPv6AgAAG34CAB6Gd0A== Date: Mon, 22 Jul 2013 16:13:03 +0000 Message-ID: <28284_1374509584_51ED5A10_28284_4180_1_B5939C6860701C49AA39C5DA5189448B0B5313@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <51E6BE72.8060500@bbn.com> <261BD146-4B2C-4528-ADF6-B7FE39F30B21@oracle.com> <51E6FE75 .4080908@bbn.com> <3B7C3493-2D1A-434F-9278-EE908107CB7A@brianrosen.net> In-Reply-To: <3B7C3493-2D1A-434F-9278-EE908107CB7A@brianrosen.net> 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.7.22.125137 Cc: "stir@ietf.org" , Hadriel Kaplan Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 16:13:10 -0000 More like 221 assigned E.164 CCs to date I think, plus half a dozen reserve= d but it obviously covers a large variety of situations in terms of assignm= ent models I'm not sure there's much to infer from that.=20 FWIW the figure of 68 countries out of 198 un member states was put forward= as having some form of NP (M/L/*) in a seminar last year. Haven't double c= hecked... just repeat it...=20=20 Indeed if there are already about 6 billion mobile phones, each of which ha= s at least one number, just add the landlines and other services on top of = this. For the SP, depends on how you define it. 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 Bri= an Rosen Sent: Wednesday, July 17, 2013 10:53 PM To: Stephen Kent Cc: stir@ietf.org; Hadriel Kaplan Subject: Re: [stir] Rollout timeframe We haven't agreed on a model for credentials yet, but some statistics: There are several billion telephone numbers. I think most experts believe = there are more assigned numbers than people.=20=20 There are 300-odd country codes There are a few tens of thousands of service providers. If enterprises get= some form of credential, there are potentially high tens of millions In the US, there are 500 million or so records in the portability database.= 15 minute ports for wireless numbers is the norm, and that includes distr= ibution of the update to the high hundreds or low thousands of copies of th= e database. It handles up to about a million transactions a day, not all o= f which are ports. Numbers that are assigned but not in the portability da= tabase are in ranges assigned to carriers. Brian On Jul 17, 2013, at 4:28 PM, Stephen Kent wrote: > Hadriel, >> Sorry about the name misspelling. :( >> Other comments inline... >>=20 >> On Jul 17, 2013, at 11:55 AM, Stephen Kent wrote: >>=20 >>>> But that would require a means of actually retrieving the correct cert= , walking the chain of signers, retrieving each of their certs, and checkin= g revocation lists. Meanwhile the caller has hung up the phone because it = didn't ring. :) >>> gee, and just when I had become fond of your concise, accurate descript= ion of what I was saying :-) ! Several things could make this potentially t= ime consuming process less onerous. >>> First, if carriers performed this checking for their called-party clien= ts, they could cache the cert and CRL data and perform the checks very quic= kly, during call setup, vouching for >> Maybe, maybe not - they can certainly cache the country-code one, and ev= en ones for the bigger/real carriers. It might or might not be practical t= o cache ones for all service providers, both the real ones and the unregula= ted ones (last time I checked, there are on the order of ~1000 of them in t= otal so far in the US, but its growing). >>=20 >> But I'm pretty sure it's impractical to cache them all if we really thin= k Enterprises would have their own cert as well. I'm not sure if it's real= istic to expect Enterprises to have certs, but the desire to support that h= as been raised for STIR, mostly so the Enterprise could then sign certs of = outsourced call-centers and remote branch offices I think. > In the RPKI context the plan is for every AS operator to acquire and cach= e all certs > CRLs, ROAs, etc. for every other other operator, and to check for changes= a few times per day. > There are about 35K network operators, world wide. Analysis of the time i= t takes to do this, > using servers in the Amazon cloud (in Tokyo and the US) to represent serv= ers and clients, > shows that this is really not a big deal in terms of bandwidth, time, sto= rage, etc. So, it would be useful to have some number to play with to get a= sense of how much bigger this system might be. >>> the caller ID info. Also, if the delegation chain is short, because it = extends only to carriers of record and all certs are issued by them, or by = national level authorities (as Henning suggested) then, this need not be a = slow process. >> Agreed, if there's only one CA signing everything, by definition it's no= t a long chain. :) >> I was more responding to the idea of having a cert signing chain, which = I thought was what people were talking about - that is what they were talki= ng about at some point. > It's not one CA, but maybe one per country, or two tiers of CA per countr= y, as per > Henning's model. But, that still makes of a very short chain. >>> When the cert path is short, one could send it via SIP, so no need to s= earch for the certs. >> Sadly we can't - doubling or tripling the SIP message size will make dep= loying it in the current infrastructure essentially untenable, from a pract= ical perspective. Or at least that's the premise folks stipulated when the = STIR discussion began, and I agree with it. > OK, I didn't see that assumption/assertion in the charter. >>> If revocation status checking is not a critical, realtime requirement, = as some others have suggested, then all the certs the called party needs wo= uld be in the header. (One could also consider sending OCSP responses to av= oid the need for CRL checking.) >> Yeah, I'm not sure whether revocation is important or not. I think it d= epends on how long a compromised key would be usable for. >>=20 > As I mentioned in a previous message, when designing a PKI it's important= to have a > model of the expected revocation rate when deciding on cert lifetimes. If= one has > good data on churn for a system prior to engineering a PKI, one can avoid= serious > mistakes. >=20 > Steve > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From jon.peterson@neustar.biz Mon Jul 22 10: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 CDC9D21F85BB for ; Mon, 22 Jul 2013 10:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.447 X-Spam-Level: X-Spam-Status: No, score=-103.447 tagged_above=-999 required=5 tests=[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 hBeC4pQC+qbA for ; Mon, 22 Jul 2013 10:18:22 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 6A93721F8424 for ; Mon, 22 Jul 2013 10:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1374514035; x=1689873910; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=RVSuLMLkzV 0rzQeBMMb2+22krw8t8aID1MRTUgzCYM4=; b=Kc5T2pNfDALHB9MHiWiGPMDdxC dH81eQQfeFIAJTYycTxnkAXyAIPF3DXcVCsvRgQKkYfqMv/w9Lh0n6Eb5zfw== Received: from ([10.31.58.70]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.28462703; Mon, 22 Jul 2013 13:27:14 -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, 22 Jul 2013 13:18:02 -0400 From: "Peterson, Jon" To: "dcrocker@bbiw.net" , "stir@ietf.org Mail List" Thread-Topic: [stir] CA Certs Thread-Index: AQHOhrZ4FNTiwdudT02BPFY99PNiDZlwvxoA Date: Mon, 22 Jul 2013 17:18:01 +0000 Message-ID: In-Reply-To: <51ECE8F1.1090508@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.149] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: YM1VLckIev055KbOGQ2biw== Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [stir] CA Certs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 22 Jul 2013 17:18:28 -0000 Personally, I still don't see much value in dragging this mailing list deep into a certs-versus-DNS debate. When I look at the web security world today, I see both certificates and the DNS playing a role, and I think we'd be best off we tried to leave the door open to both and see where the market takes us. I suspect certs are going to play a part in this, maybe not the only part, but a part. The "DNS is better than certs" arguments below, while they may have been persuasive arguments for DKIM, don't make me feel any less sure that certs are viable here. >> There were a number of factors in choosing the DNS model over the CA >> approach. >> >> 1. Control. Key revocation and management is entirely in the control >> of the domain owner. We see the mess with revocation in the CA >> world. The lag and the lookup imposition just to name two issues. At >> high volume this sort of approach is a performance disaster. True when it's clear who a "domain owner" is - in other words, when we're talking about DNS names that you go get from a DNS registrar. I mean, for DNS names, in many ways the DANE or DKIM approach is a no-brainer: if you already have a DNS name, and senders are going to resolve it in the course of protocol operation already, why not put keys in the DNS? But when we need to create a new DNS tree just for these newly-created names, and that tree is for use by the -recipient- of a communication who ordinarily wouldn't be invoking the DNS in the course of protocol operation, with very curious semantics for what constitutes a "domain owner", this argument isn't exactly persuasive. >> 2. Cost. DNS records are free. Certs cost money. no news there, but we >> were very keen that adoption be as easy as possible and a zero-cost >> "cert" is pretty attractive. People say certs are cheap, but they >> mostly live in that uncommon place, a first-world country. DNS records are free once you have a DNS name, but DNS names are not free. If you make it a requirement to use the DNS, then the cost for these names and records will be paid by someone, somewhere. Again, this is a persuasive motivating assumption for DANE or DKIM, where you just assume people already have a domain name, but here we're in a situation where the whole tree of names must be created in order to provide the function. There's no free lunch. >> Frankly the CA business model is not well aligned with the security >> benefits of certs. It wouldn't surprise me if CAs would want to do the >> same IP/Domain binding and premium pricing for wildcard certs that >> they do in the HTTP space. No lesser risk of that for the DNS than for certs, though I often do shudder when I contemplate how wildcarding-like functions would be provided in the DNS context. >> Note that it never made it into DKIM, but early DomainKeys specs also >> hinted at advertising per-user keys in DNS. That is a real cost-saver >> and allows cheap peer-to-peer authentication - something I would think >> SIP would like to do. Peer-to-peer authentication is highly desirable, and some devices may be able to provide it in either model. >> 3. Security. With the now common knowledge that TLS is interceptable >> with participating CAs, one has to question the whole security premise >> of a CA model. =8A and for the delegation models of the DNS, there is corollary inceptions that could be launched by anyone above you in the delegation hierarchy, right? >> 4. Flexibility. You can change your DNS at a whim. Need to change key >> lengths, or algorithms in a hurry? Need to spin up a new domain? Try >> that with a CA. You're surely right that for some implementations of DNS services, and some implementations of CAs, it would be easier to provision new and surprising security features through the DNS. I'm not sure I see a lot of value in that, though. If you publish keys with previously unsupported lengths or use new algorithms unilaterally in your domain name's records, I suspect that for authentication/verification services surprise is a bad thing. When you expect your records to be consumed by just anyone, you need to be pretty strict in what you publish, so flexibility of this nature doesn't fulfill any obvious need. That situation won't be any different for CAs or for the DNS. >> 5. Orthogonality of trust. Dunno whether this is relevant to your SIP >> scenario, but the - always dubious - notion that CAs "assert" who you >> are was removed from the equation so that market forces could provide >> whatever was needed. One example might be DMARC in the email space. The idea here is that the trust anchors would only be projecting onto the Internet the existing authority structures of telephone numbers. In this respect, the enrollment method of the CA could provide a far tighter coupling between certs and TN authorities than there is between web certs and domain owners, say. But yes, necessarily the credentials issued are "orthogonal" to any existing Internet authority - that is a critical requirement of this work. I think the ability of CAs to enroll entities into a trust framework without following DNS-style delegation paths is a good reason for CAs and certs to play a part in the STIR solution. >> Having done the "assertion" dance for certs for non-US entities, I >> know the process is largely a farce. >> >> 6. Adaptation. We were of the belief that such keys could be trivially >> extended to other protocols, such as jabber and SIP, with little or no >> change (Yahoo Messenger interop with 3rd-parties in particular was a >> hot issue back then). I think the earlier specs had various attempts >> at codifying exactly how that would work, but not a lot of effort went >> into this in the WG. I believe CA certs could also be adapted to other protocols with no greater difficulty than DNS names. Some of the above are great reasons why, when we secure greenfield SIP identifiers, we should incorporate DANE or something like it. I'm really not clear these move the needle for telephone numbers, though. Jon Peterson Neustar, Inc. > > >For STIR, I believe the only interesting design risk in a DNS-based >approach is whether a DNS namespace can be adequately defined and >administered, to match the needs of the STIR function. > >In terms of any other operational concerns of the approach, DKIM >provides a large-scale, multi-administration equivalence existence >proof. It covers at least 60% of all email traffic on the net. I >believe there is no operational equivalent any other technical approach; >if that's not correct, it would help to hear about a global >authentication mechanism that supports an equivalent scale of >/independent/ (multi-administration) identifier authorizations. > >The view that creating, deploying and perhaps later modifying the design >of a CA-based global infrastructure will be straightforward does not >match anything I have ever heard about CA administration and operation, >at scale. Creating any global infrastructure is typically a very high >risk activity, but CAs have had an especially rocky, long-term history. > It would be extremely helpful to see some documentation that >demonstrates that that path is lower risk than simply adding some more >names and records to the DNS. > >In terms of public-vs-private operation, the notes that are getting >posted on this list seem to vary between a goal of public access and a >goal of private access (restricted to a privileged few operators.) The >scaling and operational complexity differences between these two >operating modes is, of course, fundamental. So it it be helpful to >stabilize this requirement for STIR and then be consistent about >referring to it. > > >d/ >--=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 Mon Jul 22 10:35: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 E8ED811E8120 for ; Mon, 22 Jul 2013 10:35:25 -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.276, 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 H8NEE-97RE6C for ; Mon, 22 Jul 2013 10:35:16 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id D39BE11E80D9 for ; Mon, 22 Jul 2013 10:35:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1374515041; x=1689873910; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=2zfBdDptCa XPFS5pknGMmGpgNzjGNflWHsIF5dcSkJo=; b=cJEAQr7PFfzsa+jrp2Z4DaZhOi Yytf2CXA0aAtbNF0rOgInhGQIjMdQBNEO3x6bY93hblGK++1SaJ3fSyq6SRw== Received: from ([10.31.58.71]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.28464374; Mon, 22 Jul 2013 13:44: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; Mon, 22 Jul 2013 13:34:48 -0400 From: "Peterson, Jon" To: Richard Shockey , "'DOLLY, MARTIN C'" , "'Cullen Jennings (fluffy)'" , "'IETF STIR Mail List'" Thread-Topic: [stir] Draft STIR Charter - out of band Thread-Index: AQHOhN3olDfhVRGd9k+Zyd10mnHrBZls/+QAgAQFRoD//8JSgA== Date: Mon, 22 Jul 2013 17:34:47 +0000 Message-ID: In-Reply-To: <008e01ce86e5$ed693190$c83b94b0$@shockey.us> 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.149] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: j33VlBezTaVlfOj8ZJEpCg== Content-Type: text/plain; charset="us-ascii" Content-ID: <5A54AA695B0C0F488BF14656A5B0AD4F@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Russ Housley' Subject: Re: [stir] Draft STIR Charter - 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: Mon, 22 Jul 2013 17:35:26 -0000 I don't think Cullen's note is recommending that incumbent carriers forgo in-band. If anything, he suggested that it will take a while for carriers to get in-band implemented (something I would have thought Mr. Dolly would sympathize with), and that out-of-band would help as a interim solution in the meantime, since it could be implemented on edge devices like smartphones. That is an argument not to wait to do out-of-band only until after in-band is done, but it doesn't assume anything about existing carrier infrastructure or require any changes to same. Nor does this have anything to do with whether the trust anchors reside in the DNS, in CAs, in both or in neither. Jon Peterson Neustar, Inc. On 7/22/13 7:15 AM, "Richard Shockey" wrote: > >To Brother Marty's point folks have got to understand what Incumbent >Carriers ILEC AND MSO's are capable of actually deploying given the >existing >infrastructure and capital constraints on all parties concerned. The end >of >the TDM/SS7 PSTN are upon us ... certainly in North America and the US in >particular. > >IMHO any non DNS like in band solution will not deploy within carrier >networks cached or otherwise if you believe, as I do that the carriers are >an important part of the solution. There is a VAST amount of experience >with cached DNS infrastructure in SIP/IMS networks for multiple >applications >LNP routing etc. =20 > >There are LOTS of market binders here. If folks want to parallel out of >band >vs in band fine there may be some limited justification and use cases for >this. I'm skeptical but I've been wrong in the past. > > >-----Original Message----- >From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >DOLLY, MARTIN C >Sent: Friday, July 19, 2013 8:52 PM >To: Cullen Jennings (fluffy); IETF STIR Mail List >Cc: Russ Housley >Subject: Re: [stir] Draft STIR Charter - out of band > >What? Out of band before In band. What air are you breathing..... sorry >fluf... you are off base on this... let's think economic deployable... > >To date I have been nice but you bring out the best, this has been a USA >synergic discussion, no consideration to international, so IETF is going >yield to the ITU.....a(xx) > >-----Original Message----- >From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >Cullen Jennings (fluffy) >Sent: Friday, July 19, 2013 8:12 PM >To: IETF STIR Mail List >Cc: Russ Housley >Subject: Re: [stir] Draft STIR Charter - out of band > > >I'm listening to the arguments for in band or out of band but right now I >am >pretty skeptical that doing in-band before out-of-band is the right >order. I >suspect we need them both. Let me say a bit more > >Mobile phones could have done wideband audio long ago, but they did not. >There was no incentive for them to do it since there was no alternative >that >could do do wideband and had the same mobility properties. Then along came >smart phones and started providing much better audio quality using things >like Skype. Suddenly there was an incentive to do wideband audio on mobile >phones and you are starting to see that deploy. > >So lets talk about carrier to carrier SIP interconnects. Unless there is >an >real incentive, I sort of doubt that they will initially do a lot more >than >the SS7 interconnects they replace. No incentive and complicated to change >the business agreements in place. Particularly for interconnects between >say >Nigeria and US.=20 > >However, there is a great incentive for smartphones to implement an out of >band solutions even it only works to other smartphones. Once that existed, >there would be an incentive for non smart phones to get an equivalent >level >of service and that would most likely be done with a in band solution but >at >that point there is an incentive to deploy in band. > >A solution that only worked for smart phones is clearly not as useful as >one >that works for all phones, but doing both at the same time seems the most >likely way to me to get either of them to deploy. > >Sure it would be better for the non over the top service providers if >there >was only a solution that worked for the carrier a telephone numbers was >delegated down to form a nation level, but as apple showed with iMessage, >it >can be better for the users to have two ways to send a SMS messages to >another user. One way that goes thought the provider that the phone number >was delegated to, and one way that goes around the the carrier the phone >number was delegated to. > >So, I'd like to see the charter changed to work on both in-band and >out-of-band at the same time. > > > > > >On Jul 16, 2013, at 1:33 PM, Russ Housley wrote: > >> I have tried to pull all of the discussion into an updated charter. I >have also attached a diff to make it easier to review. >>=20 >> Russ >>=20 >>=20 >>=20 >> =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D >>=20 >>=20 >> Name: Secure Telephone Identity Revisited (stir) >> Area: RAI >>=20 >> Chairs: TBD >> Area Advisor: Richard Barnes >>=20 >> Mailing list: stir@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/stir >>=20 >> 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. As with email, the claimed source identity of a SIP >> request is not verified, and this permits unauthorized use of source >> identities as part of deceptive and coercive activities, such as >> robocalling (bulk unsolicited commercial communications), vishing >> (voicemail hacking, and impersonating banks) and swatting >> (impersonating callers to emergency services to stimulate unwarranted >> large scale law enforcement deployments). This working group will >> define a deployable mechanism that verifies the authorization of the >> calling party to use a particular telephone number. >>=20 >> SIP is one of the main VoIP technologies used by parties that want to >> present an incorrect origin, in this context an origin telephone number. >> Several previous efforts have tried to secure the origins of SIP >> communications, including RFC 3325, RFC 4474, and the VIPR working >>group. >> To date, however, true validation of the source of SIP calls has not >> seen any appreciable deployment. Several factors contributed to this >> lack of success, including: failure of the problem to be seen as >> critical at the time; lack of any technical means of producing a proof >> of authority over telephone numbers; misalignment of the mechanisms >> proposed by RFC 4474 with the complex deployment environment that has >> emerged for SIP; lack of end-to-end SIP session establishment; and >> inherent operational problems with a transitive trust model. To make >> deployment of this solution more likely, consideration must be given >> to latency, real-time performance, computational overhead, and >> administrative overhead for the legitimate call source and all >>verifiers. >>=20 >> As its first work item, the working group will specify a SIP >> header-based authorization mechanism to verify the originator of a SIP >> session is authorized to use the claimed source telephone number, >> where the session is established with SIP end to end. This is called an >in-band mechanism. >> The mechanism will use a canonical telephone number representation >> specified by the working group, including any mappings that might be >> needed between the SIP header fields and the canonical telephone >> number representation. The working group will consider choices for >> protecting identity information and credentials used, but will likely >> be based on a digital signature mechanism that covers a set of >> information in the SIP header fields, and verification will employ a >> credential that contains the public key and is associated with the one >>or >more telephone numbers. >> In order to be authoritative, credentials used with this mechanism >> will be derived from existing telephone number assignment and >> delegation models. That is, when a telephone number or range of >> telephone numbers is delegated to an entity, relevant credentials will >> be generated (or >> modified) to reflect such delegation. The mechanism must allow >> parties who are not delegated a telephone number, but are authorized >> by the entity who is delegated the number, to place calls using the >identity. >>=20 >> After completing the in-band mechanism, the working group will >> consider session establishment where there are one or more non-SIP >> hops, most likely using an out-of-band authorization mechanism. >> However, the in-band and the out-of-band mechanisms should share as >> much in common as possible, especially the credentials. >>=20 >> Expansion of the authorization mechanism to identities using the >> user@domain form deferred since the main focus of the working group is >> to develop a solution for telephone numbers. >>=20 >> The working group will coordinate with the Security Area on credential >> management. >>=20 >> The working group will coordinate with other working groups in the RAI >> Area regarding signaling through existing deployments. >>=20 >> Authentication and authorization of identity is closely linked to >> privacy, and these security features frequently come at the cost of >> privacy. 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 >> 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 >> The working group will deliver the following: >>=20 >> - A problem statement detailing the deployment environment and >> situation that motivate work on secure telephone identity >>=20 >> - A mechanism document describing the SIP end-to-end with telephone >> number-based identities >>=20 >> - A document describing the credentials required to support >> telephone number identity authentication >>=20 >> - A fallback mechanism to allow out-of-band identity establishment >> during call setup >>=20 >> Milestones >>=20 >> Sep 2013 Submit problem statement for Informational >> Nov 2013 Submit in-band mechanism for Proposed Standard >> Feb 2014 Submit credential specification for Proposed Standard >> Jun 2014 Submit fallback for Proposed Standard >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Mon Jul 22 10: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 C0EEA21F9F34 for ; Mon, 22 Jul 2013 10:55: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 qnEwJJvvcM-C for ; Mon, 22 Jul 2013 10:55:05 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id B95EC11E8135 for ; Mon, 22 Jul 2013 10:54:43 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6MHse5Y000880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Jul 2013 17:54:41 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 r6MHsdNe025835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jul 2013 17:54:39 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 r6MHsdO4006016; Mon, 22 Jul 2013 17:54:39 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 22 Jul 2013 10:54:38 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC1A1BD@EX2K10MB1.corp.yaanatech.com> Date: Mon, 22 Jul 2013 13:54:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! ! ! ! ! ! ! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> <84432CF7-A220-46F0-B945-F41F09F7061E@oracle.com> , <1E1AA91D-F3C8-4B43-A647-F898B9AB9778@oracle.com> <825EFE8B-555B-47EC-AF5D-55755C2439D5@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC19C60@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC19DAC@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC1A1BD@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] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 17:55:11 -0000 For the below, I assume you're referring to a public Internet access = model... On Jul 22, 2013, at 10:07 AM, Michael Hammer = wrote: > One detail that I think you are overlooking is that most calls are = between > individual that know each other. So, there is advantage in the end = system > caching the information that allows it to validate a call. =20 It doesn't matter whether you personally know the far-end caller or not. = DNS caches (or HTTP caches for that matter) can't know the CID Key = hasn't been compromised. If you personally think it's safe to cache = your friends' CID Keys for longer than 30 minutes, then fine cache them = all day. If you're comfortable with just believing the keys forever, = then fine cache them forever. That's an end host *application-layer* = local policy decision, because it requires knowledge/risk only a = specific user application or human can make.=20 But from the perspective of DNS caches in the network, and the DNS cache = in the end host operating system, they can't possibly make such a = decision. So if your SIP application asks the operating system's DNS = client for an answer, the operating system will check the authoritative = source after the TTL expires. In my opinion, that's a *good* property, = not a drawback. Of course your SIP application might decide to store = the CID Keys for longer, even forever, because you/it is willing to take = the risk; that's your problem to deal with if it turns out you were = wrong. > Whether that is > a cert or a DNS CID key would not be much different, except that, as = you > note, the DNS cache will likely be lost often. We should design for = the > majority of cases, not the smaller number of unknown callers. End host operating systems do cache DNS responses, but yes they'd be = clearing them out based on TTL. The DNS cache is "lost" because the = admin of the DNS decides to use a shorter TTL. The reason to do that in = STIR's case would be to reduce the time between checking the number = authority (the root "signer" of the logical "cert" equivalent), for a = changed or revoked CID key. The reason the admin would want to do that = would be to have the logical equivalent of "cert revocation" in some = reasonable time period. This makes sense because for a huge quantity of the E.164 number = "certs", the Assignee of the CID Keys will be regulated and unregulated = carriers around the World - not end users, not Enterprises, etc. While = they likely will not use one common private key for all their E.164 = numbers, it's doubtful they'd use separate keys for each and every E.164 = number. Even the CPU time required to generate 100 million unique RSA = keys is impressive. A much more likely scenario is they use the same = key for some X number of E.164s, for example one key for every 10k or = 100k E.164 numbers. So one compromised key represents a crap-load of = revocations. Even if they use a separate private key for each and every E.164, some X = number of those unique keys will reside on one server in the carrier - = the server doing the signing for that X number of E.164 sources' SIP = messages. In other words, even if every E.164 has a unique key, it's = not the endpoints doing the signing, but rather some systems in the = carrier and those systems would each have a lot of the E.164 private = keys. So again, one compromise represents a crap-load of revocations. > I was thinking that there could be a SIP 1xx series error code whereby = the > called party could tell the sender it needs a new cert. (That could = trigger > a display to the user of "Unknown new caller begin verified".) That = could > also be a point where a DNS cache could be queried as well. There = could be > an UPDATE message then sent to provide the cert for that call ID. RFC 4474 has such a response code - it fails the request with a 438 = response. But how does that help for your case? The *called* party = doesn't know the *calling* sender needs a new cert. As far as the = called party knows, the original cert is fine. The threat scenario is a = private key is compromised, allowing someone else to claim to be the = caller. If the cert is retrieved by DNS or some auto-generated URL, = it's hard for the attacker to accomplish the attack; if the cert is = retrieved by a URL sent in the SIP message, then it's trivial to = accomplish. > Another detail that you may have some cognitive dissonance on is that = the > security of the cert or the DNS entry is not secured by the caching = system > that delivered it to the called party, but by the fact that the = signature of > a well-known administrator cannot be spoofed. =20 Of course: the well-known admin's private key(s) can be compromised, and = then the DNS answers from the well-known admin can be "spoofed". Even = in that case it's not actually trivial to accomplish spoofing the DNS = answers, fwiw. But more importantly the situation can be fixed quickly = in a scalable manner, because the well-known admin's now-spoofable = signature was itself signed for only a limited time by a higher domain = authority, ultimately leading to ICANN's root keys. (you can read about = ICANN's key procedures at https://www.iana.org/dnssec/icann-dps.txt) Since we're talking about a public Internet access model, if ICANN's = keys are compromised the whole Internet is basically exposed anyway, for = some time period. I mean it's not like domain names aren't used for a = whole lot of more-important things than caller-id verification already. = :) > For DNS, garbage in =3D garbage > out. You have proven that a bad CID key can be securely distributed. = My > concern is about the root source of the CID key. Ummm... how is that any worse than how certs work? With end-entity = certificates, they're only as authentic as the trust and signature of = the root CA, and only as secure as end-entity cert holder of the private = key keeps its key *private*. If the root CA is compromised, hilarity = ensues. (i.e., DigiNotar) If the end-entity private key is compromised, = same problem. The difference is in the aspect of how everyone learns = about it and the CA can effectively fix it, quickly and in a scalable = manner. > "Even if the DNS admin's DNS Key is compromised, they can change it = and > re-sign without having to have the Assignees do anything." This is = false. > You would need to know what Text RRs were signed by that key, = invalidate all > those CID keys, reissue new public/private key pairs, then sign a new = Text > RR for however many that was. Problem is there is probably no audit = as to > what was signed. At least with a cert, you know what admin key signed = a > cert and can check any that you have to flush out both the admin cert = as > well as the certs that it signed. Nope. The TXT RR (CID Key) only holds the Assignee's *public* key = value. The DNS admin does not hold, nor never knew about, the private = key twin the Assignee has for its public CID Key. So the DNS admin can = sign all TXT RRs again, and keep its signature validity period short, = because the TXT RR's value doesn't need to change. It doesn't in certs either, for that matter. A CA could continuously = re-sign certs all day long (ie, generate certs from old CSRs). The = problem is that the old certs are given back to the end entity applicant = that made the signing request, to be used in TLS/SSL, S/MIME, etc. So = you'd need to disseminate new signed certs to all the old applicants. = That's why a cert validity period is long, and why we need revocation = lists for end-entity certs. In CIDER's case, the logical equivalent of = the "CSR applicant" never needs the signed "cert" back, because the = "cert" is retrieved directly from the "CA" by the STIR verifier.=20 > Your rfc4474 paragraph applies for both solutions as a compromised = end-user > private key doesn't even need a URL, just the DNS cache. But, at = least in > those cases, that is the end-user's bad. I don't understand what you mean. In CIDER, if Alice's end-user private = key is compromised by Charlie, then when Charlie sends a SIP INVITE to = Bob pretending to be Alice, Charlie would have to be able to inject a = fake answer to Bob's DNS query for Alice's public key. Charlie would = have to know what DNS cache Bob happens to use, and succeed in poisoning = that cache. DNS cache poisoning has occurred, but DNS caches learned = from that: they now employ means of making it a lot harder to perform = (e.g.: randomized source port, randomized 16-bit ID field value), and = ultimately DNSSEC was created with the goal of preventing such = poisoning. That's one of the main reasons why one would even use DNSSEC = in a CIDER public Internet access model - to prevent such poisoning. -hadriel From Henning.Schulzrinne@fcc.gov Mon Jul 22 11:28: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 0E9A421F8456 for ; Mon, 22 Jul 2013 11:28:51 -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 ZY4-kJ8SY4Md for ; Mon, 22 Jul 2013 11:28:46 -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 270C321F8517 for ; Mon, 22 Jul 2013 11:28:43 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Dan York' , "" Thread-Topic: [stir] CA Certs Thread-Index: AQHOhraSLrFny2QCrUyN8/TvPxbVEZlw5VgAgAAb44A= Date: Mon, 22 Jul 2013 18:28:39 +0000 References: <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! ! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> , <6642171F-7D32-408F-844B-21727086DC85@oracle.com> , <51ECE8F1.1090508@dcrocker.net> <582B387D-AB5B-482D-94BB-46F281E77AB6@isoc.org> In-Reply-To: <582B387D-AB5B-482D-94BB-46F281E77AB6@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org Mail List" Subject: Re: [stir] CA Certs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 22 Jul 2013 18:28:51 -0000 It seems that either a certificate or DNS-based approach can be public or p= rivate. For DNS, you'd presumably need either local DNS (restricted by netw= ork access controls of some sort) or a boatload of VPNs (which presumably h= ave to be standardized or profiled if you want interoperability, given the = multitude of VPN technologies out there). If you are relying on some local-= access-only-DNS, you need a mechanism to distribute the data to those local= DNS servers, update individual entries, do revocations, etc. Thus, there a= re a number of pieces that would need to be specified for the private-DNS o= ption in order to build a real system with thousands of validating particip= ants. For HTTP-based solution, you'd similarly have to pick from small bag of sol= utions (basic, digest, client cert, all over TLS, presumably), but most cli= ent implementations are likely to support all three out of the box. Another consideration is who runs what size infrastructure - given the lack= of useful resolver caching, the DNS solution would likely have to be able = to handle every single validation in the VPN model from the central authori= ty (e.g., the numbering administrator). In the HTTP data synchronization mo= del, the load would be local to the validating carrier, with the central in= frastructure pushing only updates as needed.=20 Indeed, you could picture a combination of the two approaches - a carrier r= uns a local, private DNS service that interacts with the call control compo= nents, but the local server care and feeding is through an HTTP-style cache= management and bulk transfer mechanism. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dan= York Sent: Monday, July 22, 2013 8:35 AM To: Cc: stir@ietf.org Mail List Subject: Re: [stir] CA Certs Dave,=20 On Jul 22, 2013, at 4:35 AM, "Dave Crocker" wrote: > The DKIM model is a small enhancement over the original work done by Mark= Delany, then at Yahoo, for DomainKeys. It offered the basic innovation of= putting public keys directly into the DNS, using the location in the DNS n= amespace as the de facto cert. I asked him what drove this design choice. Very good responses. Thank you for requesting and sharing this feedback.=20 > In terms of public-vs-private operation, the notes that are getting poste= d on this list seem to vary between a goal of public access and a goal of p= rivate access (restricted to a privileged few operators.) The scaling and = operational complexity differences between these two operating modes is, of= course, fundamental. So it it be helpful to stabilize this requirement fo= r STIR and then be consistent about referring to it. While I agree that stabilizing the requirement could be helpful, I would al= so note that as Hadriel mentioned, a benefit of a DNS-based approach is tha= t we don't really have to decide on the public-vs-private aspect right now.= We can construct a system that can be used publicly - and then later if pe= ople want to use it on private networks they an do so. (Although in writing= this I realize that I am effectively indicating the initial requirement sh= ould be "public".) Dan _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From richard@shockey.us Mon Jul 22 11:57:24 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98AE011E80D5 for ; Mon, 22 Jul 2013 11:57:24 -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 m9jRNSVIiTBq for ; Mon, 22 Jul 2013 11:57:19 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id D2A7121F8481 for ; Mon, 22 Jul 2013 11:57:16 -0700 (PDT) Received: (qmail 20225 invoked by uid 0); 22 Jul 2013 18:56:19 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy14.unifiedlayer.com with SMTP; 22 Jul 2013 18:56: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=Eg5gAws9DgM7Rx28NTSY4q9tXjc0hutI2DmEAuLfRrM=; b=ZPZa9euEAzbZQuuxhYRTtrPDn+vIUCShmq8Ow2zm3CZre9YKO+IPWuku4KnFUyaX4aOCVOlN/+s6J9prBTNBqDtsFgBHM8d3zxN6Fo0hOFn3VsoJHW68MbxECxmM0os4; Received: from [72.66.111.124] (port=53839 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V1LHO-0005F6-9J; Mon, 22 Jul 2013 12:56:18 -0600 From: "Richard Shockey" To: "'Henning Schulzrinne'" , "'Dan York'" , References: <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! ! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> , <6642171F-7D32-408F-844B-21727086DC85@oracle.com> , <51ECE8F1.1090508@dcrocker.net> <582B387D- AB5B-482D-94BB-46F281E 77AB6@isoc.org> In-Reply-To: Date: Mon, 22 Jul 2013 14:56:05 -0400 Message-ID: <015b01ce870d$254d4a70$6fe7df50$@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: AQL/BCbN34pvssG/zmP8Y9dsYJE+5AG2YcYxAVD2kjIAqVKS7wF5bVdPAVWjlQwA0Au3ZQJwgEvOAboCApoBU1lQ1wFzPMjQAb1CkD0B93+mIgFclyxWAy75+sgAtPotnQJFW8FvAcOj084CcME62gFbFaA0lhezKwA= 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] CA Certs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 22 Jul 2013 18:57:24 -0000 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, July 22, 2013 2:29 PM To: 'Dan York'; Cc: stir@ietf.org Mail List Subject: Re: [stir] CA Certs It seems that either a certificate or DNS-based approach can be public or private. For DNS, you'd presumably need either local DNS (restricted by network access controls of some sort) [ [RS> ] Which is exactly how boatloads of carriers access LNP and Routing data via 6116 queries today. People forget it was local TCAP elimination that drove Carrier ENUM into the network in the first place. "No more dip charges." SS7 sucks. or a boatload of VPNs (which presumably have to be standardized or profiled if you want interoperability, given the multitude of VPN technologies out there). If you are relying on some local-access-only-DNS, you need a mechanism to distribute the data to those local DNS servers, update individual entries, do revocations, etc. [RS> ] Which is exactly how wireless carriers implemented MMS routing using 6116 before moving to a locally cached DNS ENUM servers and a trusted registry with a bulk download distribution mode of the portability corrected NANP>LRN>OCN>MMSC data. Thus, there are a number of pieces that would need to be specified for the private-DNS option in order to build a real system with thousands of validating participants. For HTTP-based solution, you'd similarly have to pick from small bag of solutions (basic, digest, client cert, all over TLS, presumably), but most client implementations are likely to support all three out of the box. Another consideration is who runs what size infrastructure - given the lack of useful resolver caching, the DNS solution would likely have to be able to handle every single validation in the VPN model from the central authority (e.g., the numbering administrator). In the HTTP data synchronization model, the load would be local to the validating carrier, with the central infrastructure pushing only updates as needed. [RS> ] Which is essentially how the NPAC works today. A massive centralized registry but distributed local cache, but that has "other" issues of who operates the registry, why and how much. Shockey's Law here" Money is the answer, what is the question?" My point is in the modern SIP/IMS model the protocols are in place with the CSCF to handle locally cached 6116/DNS data and modifications could be relatively simple. I just don't see the HTTP stack making its way into IMS before V 26 or so but I'll let 3GPP experts elaborate on that. Indeed, you could picture a combination of the two approaches - a carrier runs a local, private DNS service that interacts with the call control components, but the local server care and feeding is through an HTTP-style cache management and bulk transfer mechanism. [RS> ] There is some rationale for that. This begs an old problem we had in Carrier ENUM. Do you want a "Thick" registry or "Thin". Thick presumes all the data components are held in the centralized registry, which is useful for validation purposes etc then distributed out via some bulk transfer/update method or Thin where the data is presumed to be held by the "Carrier of Record" for the TN and the first order resolution is nothing more than some NS like record. DNS is much much better for Thin models. Logically Peterson is somewhat correct here. If you presume that at least _part_ of the solution involves the CUA or edge PBX systems you might look at HTTP mechanisms, but then you have reduced the problem to access methodology. There are real tradeoff's here are in presuming how the data is managed and how it would globally scale. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dan York Sent: Monday, July 22, 2013 8:35 AM To: Cc: stir@ietf.org Mail List Subject: Re: [stir] CA Certs Dave, On Jul 22, 2013, at 4:35 AM, "Dave Crocker" wrote: > The DKIM model is a small enhancement over the original work done by Mark Delany, then at Yahoo, for DomainKeys. It offered the basic innovation of putting public keys directly into the DNS, using the location in the DNS namespace as the de facto cert. I asked him what drove this design choice. Very good responses. Thank you for requesting and sharing this feedback. > In terms of public-vs-private operation, the notes that are getting posted on this list seem to vary between a goal of public access and a goal of private access (restricted to a privileged few operators.) The scaling and operational complexity differences between these two operating modes is, of course, fundamental. So it it be helpful to stabilize this requirement for STIR and then be consistent about referring to it. While I agree that stabilizing the requirement could be helpful, I would also note that as Hadriel mentioned, a benefit of a DNS-based approach is that we don't really have to decide on the public-vs-private aspect right now. We can construct a system that can be used publicly - and then later if people want to use it on private networks they an do so. (Although in writing this I realize that I am effectively indicating the initial requirement should be "public".) 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 From michael.hammer@yaanatech.com Mon Jul 22 14:09: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 6A92411E8123 for ; Mon, 22 Jul 2013 14:09:39 -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 G6iE5Flt-NAU for ; Mon, 22 Jul 2013 14:09: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 2745111E80D3 for ; Mon, 22 Jul 2013 14:09:32 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Mon, 22 Jul 2013 14:09:29 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) Thread-Index: AQHOgvzGoW2Sqvrxc0GEvdoogk5ro5lpa5QAgAAoCgCAAe3VAIAAA5sAgAEbyACAABl1gP//jBDQgACJywD//6q3gIAA/xKAgANB3HCAALyhgP//tYrw Date: Mon, 22 Jul 2013 21:09:28 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC1A683@EX2K10MB1.corp.yaanatech.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! ! ! ! ! ! ! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> <84432CF7-A220-46F0-B945-F41F09F7061E@oracle.com> , <1E1AA91D-F3C8-4B43-A647-F898B9AB9778@oracle.com> <825EFE8B-555B-47EC-AF5D-55755C2439D5@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC19C60@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC19DAC@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC1A1BD@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.71] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00C2_01CE86FE.390977A0" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 21:09:39 -0000 ------=_NextPart_000_00C2_01CE86FE.390977A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Let me try to sum up the disconnects I see: You assume that a Cert signing will likely be compromised and there will be a host of revocations needed. You assume that a DNS signing can't happen or the whole Internet would be insecure. Any reason you trust one more than the other? (Assuming your authority is competent, but my authority is incompetent is an example of the false comparison I was talking about.) s/DigiNotar/ICANN similar hilarity will ensue. Flooding the DNS with 100 million telephone number keys every 30 seconds is doable. Flooding the DNS with a CRL of known compromises is not workable. Given that the number of compromises should be several orders of magnitude lower than the Certs/CID's themselves, why would the smaller be harder? (Note you make assumptions about how easy it might be to compromise a single user.) (You also seem to make assumptions about how often a cert is renewed. For high-value targets they could do it more often.) With Certs, a compromised private key is not known by anybody. Called continues using old cert. Bad. With DNS, a compromised private key is magically known by DNS. Called fetches the public key of the compromised private key. Ummm same diff. Bad. How exactly is that discovered in one case, but not the other? With Certs, a compromised (assignee) private key requires a new cert to be distributed (new public key associated with tel#). With DNS, a compromised (assignee) private key doesn't need to be replaced, we just re-sign the TXT RR record, because "The TXT RR (CID Key) only holds the Assignee's *public* key value." That still does not compute. "In CIDER, if Alice's end-user private key is compromised by Charlie, then when Charlie sends a SIP INVITE to Bob pretending to be Alice, Charlie would have to be able to inject a fake answer to Bob's DNS query for Alice's public key. Ummm, no. Not at all, Charlie has the private key, so the DNS will confirm that Charlie is Alice, since the supposed "good" DNS entry's public key will work with that private key. Mike -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Monday, July 22, 2013 1:55 PM To: Michael Hammer Cc: stir@ietf.org Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) For the below, I assume you're referring to a public Internet access model... On Jul 22, 2013, at 10:07 AM, Michael Hammer wrote: > One detail that I think you are overlooking is that most calls are > between individual that know each other. So, there is advantage in > the end system caching the information that allows it to validate a call. It doesn't matter whether you personally know the far-end caller or not. DNS caches (or HTTP caches for that matter) can't know the CID Key hasn't been compromised. If you personally think it's safe to cache your friends' CID Keys for longer than 30 minutes, then fine cache them all day. If you're comfortable with just believing the keys forever, then fine cache them forever. That's an end host *application-layer* local policy decision, because it requires knowledge/risk only a specific user application or human can make. But from the perspective of DNS caches in the network, and the DNS cache in the end host operating system, they can't possibly make such a decision. So if your SIP application asks the operating system's DNS client for an answer, the operating system will check the authoritative source after the TTL expires. In my opinion, that's a *good* property, not a drawback. Of course your SIP application might decide to store the CID Keys for longer, even forever, because you/it is willing to take the risk; that's your problem to deal with if it turns out you were wrong. > Whether that is > a cert or a DNS CID key would not be much different, except that, as > you note, the DNS cache will likely be lost often. We should design > for the majority of cases, not the smaller number of unknown callers. End host operating systems do cache DNS responses, but yes they'd be clearing them out based on TTL. The DNS cache is "lost" because the admin of the DNS decides to use a shorter TTL. The reason to do that in STIR's case would be to reduce the time between checking the number authority (the root "signer" of the logical "cert" equivalent), for a changed or revoked CID key. The reason the admin would want to do that would be to have the logical equivalent of "cert revocation" in some reasonable time period. This makes sense because for a huge quantity of the E.164 number "certs", the Assignee of the CID Keys will be regulated and unregulated carriers around the World - not end users, not Enterprises, etc. While they likely will not use one common private key for all their E.164 numbers, it's doubtful they'd use separate keys for each and every E.164 number. Even the CPU time required to generate 100 million unique RSA keys is impressive. A much more likely scenario is they use the same key for some X number of E.164s, for example one key for every 10k or 100k E.164 numbers. So one compromised key represents a crap-load of revocations. Even if they use a separate private key for each and every E.164, some X number of those unique keys will reside on one server in the carrier - the server doing the signing for that X number of E.164 sources' SIP messages. In other words, even if every E.164 has a unique key, it's not the endpoints doing the signing, but rather some systems in the carrier and those systems would each have a lot of the E.164 private keys. So again, one compromise represents a crap-load of revocations. > I was thinking that there could be a SIP 1xx series error code whereby > the called party could tell the sender it needs a new cert. (That > could trigger a display to the user of "Unknown new caller begin > verified".) That could also be a point where a DNS cache could be > queried as well. There could be an UPDATE message then sent to provide the cert for that call ID. RFC 4474 has such a response code - it fails the request with a 438 response. But how does that help for your case? The *called* party doesn't know the *calling* sender needs a new cert. As far as the called party knows, the original cert is fine. The threat scenario is a private key is compromised, allowing someone else to claim to be the caller. If the cert is retrieved by DNS or some auto-generated URL, it's hard for the attacker to accomplish the attack; if the cert is retrieved by a URL sent in the SIP message, then it's trivial to accomplish. > Another detail that you may have some cognitive dissonance on is that > the security of the cert or the DNS entry is not secured by the > caching system that delivered it to the called party, but by the fact > that the signature of a well-known administrator cannot be spoofed. Of course: the well-known admin's private key(s) can be compromised, and then the DNS answers from the well-known admin can be "spoofed". Even in that case it's not actually trivial to accomplish spoofing the DNS answers, fwiw. But more importantly the situation can be fixed quickly in a scalable manner, because the well-known admin's now-spoofable signature was itself signed for only a limited time by a higher domain authority, ultimately leading to ICANN's root keys. (you can read about ICANN's key procedures at https://www.iana.org/dnssec/icann-dps.txt) Since we're talking about a public Internet access model, if ICANN's keys are compromised the whole Internet is basically exposed anyway, for some time period. I mean it's not like domain names aren't used for a whole lot of more-important things than caller-id verification already. :) > For DNS, garbage in = garbage > out. You have proven that a bad CID key can be securely distributed. > My concern is about the root source of the CID key. Ummm... how is that any worse than how certs work? With end-entity certificates, they're only as authentic as the trust and signature of the root CA, and only as secure as end-entity cert holder of the private key keeps its key *private*. If the root CA is compromised, hilarity ensues. (i.e., DigiNotar) If the end-entity private key is compromised, same problem. The difference is in the aspect of how everyone learns about it and the CA can effectively fix it, quickly and in a scalable manner. > "Even if the DNS admin's DNS Key is compromised, they can change it > and re-sign without having to have the Assignees do anything." This is false. > You would need to know what Text RRs were signed by that key, > invalidate all those CID keys, reissue new public/private key pairs, > then sign a new Text RR for however many that was. Problem is there > is probably no audit as to what was signed. At least with a cert, you > know what admin key signed a cert and can check any that you have to > flush out both the admin cert as well as the certs that it signed. Nope. The TXT RR (CID Key) only holds the Assignee's *public* key value. The DNS admin does not hold, nor never knew about, the private key twin the Assignee has for its public CID Key. So the DNS admin can sign all TXT RRs again, and keep its signature validity period short, because the TXT RR's value doesn't need to change. It doesn't in certs either, for that matter. A CA could continuously re-sign certs all day long (ie, generate certs from old CSRs). The problem is that the old certs are given back to the end entity applicant that made the signing request, to be used in TLS/SSL, S/MIME, etc. So you'd need to disseminate new signed certs to all the old applicants. That's why a cert validity period is long, and why we need revocation lists for end-entity certs. In CIDER's case, the logical equivalent of the "CSR applicant" never needs the signed "cert" back, because the "cert" is retrieved directly from the "CA" by the STIR verifier. > Your rfc4474 paragraph applies for both solutions as a compromised > end-user private key doesn't even need a URL, just the DNS cache. > But, at least in those cases, that is the end-user's bad. I don't understand what you mean. In CIDER, if Alice's end-user private key is compromised by Charlie, then when Charlie sends a SIP INVITE to Bob pretending to be Alice, Charlie would have to be able to inject a fake answer to Bob's DNS query for Alice's public key. Charlie would have to know what DNS cache Bob happens to use, and succeed in poisoning that cache. DNS cache poisoning has occurred, but DNS caches learned from that: they now employ means of making it a lot harder to perform (e.g.: randomized source port, randomized 16-bit ID field value), and ultimately DNSSEC was created with the goal of preventing such poisoning. That's one of the main reasons why one would even use DNSSEC in a CIDER public Internet access model - to prevent such poisoning. -hadriel ------=_NextPart_000_00C2_01CE86FE.390977A0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcy MjIxMDkyN1owIwYJKoZIhvcNAQkEMRYEFL+/kJ3e19PSvU2KoMlK9f9Vo0zQMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAZbJxc9w8tfDG9FqEYffIAG1yXaEb7Vgl1r83B3wp fiWa93+GZ1I33XNMASGTw11sGeHutdDgtA92K9J1Kf3gQ6Ym+5/1vtYpyUNeFB+VxGR+9z+c6ODI vHH2GchmAaxsRBYp0W03WYPFjJs7t5EiINrw3JuBplBiDhDzqAU7EB4mPBmloqXhxeKB8dx7/WlL mAAddTvO7Qt69iBZ4vU6OiLkyVYi2MvVET8D7aRGD4fod4hI7MctlGZhr2ArI5kBgYB1/PhS+EgO 1cZI1xUnLfrpcROD+385ZxG3bmTZNpEJ4nuKmdN7lZUwG1TZHaPa8ajWjV7PmpTlU6QVhgT4rAAA AAAAAA== ------=_NextPart_000_00C2_01CE86FE.390977A0-- From hadriel.kaplan@oracle.com Mon Jul 22 15:39: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 4391411E8189 for ; Mon, 22 Jul 2013 15:39:49 -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 tTLbofMLMJZC for ; Mon, 22 Jul 2013 15:39:42 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9E37211E8182 for ; Mon, 22 Jul 2013 15:39:42 -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 r6MMdcoO024514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Jul 2013 22:39:39 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 r6MMdaXK006423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jul 2013 22:39: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 r6MMdZQ4024647; Mon, 22 Jul 2013 22:39:35 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 22 Jul 2013 15:39: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: Date: Mon, 22 Jul 2013 18:39:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1CCEBEA1-066C-4084-B39E-0E8E0A1AE1CE@oracle.com> References: <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! ! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> , <6642171F-7D32-408F-844B-21727086DC85@oracle.com> , <51ECE8F1.1090508@dcrocker.net> <582B387D! -AB5B-482D-94BB-46F281E77AB6@isoc.org> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "stir@ietf.org List" Subject: Re: [stir] CA Certs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 22 Jul 2013 22:39:49 -0000 On Jul 22, 2013, at 2:28 PM, Henning Schulzrinne = wrote: > It seems that either a certificate or DNS-based approach can be public = or private. For DNS, you'd presumably need either local DNS (restricted = by network access controls of some sort) or a boatload of VPNs (which = presumably have to be standardized or profiled if you want = interoperability, given the multitude of VPN technologies out there). If we're talking about a private access model but with only a = centralized database and no local copies, then yes you can do it = multiple ways - that's probably a good thing. You're talking about = connecting carriers to a central database thing in that model, so = there's no reason the central-DB service couldn't provide multiple VPN = access mechanisms of the carrier's choosing: IPsec with static keys, = IPsec with IKE, SSL VPNs, MPLS VPNs, or even direct/leased T1 lines for = that matter. We don't have to standardize anything new - all those = technologies are standardized. It's a business arrangement decision = which to do. It doesn't have to be the same for every carrier. An NPAC-style model, on the other hand, could follow the existing NPAC = itself: there are local copies of the DB in the carriers, and per-call = queries don't go to the real NPAC. (at least I don't think the central = NPAC gets queried directly, does it?) So if it's not, then from a DNS = perspective, the NPAC doesn't have to implement anything that answers = DNS queries or even smells of "DNS", nor would it need to implement HTTP = query access either for that matter. The local database copies in the = carriers could provide DNS queries/answers to/from their own STIR = verifiers, but they are local copies owned by the carrier for its own = use, so they can do any protocol they wish. They could use SS7/TCAP = even. The trick is how to handle stuff that's not in the NPAC, namely = international numbers.=20 > If you are relying on some local-access-only-DNS, you need a mechanism = to distribute the data to those local DNS servers, update individual = entries, do revocations, etc. Afaik, the standards for that already exist: AXFR (RFC 1034/1035/5936), = IXFR (RFC 1995), and NOTIFY (RFC 1996). DNS servers even implement = them. But yeah, I agree it might be good to define an additional, alternative = means of performing those for STIR, or even for DNS in general. = Something HTTP-based might make sense for that, for example. Having said that, what alternative do we have for doing that? In what = model can we have local copies of a database in the carriers, yet not = have to define some protocol they could use to = download/synchronize/update their local database copy with a master? > Thus, there are a number of pieces that would need to be specified for = the private-DNS option in order to build a real system with thousands of = validating participants. I'm not sure which "validating participants" you mean? In a = local-access-only-DNS model, I'm assuming we're talking about a local = database in carriers, to be used by their SIP STIR verifier systems, = right? There's no need for those STIR verifier systems to have some new = VPN to the local database copies - they're already in a private network = in the carrier today, and already query such databases today for other = things: CNAM, call routing, etc. Those queries are sent on = private-network interfaces internal to the carrier. That's how Private = ENUM works, SIP works, DIAMETER works, etc. They don't send them over = IPSec or TLS internally. > For HTTP-based solution, you'd similarly have to pick from small bag = of solutions (basic, digest, client cert, all over TLS, presumably), but = most client implementations are likely to support all three out of the = box. I don't follow you - I mean I don't understand which "clients" you're = talking about: the SIP STIR verifiers as clients to a carrier's local = database, or the carrier local databases as clients to a central master? = (man this stuff is hard to discuss in email! We really need a WG with = virtual/physical meetings) > Another consideration is who runs what size infrastructure - given the = lack of useful resolver caching, the DNS solution would likely have to = be able to handle every single validation in the VPN model from the = central authority (e.g., the numbering administrator). If carriers don't have their own local copy of the DB, then of course by = definition anything not in someone's local cache goes to the master = authority. The same is true of HTTP of course. > In the HTTP data synchronization model, the load would be local to the = validating carrier, with the central infrastructure pushing only updates = as needed.=20 What "HTTP data synchronization model"? You lost me. :( > Indeed, you could picture a combination of the two approaches - a = carrier runs a local, private DNS service that interacts with the call = control components, but the local server care and feeding is through an = HTTP-style cache management and bulk transfer mechanism. Sure, that's possible. We'd still have to define how that HTTP-style = cache management and bulk transfer mechanism works though. -hadriel From dhc@dcrocker.net Tue Jul 23 02:40: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 D34F811E80DC for ; Tue, 23 Jul 2013 02:40: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=[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 Ih9zuoE2UQ-Q for ; Tue, 23 Jul 2013 02:40:39 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id CFA5611E8103 for ; Tue, 23 Jul 2013 02:40:39 -0700 (PDT) Received: from [172.20.130.53] (87-252-59-189.fast.net.uk [87.252.59.189] (may be forged)) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r6N9eVTG001552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Jul 2013 02:40:35 -0700 Message-ID: <51EE4F8C.3080807@dcrocker.net> Date: Tue, 23 Jul 2013 10:40:28 +0100 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=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, 23 Jul 2013 02:40:39 -0700 (PDT) Cc: "stir@ietf.org Mail List" Subject: Re: [stir] CA Certs 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, 23 Jul 2013 09:40:45 -0000 Jon, On 7/22/2013 6:18 PM, Peterson, Jon wrote: > > Personally, I still don't see much value in dragging this mailing list > deep into a certs-versus-DNS debate. Sorry for my confusion. I thought that IETF (working group) mailing lists were where technical analysis and choice were done. In fact, I thought that was embedded in the IETF at the level of religious precept. I hadn't realized that RAI operates according to different rules. Just out of curiosity, since there /is/ a debate to be had -- the choice between certs vs. dkim-like key distribution does involve competing designs -- what is the proper venue for it? > When I look at the web security world > today, I see both certificates and the DNS playing a role, "A" role is not the question. The question is which is to be used for key distribution and based on what trust model? Perhaps it will help to say DKIM-like (or DOSETA-based, to be even more au courante) rather than DNS, since the DNS can also be used to distribute certs. In fact, this highlights that there are a number of different choices, not just two: 1. DOSETA-over-DNS 2. Certs-over-DNS (Dane-ish) 3. Certs-over-?-over HTTP On the last, the question mark is because there's an undefined semantic layer -- I'm still not clear what the cert-specific protocol details are, that operate above HTTP. > and I think > we'd be best off we tried to leave the door open to both and see > where the market takes us. That is the sort of view that always sounds appealing but merely serves to delay inevitable pain, a bit like asking someone to use two different text editors or two different email programs, so they can leave the door open for which to use (at any point in time). These are core service design choices. They have to be made at some point, and it isn't possible to refine the overall system design until these basic architectural choices are made. As for letting the market decide, the usual way such competition is pursued between IETF protocols is by parallel, independent working groups, each with a clear focus on a single, specific architecture. Is that what you are proposing? The fuzziness (or ambiguity) of language like "both [can] play a role" is an example of the reason it is best to have an effort be focused on narrow problem-solving for a specific mechanism, rather than wandering back and forth and typically getting confused about what is being discussed. > I suspect certs are going to play a part in this, maybe > not the only part, but a part. The "DNS is better than certs" arguments > below, while they may have been persuasive arguments for DKIM, don't make > me feel any less sure that certs are viable here. That's why it's better to explore functional and OA&M trade-offs rather than personal feelings. >>> There were a number of factors in choosing the DNS model over the CA >>> approach. >>> >>> 1. Control. Key revocation and management is entirely in the control >>> of the domain owner. We see the mess with revocation in the CA >>> world. The lag and the lookup imposition just to name two issues. At >>> high volume this sort of approach is a performance disaster. > > True when it's clear who a "domain owner" is - in other words, when we're > talking about DNS names that you go get from a DNS registrar. Right you are pre-echoing the point about determining a name and administration structure that I made, towards the end of my message. >>> Frankly the CA business model is not well aligned with the security >>> benefits of certs. It wouldn't surprise me if CAs would want to do the >>> same IP/Domain binding and premium pricing for wildcard certs that >>> they do in the HTTP space. > > No lesser risk of that for the DNS than for certs, Actually there is, given that most DNS pricing has been driven towards commodity levels rather than premium levels. And for a mandated new branch to cover this new use, it can be limited to cost-recovery pricing. >>> Note that it never made it into DKIM, but early DomainKeys specs also >>> hinted at advertising per-user keys in DNS. That is a real cost-saver >>> and allows cheap peer-to-peer authentication - something I would think >>> SIP would like to do. > > Peer-to-peer authentication is highly desirable, and some devices may be > able to provide it in either model. Mark is correct that DKIM does not pursue per-user usage, but wrong that it per-user keys aren't supported, in that one can always have sub-domains and that provide additional granularity, down to the individual user. What it doesn't do is map that granularity to a full email address rather than just a domain name. >>> 3. Security. With the now common knowledge that TLS is interceptable >>> with participating CAs, one has to question the whole security premise >>> of a CA model. > > Š and for the delegation models of the DNS, there is corollary inceptions > that could be launched by anyone above you in the delegation hierarchy, > right? From the part of your comment that didn't get garbled, it looks as if "DNSSec" is the response to your point. >>> 4. Flexibility. You can change your DNS at a whim. Need to change key >>> lengths, or algorithms in a hurry? Need to spin up a new domain? Try >>> that with a CA. > > You're surely right that for some implementations of DNS services, Some? All do TTLs. If you mean something that that doesn't cover, then what is it? Short TTLs mean any associated leaf node's values can be changed within a TTL time. The essential point is that TTLs constitute a far simpler and more direct mechanism than CRLs. And unless I've missed the report, they've been demonstrated to work at scale, over the open Internet, across very large numbers of independent administrations. Where has this been demonstrated for CRLs? >>> 5. Orthogonality of trust. Dunno whether this is relevant to your SIP >>> scenario, but the - always dubious - notion that CAs "assert" who you >>> are was removed from the equation so that market forces could provide >>> whatever was needed. One example might be DMARC in the email space. > > The idea here is that the trust anchors would only be projecting onto the > Internet the existing authority structures of telephone numbers. In this > respect, the enrollment method of the CA could provide a far tighter > coupling between certs and TN authorities than there is between web certs This repeats the point I made at the end (and here, it is in the next paragraph) which is that figuring out an appropriate mapping to a DNS name and administration hierarchy is the significant challenge for using a DNS-based scheme. (But then, it also one of the significant challenges for using a /non/-DNS-based scheme...) And just as a referesher, here's the point I cited as your "pre-echoing"... >> For STIR, I believe the only interesting design risk in a DNS-based >> approach is whether a DNS namespace can be adequately defined and >> administered, to match the needs of the STIR function. >> >> In terms of any other operational concerns of the approach, DKIM >> provides a large-scale, multi-administration equivalence existence >> proof. It covers at least 60% of all email traffic on the net. I >> believe there is no operational equivalent any other technical approach; >> if that's not correct, it would help to hear about a global >> authentication mechanism that supports an equivalent scale of >> /independent/ (multi-administration) identifier authorizations. >> >> The view that creating, deploying and perhaps later modifying the design >> of a CA-based global infrastructure will be straightforward does not >> match anything I have ever heard about CA administration and operation, >> at scale. Creating any global infrastructure is typically a very high >> risk activity, but CAs have had an especially rocky, long-term history. >> It would be extremely helpful to see some documentation that >> demonstrates that that path is lower risk than simply adding some more >> names and records to the DNS. >> >> In terms of public-vs-private operation, the notes that are getting >> posted on this list seem to vary between a goal of public access and a >> goal of private access (restricted to a privileged few operators.) The >> scaling and operational complexity differences between these two >> operating modes is, of course, fundamental. So it it be helpful to >> stabilize this requirement for STIR and then be consistent about >> referring to it. -- Dave Crocker Brandenburg InternetWorking bbiw.net From york@isoc.org Tue Jul 23 08:43: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 8EC8311E829A for ; Tue, 23 Jul 2013 08:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HU-UlpxAoMx4 for ; Tue, 23 Jul 2013 08:43:40 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 958C011E8298 for ; Tue, 23 Jul 2013 08:43:40 -0700 (PDT) Received: from BLUPR06MB067.namprd06.prod.outlook.com (10.242.187.146) by BLUPR06MB067.namprd06.prod.outlook.com (10.242.187.146) with Microsoft SMTP Server (TLS) id 15.0.731.16; Tue, 23 Jul 2013 15:43:31 +0000 Received: from BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.198]) by BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.185]) with mapi id 15.00.0731.000; Tue, 23 Jul 2013 15:43:31 +0000 From: Dan York To: "stir@ietf.org Mail List" Thread-Topic: Link for the latest and greatest draft of the STIR charter? Thread-Index: AQHOh7tgibIG7qvJY0KRqGwJO+Nw5g== Date: Tue, 23 Jul 2013 15:43:29 +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.4] x-forefront-prvs: 0916FC3A18 x-forefront-antispam-report: SFV:NSPM; SFS:(164054003)(189002)(199002)(74706001)(47736001)(47976001)(49866001)(83322001)(74662001)(19580405001)(63696002)(74502001)(31966008)(19580385001)(65816001)(50986001)(79102001)(51856001)(36756003)(76482001)(77982001)(59766001)(4396001)(54356001)(77096001)(16236675002)(56776001)(81542001)(76176001)(15202345003)(69226001)(74876001)(46102001)(16406001)(80022001)(83072001)(47446002)(74366001)(19580395003)(15395725003)(81342001)(54316002)(76786001)(76796001)(56816003)(53806001)(437434002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB067; H:BLUPR06MB067.namprd06.prod.outlook.com; CLIP:10.255.101.4; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_CE141CE014585yorkisocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org Subject: [stir] Link for the latest and greatest draft of the STIR charter? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 23 Jul 2013 15:43:44 -0000 --_000_CE141CE014585yorkisocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm looking for a link to the latest draft of the STIR charter to pass alon= g to some folks interested in this work. Russ and Brian sent a revised dra= ft to the list on July 11: http://www.ietf.org/mail-archive/web/stir/current/msg00785.html which generated a lengthy discussion whose offshoots are still ongoing. = Russ and Brian, will you be updating the draft charter before the meeting? And is there a URL I can pass along that points to the latest draft charter= for a BOF? I.e. a static link as there is for a working group charter? O= r do BOF charters only live in email lists? (My apologies for my ignoranc= e on this but with the BOFs with which I have been involved in the past the= charters have not been under such vigorous discussion and so the link to a= n email message *could* be sent around or posted on a web page as "the" cha= rter for the upcoming BOF.) Thanks, 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/ --_000_CE141CE014585yorkisocorg_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
I'm looking for a link to the latest draft of the STIR charter to pass= along to some folks interested in this work.  Russ and Brian sent a r= evised draft to the list on July 11:

http://www.ietf.org/mail-archive/web/stir/current/msg00785.html

which generated a lengthy discussion whose offshoots are still ongoing= .    Russ and Brian, will you be updating the draft charter befor= e the meeting?  

And is there a URL I can pass along that points to the latest draft ch= arter for a BOF?  I.e. a static link as there is for a working group c= harter?  Or do BOF charters only live in email lists?   (My apolo= gies for my ignorance on this but with the BOFs with which I have been involved in the past the charters have not been und= er such vigorous discussion and so the link to an email message *could* be = sent around or posted on a web page as "the" charter for the upco= ming BOF.)

Thanks,
Dan

--
Dan York
Senior Content Strategist, Internet = Society
york@isoc.org <mailto:york@isoc.o= rg>   +1-802-735-1624
Jabber: york@jabber.isoc.org <mai= lto:york@jabber.isoc.org>
Skype: danyork   http://twitter= .com/danyork

http://www.internetsociety.org/deplo= y360/ 
--_000_CE141CE014585yorkisocorg_-- From mary.ietf.barnes@gmail.com Tue Jul 23 08:53:58 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8C211E82A6 for ; Tue, 23 Jul 2013 08:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.793 X-Spam-Level: X-Spam-Status: No, score=-101.793 tagged_above=-999 required=5 tests=[AWL=0.806, 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 omkdqRE1tnau for ; Tue, 23 Jul 2013 08:53:57 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD9411E82A2 for ; Tue, 23 Jul 2013 08:53:38 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id s1so4461360qcw.1 for ; Tue, 23 Jul 2013 08:53:37 -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=mw4RXPj5K2Ae03oimQWaSDL90R4oJM7aIPD51mq6uhM=; b=mh2Pl+acssB1Z60MXDgnJt7MQtYCaoxNh+b8mYAFihIF5tEwvgMT3itQz8Wnjg7ABi OWB9zm/hNXjt8rtSjLxiWnK5MZIB4TKNhXfPf5s2wQDOWeu006tI+rDiIWEYmu9LzNKl arL6SKJDHAqiUqVlj8DmZ2x6kvSnKJyyJgl8efRih2+mLaRBnTqbJWblgArpXJqESO1k tBrGEO7/o5dtpJWu6fK5YXKapABfdW3EutKvdV65q+Og28Phev8AUE3y/w8hN1n1jYpE VdK+86E29Gq+9IurQ05qLgSw3RJSSPJeRydZyofPFf1NpciHE9KnN2W07xf9cqfjPOLR +mlw== MIME-Version: 1.0 X-Received: by 10.224.73.193 with SMTP id r1mr6825925qaj.57.1374594817891; Tue, 23 Jul 2013 08:53:37 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Tue, 23 Jul 2013 08:53:37 -0700 (PDT) In-Reply-To: References: Date: Tue, 23 Jul 2013 10:53:37 -0500 Message-ID: From: Mary Barnes To: Dan York Content-Type: multipart/alternative; boundary=001a11c3e0e4d4a21604e22fcb63 Cc: "stir@ietf.org Mail List" Subject: Re: [stir] Link for the latest and greatest draft of the STIR charter? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 23 Jul 2013 15:53:58 -0000 --001a11c3e0e4d4a21604e22fcb63 Content-Type: text/plain; charset=ISO-8859-1 In general, you should be able to find all the Bof information here: http://tools.ietf.org/bof/trac/ Some of the bof charters are on that webpage and others just point to the charter in the WG mailing list. I would assume that the Bof chairs would ensure that the link is pointing to the latest and greatest charter for the Bof, but it doesn't look like it. So, the link you have probably is the latest, although clearly there have been lots of comments since that was posted. Mary. On Tue, Jul 23, 2013 at 10:43 AM, Dan York wrote: > I'm looking for a link to the latest draft of the STIR charter to pass > along to some folks interested in this work. Russ and Brian sent a revised > draft to the list on July 11: > > http://www.ietf.org/mail-archive/web/stir/current/msg00785.html > > which generated a lengthy discussion whose offshoots are still ongoing. > Russ and Brian, will you be updating the draft charter before the > meeting? > > And is there a URL I can pass along that points to the latest draft > charter for a BOF? I.e. a static link as there is for a working group > charter? Or do BOF charters only live in email lists? (My apologies for > my ignorance on this but with the BOFs with which I have been involved in > the past the charters have not been under such vigorous discussion and so > the link to an email message *could* be sent around or posted on a web page > as "the" charter for the upcoming BOF.) > > Thanks, > 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 > > --001a11c3e0e4d4a21604e22fcb63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In general, you should be able to find all the Bof informa= tion here:

Some of the bof charters a= re on that webpage and others just point to the charter in the WG mailing l= ist. =A0I would assume that the Bof chairs would ensure that the link is po= inting to the latest and greatest charter for the Bof, but it doesn't l= ook like it. =A0So, the link you have probably is the latest, although clea= rly there have been lots of comments since that was posted.

Mary.


On Tue, Jul 23, 2013 at 10:43 AM, Dan York <york@isoc.= org> wrote:
I'm looking for a link to the latest draft of the STIR charter to = pass along to some folks interested in this work. =A0Russ and Brian sent a = revised draft to the list on July 11:


which generated a lengthy discussion whose offshoots are still ongoing= . =A0 =A0Russ and Brian, will you be updating the draft charter before the = meeting? =A0

And is there a URL I can pass along that points to the latest draft ch= arter for a BOF? =A0I.e. a static link as there is for a working group char= ter? =A0Or do BOF charters only live in email lists? =A0 (My apologies for = my ignorance on this but with the BOFs with which I have been involved in the past the charters have not been und= er such vigorous discussion and so the link to an email message *could* be = sent around or posted on a web page as "the" charter for the upco= ming BOF.)

Thanks,
Dan

--
Dan York
Senior Content Strategist, Internet = Society

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


--001a11c3e0e4d4a21604e22fcb63-- From dhc@dcrocker.net Tue Jul 23 09:04: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 EFE5711E82BC for ; Tue, 23 Jul 2013 09:04:06 -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 Jux5Z5I5SYQz for ; Tue, 23 Jul 2013 09:04:02 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 979AF11E82B0 for ; Tue, 23 Jul 2013 09:04:02 -0700 (PDT) Received: from [10.101.1.226] ([176.12.107.140]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r6NG3o2e009804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Jul 2013 09:03:58 -0700 Message-ID: <51EEA962.8090302@dcrocker.net> Date: Tue, 23 Jul 2013 17:03:46 +0100 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 X-Priority: 2 (High) References: In-Reply-To: X-Forwarded-Message-Id: 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, 23 Jul 2013 09:04:01 -0700 (PDT) Cc: "stir@ietf.org" Subject: [stir] Fwd: 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: Tue, 23 Jul 2013 16:04:07 -0000 Russ, et al, Dan's query prompted a bit of reflection for me, one result of which was thinking that a bit of reflection might be good for us all... The enclosed provides a rather particular basis for evaluating the creation of a working group. As we saw immediately after it was posted, it still leaves some room for debate about its meaning and, therefore, the detailed criteria that should be applied from it. Still, it's a view that has substance and especially pragmatics. And it was a month ago, and we've continued with list discussions. To the extent that you, Russ, have seen discussion that seemed to be moving towards convergence, or seemed not to, it could be very helpful to obtain your summary feedback, as of now. In effect, I'm asking you to do a bit of an audit, highlighting barriers you currently see to the formation of a working group. This will give us roughly a week to disagree with your assessment and gain support for the disagreement or -- stated more constructively -- to scramble to obtain convergence where it is missing. Thanks. d/ -------- Original Message -------- Subject: Re: [stir] Do we agree on the basics? Date: Wed, 19 Jun 2013 17:19:23 -0400 From: Russ Housley To: Hadriel Kaplan CC: stir@ietf.org 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 _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir -- Dave Crocker Brandenburg InternetWorking bbiw.net From hadriel.kaplan@oracle.com Tue Jul 23 09:05: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 C53B111E82A1 for ; Tue, 23 Jul 2013 09:05:21 -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 mb76jauqCfQy for ; Tue, 23 Jul 2013 09:05:15 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id DB37321F9814 for ; Tue, 23 Jul 2013 09:05:06 -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 r6NG4tNr027187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Jul 2013 16:04:56 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 r6NG4r48016485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jul 2013 16:04:54 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 r6NG4qhc003420; Tue, 23 Jul 2013 16:04:53 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 23 Jul 2013 09:04: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: <00C069FD01E0324C9FFCADF539701DB3BBC1A683@EX2K10MB1.corp.yaanatech.com> Date: Tue, 23 Jul 2013 12:04:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6EF50BDB-3F41-49FE-83C1-20216D0D0BF0@oracle.com> References: <51E371BA.9060009@dcrocker.net> <011601ce818b$7bdd48e0$7397daa0$@shockey.us> <71E797DB-492C-4731-9888-A3FFBF2BBC5A@oracle.com> <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1827C@EX2K10MB1.corp.yaanatech.com> <971DC811-744! ! ! ! ! ! ! ! ! ! 6-4346-84C1-37738E3AF6C4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC184DD@EX2K10MB1.corp.yaanatech.com> <1134364F-C428-4C98-91D4-6F33D4271299@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC18687@EX2K10MB1.corp.yaanatech.com> <7CE281BE-CF34-4E12-992C-D07C838D95CB@oracle.com> <84432CF7-A220-46F0-B945-F41F09F7061E@oracle.com> , <1E1AA91D-F3C8-4B43-A647-F898B9AB9778@oracle.com> <825EFE8B-555B-47EC-AF5D-55755C2439D5@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC19C60@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC19DAC@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC1A1BD@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324! C9FFCADF539701DB3BBC1A683@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" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 16:05:21 -0000 On Jul 22, 2013, at 5:09 PM, Michael Hammer = wrote: > You assume that a Cert signing will likely be compromised and there = will be > a host of revocations needed. > You assume that a DNS signing can't happen or the whole Internet would = be > insecure. > Any reason you trust one more than the other? =20 I don't "trust" either one - I'm more focused on the "what happens after = its compromised". > (Assuming your authority is competent, but my authority is incompetent = is an > example of the false comparison I was talking about.) > s/DigiNotar/ICANN similar hilarity will ensue. My point with the ICANN keys getting compromised is that caller-id = verification will be the least of the problems in that scenario. In = fact, in order to retrieve certificates at all using HTTP (or retrieve = CRLs/OCSP for that matter), you're already relying on DNS and ultimately = ICANN. But the good news is that because it's just one root CA for the entire = Internet, if that CA's keys get compromised the news of such a thing = will spread quick and wide, with operating systems, DNS caches, etc., = providing security updates to reject/remove the compromised root keys. Ultimately, no matter what we do, we do have to "trust" some root = signing organization(s). Would you rather trust one, or 200? Do you = want to check CRLs from one common root, or from 200 roots? In the = CIDER proposal, for a public Internet access model ultimately there is = one true root: ICANN, the root for DNS. That doesn't seem so crazy to = me, for a public Internet access thing to do. ICANN has already = deployed DNSSEC, and it's used for other important things than just = caller-id validation. > Flooding the DNS with 100 million telephone number keys every 30 = seconds is > doable. I don't know what the above means. In what way do you mean that? > Flooding the DNS with a CRL of known compromises is not workable. I don't know what the above means. What does it mean to "flood the DNS = with a CRL"? > Given that the number of compromises should be several orders of = magnitude > lower than the Certs/CID's themselves, why would the smaller be = harder? Of course the number of compromises should be lower than the number of = valid CID Keys. So? You lost me. > (Note you make assumptions about how easy it might be to compromise a = single > user.) > (You also seem to make assumptions about how often a cert is renewed. = For > high-value targets they could do it more often.) > With Certs, a compromised private key is not known by anybody. Called > continues using old cert. Bad. That depends on the way in which we define retrieving the certs, and = whether CRLs/OCSP is implemented. A compromised cert would be in a CRL = eventually. > With DNS, a compromised private key is magically known by DNS. Called > fetches the public key of the compromised private key. Ummm same = diff. > Bad. > How exactly is that discovered in one case, but not the other? Are you asking how the attacked party discovered their key has been = compromised? Or are you asking, once they discover it, how everyone = else learns about it? Obviously if you never learn your key was compromised, it won't stop = being usable until it gets changed and its validity time expires. If you learn a key was compromised, with certs you go to the CA and get = new certs, and ask it to revoke the certs it signed for you, either in = CRL or OCSP. With DNSSEC you go to the DNS admin for the zone you're = in, upload new CID Keys, and remove the compromised ones. =20 > With Certs, a compromised (assignee) private key requires a new cert = to be > distributed (new public key associated with tel#). > With DNS, a compromised (assignee) private key doesn't need to be = replaced, > we just re-sign the TXT RR record, because "The TXT RR (CID Key) only = holds > the Assignee's *public* key value." > That still does not compute. We were talking about if the DNS admin's DNSSEC zone-signing keys got = compromised - not if the Assignee's CID private-key got compromised. If = the Assignee's CID private keys got compromised, then of course the TXT = RR value changes. The nice thing is there's no CRL/OCSP; it's "revoked" = by timing out. > "In CIDER, if Alice's end-user private key is compromised by Charlie, = then > when Charlie sends a SIP INVITE to Bob pretending to be Alice,=20 > Charlie would have to be able to inject a fake answer to Bob's DNS = query for > Alice's public key. > Ummm, no. Not at all, Charlie has the private key, so the DNS will = confirm > that Charlie is Alice, since the supposed "good" DNS entry's public = key will > work with that private key. I was talking about once the compromise was discovered. Obviously if = Alice never discovers her key has been compromised, Charlie will be able = to use her key until Alice changes it. The odds are though that Alice = will discover it - not directly, but by either being told by Bob, or by = her carrier getting told one or more of its other E.164 numbers using = the same key being abused. Ultimately people do report caller-id fraud = today to their carriers... we're just trying to reduce the number of = incidents as much as possible. -hadriel From philippe.fouquart@orange.com Tue Jul 23 09: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 81C6811E82E9 for ; Tue, 23 Jul 2013 09:23: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 GuiSmIKMRtxG for ; Tue, 23 Jul 2013 09:23: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 CABC011E82DF for ; Tue, 23 Jul 2013 09:23:18 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 504932DCAE9; Tue, 23 Jul 2013 18:23:13 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 35E144C024; Tue, 23 Jul 2013 18:23:13 +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, 23 Jul 2013 18:23:12 +0200 From: To: Hadriel Kaplan , "stir@ietf.org" Thread-Topic: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt Thread-Index: AQHOfrnJIrVpZ/tZPUKeljXpre8LSZlychJw Date: Tue, 23 Jul 2013 16:23:12 +0000 Message-ID: <19893_1374596593_51EEADF1_19893_9071_1_B5939C6860701C49AA39C5DA5189448B0B55A6@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <20130712043221.11767.74779.idtracker@ietfa.amsl.com> <1F4B4D44-BD3E-4995-876A-147832C925F9@oracle.com> In-Reply-To: <1F4B4D44-BD3E-4995-876A-147832C925F9@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.7.23.150632 Subject: Re: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 23 Jul 2013 16:23:41 -0000 Hadriel, A couple of initial questions/comments on this draft.=20 Just an observation, first. Sometimes in 4.1 and 4.2 (see below), definitio= ns seem to refer to numbers in general, examples taken from the NANP,... an= d some conclusion drawn essentially from an observation on the example rath= er than from the definition. :)=20 > IKES also considers toll-free 1-8xx type numbers to be "E.164" numbers,= =20 > even though technically they are not. If the statement is not only about US toll free numbers but on "freephone" = numbers in general ("cc-8xx" being indeed very common for that), "technical= ly they may not be", would be more accurate I think, on other CCs some of t= hem are actually reachable from abroad.=20 > Nationally-specific number codes are numbers that are not E.164=20 > numbers, nor are private numbering plan numbers, but are instead=20 > number codes used for specific purposes within national numbering=20 > plans. Examples of these are N11 codes in the NANP, two or three=20 > digit emergency numbers such as 112, and inter-carrier common short=20 > codes. Even if they cannot be used as caller-id numbers , they are=20 > destination numbers and thus IKES needs to support them.=20=20 Actually short codes can sometimes be used as CgPN, again it depends on the= country. Probably not emergency numbers, (although you might even find cor= ner cases in the European 116 series, some of which qualify as such in some= countries) but short codes can be.=20 > Likewise for nationally-specific number codes, the IKES process=20 > generates a canonical representation of the number code. A leading=20 > country-code is prepended to the number code, to indicate the=20 > national numbering plan they are for. I suppose you've been waiting for this but the usual problem of using such = "pseudo E.164 numbers" for non E.164 numbers instead of local numbers is th= at, for countries that use national trunk codes eg 0, you can have an overl= ap between the short codes and the initial digits of the E.164 NDC or the S= N. It's obviously not a problem as long as we stay in the dialing plan (act= ually that's precisely what the national trunk code is here for, to have mo= re spare values to use) but it seems this would mean that the assignee of s= ay range 112 could legitimately sign +CC-112, I'm not sure that's a good th= ing. (although this particular one 112 is indeed generally reserved in the = national E.164 numbering plan but I use it to get the picture).=20 > 10. Usage in SS7/ISUP [...] > the signature, key=20 > index, and timestamp are carried in the User-to-User Information=20 > parameter ; (Noted past exchanges on this. Don't think this was addressed) Generally sp= eaking, what if the UUI is already used for a different purpose? (eg RFC 64= 67 use cases) Thanks,=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, July 12, 2013 6:39 AM To: stir@ietf.org Subject: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt Howdy, I've been meaning to submit a couple drafts for STIR - one for how a DNS mo= del could work, and one for how the stuff can get through SIP and other pro= tocols in-band. Since some of the recent discussion has touched on some of the issues, and = the deadline for new drafts is fast approaching, I've submitted the latter = draft just now: http://tools.ietf.org/html/draft-kaplan-stir-ikes-out-00 Sorry about the length, and yes it's still drafty/straw-man-ish. It's also= repetitive in sections, and needs a re-write, but the general concept shou= ld be understandable. Comments/flames appreciated. -hadriel Begin forwarded message: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : An Identity Key-based and Effective Signature for Orig= in-Unknown Types > Author(s) : Hadriel Kaplan > Filename : draft-kaplan-stir-ikes-out-00.txt > Pages : 28 > Date : 2013-07-11 >=20 > Abstract: > This document describes a mechanism and format for signing source > identity information of communication requests, in a manner capable > of crossing multiple communication protocol types - even if the > origin's protocol type is unknown. This is useful for providing > E.164 and other forms of Caller-ID reputability for various > communication protocols, such as SIP, XMPP, WebRTC, H.323, and > SS7/ISUP. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-kaplan-stir-ikes-out >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-kaplan-stir-ikes-out-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ 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 michael.hammer@yaanatech.com Tue Jul 23 09: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 0335711E82DF for ; Tue, 23 Jul 2013 09:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.158, 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 uyxxY6Pe+qeW for ; Tue, 23 Jul 2013 09:26:40 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 3C04711E8269 for ; Tue, 23 Jul 2013 09:26:26 -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, 23 Jul 2013 09:26:23 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) Thread-Index: AQHOgvzGoW2Sqvrxc0GEvdoogk5ro5lpa5QAgAAoCgCAAe3VAIAAA5sAgAEbyACAABl1gP//jBDQgACJywD//6q3gIAA/xKAgANB3HCAALyhgP//tYrwADfEMAAADkF6MA== Date: Tue, 23 Jul 2013 16:26:23 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC1BE03@EX2K10MB1.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC1A683@EX2K10MB1.corp.yaanatech.com> <6EF50BDB-3F41-49FE-83C1-20216D0D0BF0@oracle.com> In-Reply-To: <6EF50BDB-3F41-49FE-83C1-20216D0D0BF0@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.96] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_013A_01CE879F.D79948E0" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 16:26:46 -0000 ------=_NextPart_000_013A_01CE879F.D79948E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I think we are very close on understanding the pros and cons of each, so the email discussion has served its purpose. My flooding comment was standing back and looking at the forest for the trees. You indicated that the TTL is very small, so all the caches in the DNS need to be flushed and all new calls/quries to DNS will cause the data to flow from their root locations out towards the edge, again, every 30 seconds. Since there are millions of calls per minute globally, that looks like a flood of updates to me. So, my question was looking at the volume of RRs repeatedly going out, versus the number of CRLs that would need to go out. Given how often a key might be compromised, it would seem that the CRL number might be many orders of magnitude less. As you note, if a compromise occurs, in either approach, that information needs to get propagated to users of the network. One more scale question to throw in here. Anther thread mentions a web of VPNs may be needed. Today, we have some number of Service Providers involved. Every additional SP would mean an increase of VPNS by N(N-1). If we go from, say 10,000 to 100,000 or to 1M SPs does that scale? Mike -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Tuesday, July 23, 2013 12:05 PM To: Michael Hammer Cc: stir@ietf.org Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) On Jul 22, 2013, at 5:09 PM, Michael Hammer wrote: > You assume that a Cert signing will likely be compromised and there > will be a host of revocations needed. > You assume that a DNS signing can't happen or the whole Internet would > be insecure. > Any reason you trust one more than the other? I don't "trust" either one - I'm more focused on the "what happens after its compromised". > (Assuming your authority is competent, but my authority is incompetent > is an example of the false comparison I was talking about.) > s/DigiNotar/ICANN similar hilarity will ensue. My point with the ICANN keys getting compromised is that caller-id verification will be the least of the problems in that scenario. In fact, in order to retrieve certificates at all using HTTP (or retrieve CRLs/OCSP for that matter), you're already relying on DNS and ultimately ICANN. But the good news is that because it's just one root CA for the entire Internet, if that CA's keys get compromised the news of such a thing will spread quick and wide, with operating systems, DNS caches, etc., providing security updates to reject/remove the compromised root keys. Ultimately, no matter what we do, we do have to "trust" some root signing organization(s). Would you rather trust one, or 200? Do you want to check CRLs from one common root, or from 200 roots? In the CIDER proposal, for a public Internet access model ultimately there is one true root: ICANN, the root for DNS. That doesn't seem so crazy to me, for a public Internet access thing to do. ICANN has already deployed DNSSEC, and it's used for other important things than just caller-id validation. > Flooding the DNS with 100 million telephone number keys every 30 > seconds is doable. I don't know what the above means. In what way do you mean that? > Flooding the DNS with a CRL of known compromises is not workable. I don't know what the above means. What does it mean to "flood the DNS with a CRL"? > Given that the number of compromises should be several orders of > magnitude lower than the Certs/CID's themselves, why would the smaller be harder? Of course the number of compromises should be lower than the number of valid CID Keys. So? You lost me. > (Note you make assumptions about how easy it might be to compromise a > single > user.) > (You also seem to make assumptions about how often a cert is renewed. > For high-value targets they could do it more often.) With Certs, a > compromised private key is not known by anybody. Called continues > using old cert. Bad. That depends on the way in which we define retrieving the certs, and whether CRLs/OCSP is implemented. A compromised cert would be in a CRL eventually. > With DNS, a compromised private key is magically known by DNS. Called > fetches the public key of the compromised private key. Ummm same diff. > Bad. > How exactly is that discovered in one case, but not the other? Are you asking how the attacked party discovered their key has been compromised? Or are you asking, once they discover it, how everyone else learns about it? Obviously if you never learn your key was compromised, it won't stop being usable until it gets changed and its validity time expires. If you learn a key was compromised, with certs you go to the CA and get new certs, and ask it to revoke the certs it signed for you, either in CRL or OCSP. With DNSSEC you go to the DNS admin for the zone you're in, upload new CID Keys, and remove the compromised ones. > With Certs, a compromised (assignee) private key requires a new cert > to be distributed (new public key associated with tel#). > With DNS, a compromised (assignee) private key doesn't need to be > replaced, we just re-sign the TXT RR record, because "The TXT RR (CID > Key) only holds the Assignee's *public* key value." > That still does not compute. We were talking about if the DNS admin's DNSSEC zone-signing keys got compromised - not if the Assignee's CID private-key got compromised. If the Assignee's CID private keys got compromised, then of course the TXT RR value changes. The nice thing is there's no CRL/OCSP; it's "revoked" by timing out. > "In CIDER, if Alice's end-user private key is compromised by Charlie, > then when Charlie sends a SIP INVITE to Bob pretending to be Alice, > Charlie would have to be able to inject a fake answer to Bob's DNS > query for Alice's public key. > Ummm, no. Not at all, Charlie has the private key, so the DNS will > confirm that Charlie is Alice, since the supposed "good" DNS entry's > public key will work with that private key. I was talking about once the compromise was discovered. Obviously if Alice never discovers her key has been compromised, Charlie will be able to use her key until Alice changes it. The odds are though that Alice will discover it - not directly, but by either being told by Bob, or by her carrier getting told one or more of its other E.164 numbers using the same key being abused. Ultimately people do report caller-id fraud today to their carriers... we're just trying to reduce the number of incidents as much as possible. -hadriel ------=_NextPart_000_013A_01CE879F.D79948E0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcy MzE2MjYyMlowIwYJKoZIhvcNAQkEMRYEFOdZA9XRj4NnQd4K67CI2+rcPS6EMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAX2sMCz56RVNgxQhhcXA6FZ2GT26ZyMjAqQI6MIu3 PteyH5JpxbBT94TqEuiSSc6VWOorWXOOj+Y+8JDgkqBkx/dgnwLEwdlpy/Fc2bhsZkRlEtzoazk7 +e1LASOBW1Dj3ZVsxTgnu+7vf201rWP9hP4fek5bqUMoQ1vKUzgO6vdPP0KoBfzsgf4m43YVmPY9 eEqhSw2cGkkwwIw3+Aq+s1zpblNr/BGNB8NwzNvVzFGNfP3+kIbKGPT9hmDaL2ByGe0bVGeEudrG CG5V51TUcFcYPX5jkebEsMbKrAGMEbEUK5FME7QLFgmEiwB86TjTEI87FeLP0yxRFqOeka3k2gAA AAAAAA== ------=_NextPart_000_013A_01CE879F.D79948E0-- From kent@bbn.com Tue Jul 23 10:11: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 3F3AB11E82EC for ; Tue, 23 Jul 2013 10:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, 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 haC-UnAb9sWi for ; Tue, 23 Jul 2013 10:11:42 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8915111E823F for ; Tue, 23 Jul 2013 10:11:38 -0700 (PDT) Received: from dhcp-192-1-255-203.col.bbn.com ([192.1.255.203]:63261) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V1g7Z-000IY2-0t; Tue, 23 Jul 2013 13:11:33 -0400 Message-ID: <51EEB947.4030601@bbn.com> Date: Tue, 23 Jul 2013 13:11:35 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: dcrocker@bbiw.net, "stir@ietf.org" References: <29029_1373979285_51E54294_29029_4240_1_B5939C6860701C49AA39C5DA5189448B0B46D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <00C069FD01E0324C9FFCADF539701DB3BBC17CBA@EX2K10MB1.corp.yaanatech.com> <82BF5645-8B06-4AFF-87E4-7C391D0273B3@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC17DD5@EX2K10MB1.corp.yaanatech.com> <51E56D2C.2010700@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC17F58@EX2K10MB1.corp.yaanatech.com> <51E57813.3070601@bbn.com> <00C069FD01E0324C9FFCADF539701DB3BBC1808B@EX2K10MB1.corp.yaanatech.com> <82C4B977-B099-479B-9FD3-5421788FF1A6@oracle.com> <51E6BE72.8060500@bbn.com> <261BD146-4B2C-4528-ADF6-B7FE39F30B21@oracle.com> <51E6FE75.4080908@bbn.com> <51E7045B.3000308@cs.tcd.ie> <51E709F9.4090002@bbn.com> <51E7F9CB.5000007@dcrocker.net> <51E80996.1030803@bbn! .com> <51E845A9.6030605@dcrocker.net> In-Reply-To: <51E845A9.6030605@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [stir] Rollout timeframe X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 17:11:48 -0000 ... > > Thanks for up-leveling to a point of significant substance, namely the > importance of the functional goal in choosing among alternative designs. > > In the current context, it exactly targets the core question of the > functional goal for Caller-ID validation, with eye towards carefully > considering the pragmatics of a very constrained mechanism for this > very constrained goal. > > At a significantly more 'meta' level -- which will probably cause > Stephen F to roll his eyes now as he always did when I attempted this > during the DKIM effort -- it suggests the benefit of formulating and > attacking narrower goals with narrower solutions and the detriment of > trying, instead, to create broader and more general solutions. > > Divide and conquer on complex problems is good for humans, as well as > computers... I think subsequent discussion on the list shows that there is not yet agreement on a threat model, the number of players, in-band vs. OOB, etc. So when you argue for tackling narrower goals I suspect there is not yet agreement about what those goals are. Finally, my comments re DKIM vs. SMIME do not really support your argument about scope. The two mechanisms address largely different sets of goals. Steve From hadriel.kaplan@oracle.com Tue Jul 23 12:13: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 E9AF711E837E for ; Tue, 23 Jul 2013 12:13:12 -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, NORMAL_HTTP_TO_IP=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 dYu5K1nzHxun for ; Tue, 23 Jul 2013 12:13:06 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 157C511E819B for ; Tue, 23 Jul 2013 12:13: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 r6NJD1aU001507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Jul 2013 19:13:02 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 r6NJD0NF015911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jul 2013 19:13:01 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 r6NJD0na015878; Tue, 23 Jul 2013 19:13:00 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 23 Jul 2013 12:12: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: <00C069FD01E0324C9FFCADF539701DB3BBC1BE03@EX2K10MB1.corp.yaanatech.com> Date: Tue, 23 Jul 2013 15:12:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0073993E-1BC8-461C-9A7E-B5DCFC617DBF@oracle.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC1A683@EX2K10MB1.corp.yaanatech.com> <6EF50BDB-3F41-49FE-83C1-20216D0D0BF0@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1BE03@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" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 19:13:13 -0000 On Jul 23, 2013, at 12:26 PM, Michael Hammer = wrote: > My flooding comment was standing back and looking at the forest for = the > trees. > You indicated that the TTL is very small, so all the caches in the DNS = need > to be flushed and=20 > all new calls/quries to DNS will cause the data to flow from their = root > locations out towards the edge, again, every 30 seconds. [minor note: it was every 30 minutes, not seconds] > Since there are millions of calls per minute globally, that looks like = a > flood of updates to me. Not from the "root" exactly. For example, let's assume the CIDER anchor = for the NANP is "1.cid.example.com". The DNS caches/resolvers would = know which DNS server IPs to access for "1.cid.example.com" all the = time, because whenever its TTL expires just one call-triggered CIDER = query from anyone using the DNS resolver/cache refreshes it for all = calls for everyone on that resolver/cache, for the next TTL time period. In fact the resolvers would even know the one for the NPA (area-code) = level because there would be sufficient frequency of calls for that to = also happen, for the NPAs that are frequently called from. It's not a = big deal if it doesn't, but as an example the odds are a DNS resolver in = New York region would always know the DNS server IPs to go to for = ".2.1.2.1.cid.example.com", because as soon as its TTL times out just = one call from the 212 area-code to someone in New York would refresh it, = for all future calls from 212 to New York until the TTL expires again. But anyway, it's not like DNS doesn't already have to deal with far more = than millions of queries per minute for ".com" or "google.com" or = whatever. It's just that the queries don't all happen to the same = physical server. The tree hierarchy is used to split the work-load = among separate servers, and for busy nodes in the tree they're = replicated among multiple physical servers too, and deployed = geographically using anycast, and the DNS resolvers in the ISPs help = reduce the workload by caching. Regardless, a similar issue exists with HTTP and certs. Whatever we = decide the HTTP cache timeout is likely to be and whatever we decide the = cert validity period is likely to be, affects the volume of HTTP queries = to the CA; and there are still millions of calls per minute globally; = and there are still DDoS issues and attacks. Obviously some HTTP-based = sites have figured out how to handle massive HTTP query volume as well, = through numerous means. The nice thing about a DNS-based approach is = the vertical and horizontal scaling issues and their solutions are = well-known, have been around for a long time, and are easily and cheaply = achievable for any national country-code admin without all of them = having to be a Google or Facebook. > So, my question was looking at the volume of RRs repeatedly going out, > versus the number of CRLs that would need to go out. Ahh, ok I see what you're getting at. So you're thinking if the cert = validity time was long, it could be cached for a long time and reduce = query rates, at the expense of possibly enormous CRLs. OK, but who = would be doing the caching, and who would be checking and storing the = CRL? I mean we're talking about a public Internet access model, so for that = I've been assuming we're talking about end hosts doing the STIR-specific = work. Like a softphone or smartphone app on your mobile/PC. In such a = case, as I said before, they can choose to cache the CID Keys longer, = because they can make such a decision and take the risk. (it's not the = DNS layer caching them in such a case, it's the app-layer) For example = they can choose to store them longer if they're in the address book. = They can even do things like cache them for a week and refresh them only = once a week, or once a month, or whatever. That's the logical = equivalent of checking a CRL once a week or month or whatever, except = that you don't need to store the CRL or worry about its size, because = whenever you get a call from someone you don't have in your address book = you'll be doing a new DNS query instead of getting the cert and = comparing it against a CRL. Even an Enterprise IP-PBX could cache them longer in its application = layer, though I doubt it would be a worthwhile memory vs. CPU tradeoff = for it. But the point is the caches in the ISP's, Enterprises, etc., would not = be able to cache them forever, etc. > Given how often a key might be compromised, it would seem that the CRL > number might be many orders of magnitude less. I'm not sure what "number" you're referring to - the number of entries = in the CRL? =20 Keys really do get compromised. Since even in a public Internet access = model there will still be very large carriers holding the private keys = for signing their E.164 numbers, and they'll have those keys in a = limited number of servers, I think they will want to be able to revoke a = large number of them. So I think we do have to make it practical to = "revoke" millions of "certs", in a reasonable timeframe, globally. = (assuming each cert represents one E.164 number) I know this sounds like doomsday talk and fear mongering. I can't help = that. I generally avoid/ignore "what if" scenarios that have zero real = chance of happening, or if they happen then far worse things would = already have happened. I try to be pragmatic as much as possible. But = I think this scenario could actually occur. Again, it's not the reason I think CIDER in DNS is useful - it's just = one additional benefit. > One more scale question to throw in here. Anther thread mentions a = web of > VPNs may be needed. > Today, we have some number of Service Providers involved. > Every additional SP would mean an increase of VPNS by N(N-1). > If we go from, say 10,000 to 100,000 or to 1M SPs does that scale? Oddly, yes. I know it seems whacky, but it already scales today in SIP = - that's what happens in SIP right now. I mean if there's a need for a = "web of VPNs", it implies the CID Keys can't be made publicly available, = and that it needs to only be accessible by specific trusted parties. So = there's some administrative control required for which specific = organizations can access what from where. It's not just a = username/password required, but actual knowledge of what legal entity is = accessing it, backed up with legally binding documentation, reliable = corporate contact information, and with support and monitoring and = troubleshooting and all. The administrative overhead for such control doesn't scale, no matter = what the protocol being used is... not on a world-wide basis. There = would have to be a hierarchical structure of control, similar if not = identical to the PSTN, whereby the administrative headache could be = split-up/divided by country, and passed down to carriers. That already = happens right now, both in SIP and for things like NPAC. NPAC provides = a feed to regulated carriers over private links, and the carriers have = local copies of the DB. They in turn provide query access to it over = private links to lower-tier/non-regulated carriers. No one entity = provides query access from all SPs for NPAC; nor do they do so for SIP = or whatever. (I'm generalizing, but it gets the point across) Likewise in SIP, it's almost always interconnected using private links = or some form of a VPN (IPsec, MPLS, VLAN, whatever). It "scales" = because no one entity provides SIP access from all other SPs and = Enterprises world-wide. Some of them provide in the ballpark of 100,000 = SIP trunks to Enterprises, again in private VPNs, but it's not the VPN = technology that makes it burdensome or untenable. And ultimately we're = talking about a SIP in-band STIR scenario, so having the STIR-DB = administrative web of control follow the SIP administrative web of = control isn't crazy-talk. Having said all that, I'm hopeful that we don't need to make it a "web = of VPNs". I absolutely expect carriers to get controlled, secure access = for a whole copy of the DB for their country-code anyway, so that part = doesn't matter - but I'm hopeful that we can make the data sufficiently = benign to be available on the public Internet too for anyone else. Not = just for the heck of it, but because I think it would make the = international calling cases simpler, as well as help detect when = received caller-ids should have been STIR-secured but weren't. -hadriel From michael.hammer@yaanatech.com Tue Jul 23 12:39: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 79CDD11E82F8 for ; Tue, 23 Jul 2013 12:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, 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 rXS8993+k-Ri for ; Tue, 23 Jul 2013 12:39:42 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 65CF011E80D5 for ; Tue, 23 Jul 2013 12:39: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; Tue, 23 Jul 2013 12:39:41 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) Thread-Index: AQHOgvzGoW2Sqvrxc0GEvdoogk5ro5lpa5QAgAAoCgCAAe3VAIAAA5sAgAEbyACAABl1gP//jBDQgACJywD//6q3gIAA/xKAgANB3HCAALyhgP//tYrwADfEMAAADkF6MP//woOAgABwijA= Date: Tue, 23 Jul 2013 19:39:40 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC1C956@EX2K10MB1.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC1A683@EX2K10MB1.corp.yaanatech.com> <6EF50BDB-3F41-49FE-83C1-20216D0D0BF0@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1BE03@EX2K10MB1.corp.yaanatech.com> <0073993E-1BC8-461C-9A7E-B5DCFC617DBF@oracle.com> In-Reply-To: <0073993E-1BC8-461C-9A7E-B5DCFC617DBF@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.96] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_03A4_01CE87BA.D8282720" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 19:39:47 -0000 ------=_NextPart_000_03A4_01CE87BA.D8282720 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The validity time of the Certs could be some reasonable timeframe, say a year. The CRL would not increase indefinitely, as it would only need to list certs compromised within that period. Older Certs would be invalidated by their dates. You keep saying that the SPs would keep the private keys in servers for some reason. While they need their own keys for administrative actions, The private keys associated with the end-user certs should not be stored. I think you are assuming that the SP signs for the calling party. I am assuming that the calling party signs themselves. (SIP Internet case) Lastly, I can summarize you last 4 paragraphs: So long as we maintain the current hierarchy of service providers, then it will scale. That seems like a public policy question, so I won't go there. Mike -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Tuesday, July 23, 2013 3:13 PM To: Michael Hammer Cc: stir@ietf.org Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) On Jul 23, 2013, at 12:26 PM, Michael Hammer wrote: > My flooding comment was standing back and looking at the forest for > the trees. > You indicated that the TTL is very small, so all the caches in the DNS > need to be flushed and all new calls/quries to DNS will cause the data > to flow from their root locations out towards the edge, again, every > 30 seconds. [minor note: it was every 30 minutes, not seconds] > Since there are millions of calls per minute globally, that looks like > a flood of updates to me. Not from the "root" exactly. For example, let's assume the CIDER anchor for the NANP is "1.cid.example.com". The DNS caches/resolvers would know which DNS server IPs to access for "1.cid.example.com" all the time, because whenever its TTL expires just one call-triggered CIDER query from anyone using the DNS resolver/cache refreshes it for all calls for everyone on that resolver/cache, for the next TTL time period. In fact the resolvers would even know the one for the NPA (area-code) level because there would be sufficient frequency of calls for that to also happen, for the NPAs that are frequently called from. It's not a big deal if it doesn't, but as an example the odds are a DNS resolver in New York region would always know the DNS server IPs to go to for ".2.1.2.1.cid.example.com", because as soon as its TTL times out just one call from the 212 area-code to someone in New York would refresh it, for all future calls from 212 to New York until the TTL expires again. But anyway, it's not like DNS doesn't already have to deal with far more than millions of queries per minute for ".com" or "google.com" or whatever. It's just that the queries don't all happen to the same physical server. The tree hierarchy is used to split the work-load among separate servers, and for busy nodes in the tree they're replicated among multiple physical servers too, and deployed geographically using anycast, and the DNS resolvers in the ISPs help reduce the workload by caching. Regardless, a similar issue exists with HTTP and certs. Whatever we decide the HTTP cache timeout is likely to be and whatever we decide the cert validity period is likely to be, affects the volume of HTTP queries to the CA; and there are still millions of calls per minute globally; and there are still DDoS issues and attacks. Obviously some HTTP-based sites have figured out how to handle massive HTTP query volume as well, through numerous means. The nice thing about a DNS-based approach is the vertical and horizontal scaling issues and their solutions are well-known, have been around for a long time, and are easily and cheaply achievable for any national country-code admin without all of them having to be a Google or Facebook. > So, my question was looking at the volume of RRs repeatedly going out, > versus the number of CRLs that would need to go out. Ahh, ok I see what you're getting at. So you're thinking if the cert validity time was long, it could be cached for a long time and reduce query rates, at the expense of possibly enormous CRLs. OK, but who would be doing the caching, and who would be checking and storing the CRL? I mean we're talking about a public Internet access model, so for that I've been assuming we're talking about end hosts doing the STIR-specific work. Like a softphone or smartphone app on your mobile/PC. In such a case, as I said before, they can choose to cache the CID Keys longer, because they can make such a decision and take the risk. (it's not the DNS layer caching them in such a case, it's the app-layer) For example they can choose to store them longer if they're in the address book. They can even do things like cache them for a week and refresh them only once a week, or once a month, or whatever. That's the logical equivalent of checking a CRL once a week or month or whatever, except that you don't need to store the CRL or worry about its size, because whenever you get a call from someone you don't have in your address book you'll be doing a new DNS query instead of getting the cert and comparing it against a CRL. Even an Enterprise IP-PBX could cache them longer in its application layer, though I doubt it would be a worthwhile memory vs. CPU tradeoff for it. But the point is the caches in the ISP's, Enterprises, etc., would not be able to cache them forever, etc. > Given how often a key might be compromised, it would seem that the CRL > number might be many orders of magnitude less. I'm not sure what "number" you're referring to - the number of entries in the CRL? Keys really do get compromised. Since even in a public Internet access model there will still be very large carriers holding the private keys for signing their E.164 numbers, and they'll have those keys in a limited number of servers, I think they will want to be able to revoke a large number of them. So I think we do have to make it practical to "revoke" millions of "certs", in a reasonable timeframe, globally. (assuming each cert represents one E.164 number) I know this sounds like doomsday talk and fear mongering. I can't help that. I generally avoid/ignore "what if" scenarios that have zero real chance of happening, or if they happen then far worse things would already have happened. I try to be pragmatic as much as possible. But I think this scenario could actually occur. Again, it's not the reason I think CIDER in DNS is useful - it's just one additional benefit. > One more scale question to throw in here. Anther thread mentions a > web of VPNs may be needed. > Today, we have some number of Service Providers involved. > Every additional SP would mean an increase of VPNS by N(N-1). > If we go from, say 10,000 to 100,000 or to 1M SPs does that scale? Oddly, yes. I know it seems whacky, but it already scales today in SIP - that's what happens in SIP right now. I mean if there's a need for a "web of VPNs", it implies the CID Keys can't be made publicly available, and that it needs to only be accessible by specific trusted parties. So there's some administrative control required for which specific organizations can access what from where. It's not just a username/password required, but actual knowledge of what legal entity is accessing it, backed up with legally binding documentation, reliable corporate contact information, and with support and monitoring and troubleshooting and all. The administrative overhead for such control doesn't scale, no matter what the protocol being used is... not on a world-wide basis. There would have to be a hierarchical structure of control, similar if not identical to the PSTN, whereby the administrative headache could be split-up/divided by country, and passed down to carriers. That already happens right now, both in SIP and for things like NPAC. NPAC provides a feed to regulated carriers over private links, and the carriers have local copies of the DB. They in turn provide query access to it over private links to lower-tier/non-regulated carriers. No one entity provides query access from all SPs for NPAC; nor do they do so for SIP or whatever. (I'm generalizing, but it gets the point across) Likewise in SIP, it's almost always interconnected using private links or some form of a VPN (IPsec, MPLS, VLAN, whatever). It "scales" because no one entity provides SIP access from all other SPs and Enterprises world-wide. Some of them provide in the ballpark of 100,000 SIP trunks to Enterprises, again in private VPNs, but it's not the VPN technology that makes it burdensome or untenable. And ultimately we're talking about a SIP in-band STIR scenario, so having the STIR-DB administrative web of control follow the SIP administrative web of control isn't crazy-talk. Having said all that, I'm hopeful that we don't need to make it a "web of VPNs". I absolutely expect carriers to get controlled, secure access for a whole copy of the DB for their country-code anyway, so that part doesn't matter - but I'm hopeful that we can make the data sufficiently benign to be available on the public Internet too for anyone else. Not just for the heck of it, but because I think it would make the international calling cases simpler, as well as help detect when received caller-ids should have been STIR-secured but weren't. -hadriel ------=_NextPart_000_03A4_01CE87BA.D8282720 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcy MzE5Mzk0MFowIwYJKoZIhvcNAQkEMRYEFAtEwzBb0CaPXHlg0WlXOKiIISldMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAFU6qZobLcAykpagEgdkKRDMfa9H/fvO+391Km1H1 jRVV9dHg7XZkPwpXIhnP55NU99Qw8LOrFruAUVIlHE/ZM2hoQaL2FImqgPUtNx6LCiDjDpxQpI8B gP/sTc+uZbHwmeXnyvze1FmLqWcjxcXRpqQ+36D/Iqe2+C6vRPcGfyDWHlFG+YZfJVrmhQg6kU1X k7osubpVxbgGN/zjd9cLS+HC4FuAdN2kKVtxR5xJ4QYJ/YYd7uv3BmVrnNeh/rYofO4WyPolr5mX Lvo69bR7JxB38YOjnWrwU7Sp7oX8NrgF9OB3LyuNLB+GYQeAgOcDxzZAteduYFVuw75rKyaA3QAA AAAAAA== ------=_NextPart_000_03A4_01CE87BA.D8282720-- From hadriel.kaplan@oracle.com Tue Jul 23 14:11: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 AF87111E8159 for ; Tue, 23 Jul 2013 14:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.061, 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 JkvsOsf0Gbra for ; Tue, 23 Jul 2013 14:10:52 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 96A2E11E8135 for ; Tue, 23 Jul 2013 14:10:50 -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 r6NLAmsg026498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Jul 2013 21:10:49 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 r6NLAm55021740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jul 2013 21:10:48 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 r6NLAmc4021737; Tue, 23 Jul 2013 21:10:48 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 23 Jul 2013 14:10: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: <19893_1374596593_51EEADF1_19893_9071_1_B5939C6860701C49AA39C5DA5189448B0B55A6@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Tue, 23 Jul 2013 17:10:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <15BB6D07-F5D4-4945-80B9-0648CB32A6CA@oracle.com> References: <20130712043221.11767.74779.idtracker@ietfa.amsl.com> <1F4B4D44-BD3E-4995-876A-147832C925F9@oracle.com> <19893_1374596593_51EEADF1_19893_9071_1_B5939C6860701C49AA39C5DA5189448B0B55A6@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: "stir@ietf.org" Subject: Re: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 23 Jul 2013 21:11:00 -0000 Thanks for the review and catching this stuff! More comments inline... On Jul 23, 2013, at 12:23 PM, philippe.fouquart@orange.com wrote: > Just an observation, first. Sometimes in 4.1 and 4.2 (see below), = definitions seem to refer to numbers in general, examples taken from the = NANP,... and some conclusion drawn essentially from an observation on = the example rather than from the definition. :)=20 Ahh sorry. I need to clean the draft up for sure. :) >> IKES also considers toll-free 1-8xx type numbers to be "E.164" = numbers,=20 >> even though technically they are not. >=20 > If the statement is not only about US toll free numbers but on = "freephone" numbers in general ("cc-8xx" being indeed very common for = that), "technically they may not be", would be more accurate I think, on = other CCs some of them are actually reachable from abroad.=20 OK, will fix in next rev. >> Nationally-specific number codes are numbers that are not E.164=20 >> numbers, nor are private numbering plan numbers, but are instead=20 >> number codes used for specific purposes within national numbering=20 >> plans. Examples of these are N11 codes in the NANP, two or three=20 >> digit emergency numbers such as 112, and inter-carrier common short=20= >> codes. Even if they cannot be used as caller-id numbers , they are=20= >> destination numbers and thus IKES needs to support them. =20 >=20 > Actually short codes can sometimes be used as CgPN, again it depends = on the country. Probably not emergency numbers, (although you might even = find corner cases in the European 116 series, some of which qualify as = such in some countries) but short codes can be.=20 I meant to imply that but it didn't come across right - when I said = "Even if they cannot be used as caller-id numbers", I really meant more = "Even for cases where they cannot be used as caller-id numbers". >=20 >> Likewise for nationally-specific number codes, the IKES process=20 >> generates a canonical representation of the number code. A leading=20= >> country-code is prepended to the number code, to indicate the=20 >> national numbering plan they are for. >=20 > I suppose you've been waiting for this but the usual problem of using = such "pseudo E.164 numbers" for non E.164 numbers instead of local = numbers is that, for countries that use national trunk codes eg 0, you = can have an overlap between the short codes and the initial digits of = the E.164 NDC or the SN. It's obviously not a problem as long as we stay = in the dialing plan (actually that's precisely what the national trunk = code is here for, to have more spare values to use) but it seems this = would mean that the assignee of say range 112 could legitimately sign = +CC-112, I'm not sure that's a good thing. (although this particular one = 112 is indeed generally reserved in the national E.164 numbering plan = but I use it to get the picture).=20 Yup, I've been waiting for that. :) So right now in the CIDER draft it talks about there being a different = domain name anchor for E.164s vs. number-codes. So "cid.example.com" = might be the E.164 anchor, while "nid.example.com" might be used for = number-codes. So a key holder for the whole E.164 range prefixed by = +33-112 couldn't successfully sign a number-code of 112 in France, = because the IKES-receiving verifier would look the latter E.164 up as = "2.1.1.3.3.nid.example.com", while the attacker's key is only in = "2.1.1.3.3.cid.example.com" and thus only valid for that number-code. I think I put an example in where they used the same anchor, which is = probably dangerous for the reason you said. If I did, I'll fix it next = rev. >> 10. Usage in SS7/ISUP > [...] >> the signature, key=20 >> index, and timestamp are carried in the User-to-User Information=20 >> parameter ; >=20 > (Noted past exchanges on this. Don't think this was addressed) = Generally speaking, what if the UUI is already used for a different = purpose? (eg RFC 6467 use cases) Yeah, I was waiting for the emails discussion around it to coalesce. I = think the right thing to do would be for RFC 6567 to win - the UUI in = that case is for a end-to-end UUI as used in inter-PBX/inter-branch = cases, so the IKES Generator or SIP-SS7 interworking gateway should not = replace it with the IKES stuff. I'm thinking that's ok, because as far = as I know those inter-PBX cases are already in controlled environments = and don't have a faked caller-id problem from random sources. Yes/no? -hadriel From housley@vigilsec.com Tue Jul 23 14:23:17 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5EB11E839E for ; Tue, 23 Jul 2013 14:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.706 X-Spam-Level: X-Spam-Status: No, score=-102.706 tagged_above=-999 required=5 tests=[AWL=-0.108, 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 nw2H7jCrjCWm for ; Tue, 23 Jul 2013 14:23:08 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 7421911E82F4 for ; Tue, 23 Jul 2013 14:22:53 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 2102CF2407E; Tue, 23 Jul 2013 17:22:57 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 2SfvD3zd-UD8; Tue, 23 Jul 2013 17:22:47 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-154-95.washdc.fios.verizon.net [96.241.154.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 08861F240BA; Tue, 23 Jul 2013 17:22:54 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-102--977108972 From: Russ Housley In-Reply-To: Date: Tue, 23 Jul 2013 17:22:45 -0400 Message-Id: <900A3F5B-4073-4C16-8811-D59DB095B49A@vigilsec.com> References: To: Dan York X-Mailer: Apple Mail (2.1085) Cc: "stir@ietf.org Mail List" Subject: Re: [stir] Link for the latest and greatest draft of the STIR charter? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 23 Jul 2013 21:23:17 -0000 --Apple-Mail-102--977108972 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Here is the latest charter text. I have asked Richard Barnes if he will = put it in the datatracker -- a lowly BOF Chair does not have the = privilege to take this action. Since this was posted, Cullen had asked for the in-band and out-of-band = mechanisms to be worked on in parallel (instead of in series). There = was clearly push back on this idea. I expect this will be discussed = further at the BOF. Russ =3D =3D =3D =3D =3D =3D =3D =3D =3D Name: Secure Telephone Identity Revisited (stir) Area: RAI Chairs: TBD Area Advisor: Richard Barnes Mailing list: stir@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/stir 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. As with email, the claimed source identity of a SIP request is not verified, and this permits unauthorized use of source identities as part of deceptive and coercive activities, such as robocalling (bulk unsolicited commercial communications), vishing (voicemail hacking, and impersonating banks) and swatting (impersonating callers to emergency services to stimulate unwarranted large scale law enforcement deployments). This working group will define a deployable mechanism that verifies the authorization of the calling party to use a particular telephone number. SIP is one of the main VoIP technologies used by parties that want to present an incorrect origin, in this context an origin telephone number. Several previous efforts have tried to secure the origins of SIP communications, including RFC 3325, RFC 4474, and the VIPR working = group. To date, however, true validation of the source of SIP calls has not = seen any appreciable deployment. Several factors contributed to this lack of success, including: failure of the problem to be seen as critical at the time; lack of any technical means of producing a proof of authority over telephone numbers; misalignment of the mechanisms proposed by RFC 4474 with the complex deployment environment that has emerged for SIP; lack = of end-to-end SIP session establishment; and inherent operational problems with a transitive trust model. To make deployment of this solution more likely, consideration must be given to latency, real-time performance, computational overhead, and administrative overhead for the legitimate call source and all verifiers. As its first work item, the working group will specify a SIP = header-based authorization mechanism to verify the originator of a SIP session is authorized to use the claimed source telephone number, where the session is established with SIP end to end. This is called an in-band = mechanism. The mechanism will use a canonical telephone number representation specified by the working group, including any mappings that might be needed between the SIP header fields and the canonical telephone number representation. The working group will consider choices for protecting identity information and credentials used, but will likely be based on a digital signature mechanism that covers a set of information in the SIP header fields, and verification will employ a credential that contains the public key and is associated with the one or more telephone numbers. In order to be authoritative, credentials used with this mechanism will be derived from existing telephone number assignment and delegation models. That is, when a telephone number or range of telephone numbers is delegated to an entity, relevant credentials will be generated (or modified) to reflect such delegation. The mechanism must allow a telephone number holder to further delegate and revoke use of a=20 telephone number without compromising the global delegation scheme. The mechanism must allow parties who are not delegated a telephone number, but are authorized by the entity who is delegated the number, to place calls using the identity. After completing the in-band mechanism, the working group will consider session establishment where there are one or more non-SIP hops, most likely using an out-of-band authorization mechanism. However, the in-band and the out-of-band mechanisms should share as much in common as possible, especially the credentials. Expansion of the authorization mechanism to identities using the user@domain form deferred since the main focus of the working group is = to develop a solution for telephone numbers. The working group will coordinate with the Security Area on credential management. The working group will coordinate with other working groups in the RAI Area regarding signaling through existing deployments. Authentication and authorization of identity is closely linked to privacy, and these security features frequently come at the cost of privacy. 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. 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 The working group will deliver the following: - A problem statement detailing the deployment environment and situation that motivate work on secure telephone identity - A mechanism document describing the SIP end-to-end with telephone number-based identities=20 - A document describing the credentials required to support telephone number identity authentication - A fallback mechanism to allow out-of-band identity establishment during call setup Milestones Sep 2013 Submit problem statement for Informational Nov 2013 Submit in-band mechanism for Proposed Standard Feb 2014 Submit credential specification for Proposed Standard Jun 2014 Submit fallback for Proposed Standard On Jul 23, 2013, at 11:43 AM, Dan York wrote: > I'm looking for a link to the latest draft of the STIR charter to pass = along to some folks interested in this work. Russ and Brian sent a = revised draft to the list on July 11: >=20 > http://www.ietf.org/mail-archive/web/stir/current/msg00785.html >=20 > which generated a lengthy discussion whose offshoots are still = ongoing. Russ and Brian, will you be updating the draft charter = before the meeting? =20 >=20 > And is there a URL I can pass along that points to the latest draft = charter for a BOF? I.e. a static link as there is for a working group = charter? Or do BOF charters only live in email lists? (My apologies = for my ignorance on this but with the BOFs with which I have been = involved in the past the charters have not been under such vigorous = discussion and so the link to an email message *could* be sent around or = posted on a web page as "the" charter for the upcoming BOF.) >=20 > Thanks, > 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 --Apple-Mail-102--977108972 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Here = is the latest charter text.  I have asked Richard Barnes if he will = put it in the datatracker -- a lowly BOF Chair does not have the = privilege to take this action.

Since this was posted, = Cullen had asked for the in-band and out-of-band mechanisms to be worked = on in parallel (instead of in series).  There was clearly push back = on this idea.  I expect this will be discussed further at the = BOF.

Russ

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


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

Chairs: TBD
Area Advisor: Richard = Barnes

Mailing list: stir@ietf.org

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.  As with email, the claimed = source identity of a SIP
request is not verified, and this = permits unauthorized use of source
identities as part of = deceptive and coercive activities, such as
robocalling (bulk = unsolicited commercial communications), vishing
(voicemail = hacking, and impersonating banks) and swatting = (impersonating
callers to emergency services to stimulate = unwarranted large scale law
enforcement deployments). =  This working group will define a deployable
mechanism = that verifies the authorization of the calling party to use
a = particular telephone number.

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

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

The mechanism must allow = parties
who are not delegated a telephone number, but are = authorized by the
entity who is delegated the number, to place = calls using the identity.

After completing the = in-band mechanism, the working group will consider
session = establishment where there are one or more non-SIP hops, = most
likely using an out-of-band authorization mechanism. =  However, the
in-band and the out-of-band mechanisms = should share as much in common as
possible, especially the = credentials.

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

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

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

Authentication and authorization = of identity is closely linked to
privacy, and these security = features frequently come at the cost of
privacy.  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.

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
  Secure Origin Identification: Problem Statement, = Requirements,
  and Roadmap
<= br>
  Authenticated Identity Management in the Session = Initiation
  Protocol (SIP)
=

The working group will deliver the = following:

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

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

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

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

Milestones

Sep = 2013   Submit problem statement for Informational
Nov = 2013   Submit in-band mechanism for Proposed Standard
Feb = 2014   Submit credential specification for Proposed = Standard
Jun 2014   Submit fallback for Proposed = Standard



On = Jul 23, 2013, at 11:43 AM, Dan York wrote:

I'm looking for a link to the latest draft of the STIR charter to = pass along to some folks interested in this work.  Russ and Brian = sent a revised draft to the list on July 11:


which generated a lengthy discussion whose offshoots are still = ongoing.    Russ and Brian, will you be updating the draft = charter before the meeting?  

And is there a URL I can pass along that points to the latest draft = charter for a BOF?  I.e. a static link as there is for a working = group charter?  Or do BOF charters only live in email lists?   = (My apologies for my ignorance on this but with the BOFs with which I have been involved in the past the charters have not been = under such vigorous discussion and so the link to an email message = *could* be sent around or posted on a web page as "the" charter for the = upcoming BOF.)

Thanks,
Dan

--
Dan York
Senior Content Strategist, = Internet Society
york@isoc.org <mailto:york@isoc.org>   = +1-802-735-1624
_______________________________________________
stir mailing = list
stir@ietf.org
https://www.ietf.org/m= ailman/listinfo/stir

= --Apple-Mail-102--977108972-- From hadriel.kaplan@oracle.com Tue Jul 23 14:38: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 D21E011E82F4 for ; Tue, 23 Jul 2013 14:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.39 X-Spam-Level: X-Spam-Status: No, score=-6.39 tagged_above=-999 required=5 tests=[AWL=-0.106, 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 Ndw2P6GsnCbB for ; Tue, 23 Jul 2013 14:38:44 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9754411E82D6 for ; Tue, 23 Jul 2013 14:38:43 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6NLcfS3020436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Jul 2013 21:38:42 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 r6NLcecA028302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jul 2013 21:38:41 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6NLce0J028287; Tue, 23 Jul 2013 21:38:40 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 23 Jul 2013 14:38: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: <00C069FD01E0324C9FFCADF539701DB3BBC1C956@EX2K10MB1.corp.yaanatech.com> Date: Tue, 23 Jul 2013 17:38:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00C069FD01E0324C9FFCADF539701DB3BBC1A683@EX2K10MB1.corp.yaanatech.com> <6EF50BDB-3F41-49FE-83C1-20216D0D0BF0@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1BE03@EX2K10MB1.corp.yaanatech.com> <0073993E-1BC8-461C-9A7E-B5DCFC617DBF@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1C956@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] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 21:38:51 -0000 On Jul 23, 2013, at 3:39 PM, Michael Hammer = wrote: > You keep saying that the SPs would keep the private keys in servers = for some > reason. > While they need their own keys for administrative actions, > The private keys associated with the end-user certs should not be = stored. > I think you are assuming that the SP signs for the calling party. > I am assuming that the calling party signs themselves. (SIP Internet = case) I was wondering if that was what you meant. You're right - I assume no = matter what happens, that most of the SPs will be signing for some = significant portion of their subscriber calling parties. That way they = can sign for the billions of E.164 caller-id's they control, that are = not smartphones, won't be upgraded, etc. I also think they'll be = signing on behalf of most Enterprise-originated calls too, for that = matter. I don't think I'm the only one with that assumption, BTW. At the end of = the day, most SIP service providers provide a service, and most of their = customers expect them to do it. Even for Enterprise cases, most = Enterprises in the World don't have SIP/VoIP expertise, don't use = Asterix, and don't want to deal with the details - they pay a service = provider to provide phone-call-type service, and they expect to get = their money's worth. When something goes wrong, they want to be able to = yell at someone else to fix it. There are exceptions of course - for = example very large corporations and companies for whom phone service is = their business (e.g., call-centers), and of course there are always = folks who are unique; but for most folks it's a service they use, not = something they want to worry about programming. > Lastly, I can summarize you last 4 paragraphs: > So long as we maintain the current hierarchy of service providers, = then it > will scale. > That seems like a public policy question, so I won't go there. Totally. But that's implied in the concept of not making the STIR data = publicly available, isn't it? I mean if SIP were used on the public = Internet in an open manner, like email, but the STIR data was = access-controlled, how would the administrative burden of = access-controlling it scale even for HTTP? It's not like writing a = script to query the whole database using HTTP is that difficult. And = it's not like a username/password prevents anything - it just requires = you to get a username/password. It's not like just anybody who passes a = captcha test and has a personal email account somewhere; in fact we = can't even just only let "corporations" access it. The implied problem = here is we don't want to give just anyone access - only "very special" = someones. So who are the very special someones? How does it = administratively scale to have millions of very special someones, on a = World-wide basis, for just one database admin/company to control? And = why wouldn't or shouldn't the STIR access-control model follow the = PSTN/SIP hierarchy model, since they're the ones who are legally = assigned E.164 numbers to begin with? -hadriel From richard@shockey.us Tue Jul 23 15:18: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 9B0E911E8163 for ; Tue, 23 Jul 2013 15:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.108 X-Spam-Level: X-Spam-Status: No, score=-102.108 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 AwZR8YbgUwNa for ; Tue, 23 Jul 2013 15:18:38 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 6B37811E814F for ; Tue, 23 Jul 2013 15:18:27 -0700 (PDT) Received: (qmail 22785 invoked by uid 0); 23 Jul 2013 22:17:49 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.bluehost.com with SMTP; 23 Jul 2013 22:17:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=p8yhEqHeUQpAfR2v09Q1bBF4UpwLUgyshr0EAWGg48U=; b=SQ7+PrmY+QPHjg7c9S3NSbsECEPYcU2L0XqEXTkxJPZ1g8ZBxBGpu2CcNAAxJDVuJJc1SgEGIkskFsi9+Y+iK4b/QZ7fVBADt9+QAkgfZkQrVvSqVclxu+xw1Jysv+XT; Received: from [72.66.111.124] (port=59404 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V1ktw-0003Co-6B for stir@ietf.org; Tue, 23 Jul 2013 16:17:48 -0600 From: "Richard Shockey" To: References: <00C069FD01E0324C9FFCADF539701DB3BBC1A683@EX2K10MB1.corp.yaanatech.com> <6EF50BDB-3F41-49FE-83C1-20216D0D0BF0@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1BE03@EX2K10MB1.corp.yaanatech.com> <0073993E-1BC8-461C-9A7E-B5DCFC617DBF@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1C956@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Date: Tue, 23 Jul 2013 18:17:45 -0400 Message-ID: <011401ce87f2$75e5e880$61b1b980$@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: AQKGYdESuNaKYzjA1MOVC/t4WgLNfwFqNPDrAOTUU78BYLTRJAGN7elAAkH22Z2XxyEXkA== 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] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 22:18:43 -0000 +1 People pay for a service and contrary to popular opinion SIP/IMS is actually a good business for service providers. I have zero confidence calling party is going to sign for themselves for much the same reason I don't have a lot of confidence that we will see handsets actually doing the validation in significant numbers. I pay people to run the SMTP email servers for my domain. I expect them to implement tools to reduce SPAM or I will just "port" my domain elsewhere. As for the policy questions here .. they are not going away but at least the structure of authority in E.164 is well known, definable, and in the case of the US portions of the NANP the Authority to Act is considered plenary and fully tested in the courts. Section 251(e) [1] of the US Act for you budding amateur teleco lawyers out there. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Tuesday, July 23, 2013 5:39 PM To: Michael Hammer Cc: stir@ietf.org Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) On Jul 23, 2013, at 3:39 PM, Michael Hammer wrote: > You keep saying that the SPs would keep the private keys in servers > for some reason. > While they need their own keys for administrative actions, The private > keys associated with the end-user certs should not be stored. > I think you are assuming that the SP signs for the calling party. > I am assuming that the calling party signs themselves. (SIP Internet > case) I was wondering if that was what you meant. You're right - I assume no matter what happens, that most of the SPs will be signing for some significant portion of their subscriber calling parties. That way they can sign for the billions of E.164 caller-id's they control, that are not smartphones, won't be upgraded, etc. I also think they'll be signing on behalf of most Enterprise-originated calls too, for that matter. I don't think I'm the only one with that assumption, BTW. At the end of the day, most SIP service providers provide a service, and most of their customers expect them to do it. Even for Enterprise cases, most Enterprises in the World don't have SIP/VoIP expertise, don't use Asterix, and don't want to deal with the details - they pay a service provider to provide phone-call-type service, and they expect to get their money's worth. When something goes wrong, they want to be able to yell at someone else to fix it. There are exceptions of course - for example very large corporations and companies for whom phone service is their business (e.g., call-centers), and of course there are always folks who are unique; but for most folks it's a service they use, not something they want to worry about programming. > Lastly, I can summarize you last 4 paragraphs: > So long as we maintain the current hierarchy of service providers, > then it will scale. > That seems like a public policy question, so I won't go there. Totally. But that's implied in the concept of not making the STIR data publicly available, isn't it? I mean if SIP were used on the public Internet in an open manner, like email, but the STIR data was access-controlled, how would the administrative burden of access-controlling it scale even for HTTP? It's not like writing a script to query the whole database using HTTP is that difficult. And it's not like a username/password prevents anything - it just requires you to get a username/password. It's not like just anybody who passes a captcha test and has a personal email account somewhere; in fact we can't even just only let "corporations" access it. The implied problem here is we don't want to give just anyone access - only "very special" someones. So who are the very special someones? How does it administratively scale to have millions of very special someones, on a World-wide basis, for just one database admin/company to control? And why wouldn't or shouldn't the ST IR access-control model follow the PSTN/SIP hierarchy model, since they're the ones who are legally assigned E.164 numbers to begin with? -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From jon.peterson@neustar.biz Tue Jul 23 18:26: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 6951B11E81B1 for ; Tue, 23 Jul 2013 18:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.641 X-Spam-Level: X-Spam-Status: No, score=-105.641 tagged_above=-999 required=5 tests=[AWL=0.959, 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 azgHitWNq6bV for ; Tue, 23 Jul 2013 18:26:52 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 36BE811E81A6 for ; Tue, 23 Jul 2013 18:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1374629122; x=1689978328; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=ycQxpwnx8i yP3522QiObooDBjHfZFb3MlFFjYCx/a1o=; b=bo5GlrJd2aCVpJmYkXrmzFBmQe lX2KXDgF0wRs7ToiMCnEzaUoW4NAgwZ38ZO2mLtDZK4aR/OFxjxuN+6cgeog== Received: from ([10.31.58.70]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.21411898; Tue, 23 Jul 2013 21:25:21 -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, 23 Jul 2013 21:26:41 -0400 From: "Peterson, Jon" To: Hadriel Kaplan , Henning Schulzrinne Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) - attack model Thread-Index: AQHOhN3XlLvfS0GEU02eRKlH1yvyDZltRmkAgAEf8ACAABBBAIAAAhKAgAAO24CAAQXHgIADUFyA Date: Wed, 24 Jul 2013 01:26:41 +0000 Message-ID: In-Reply-To: <04608538-7A05-4F63-AC8F-E9BC63149A01@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.149] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: GGrJbuLUzq5MYWjwle48Zg== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org Mail List" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jul 2013 01:26:56 -0000 I've been arguing that we hedge our bets too, but perhaps that we hedge them even more than you consider below. (Forgive me that I haven't closely tracked your tight loop with Mike Hammer, in case it sheds any light I miss here.) RFC4474 (/RFC4474bis) doesn't restrict access to certificates to HTTP fetches. RFC4474 is pretty agnostic about how you get certs. We talked about certs being included in SIP messages, so they'd arrive along with the signature. We talked about using SIP itself to fetch them, via SUBSCRIBE. We considered cases where verifiers had access to caches, or even local cert stores. At the time we were doing RFC4474, HTTP seemed like the right thing to hype for a number of reasons, so we encouraged it. But the URL in Identity-Info is just supposed to be a helpful suggestion, not the sole and authoritative means of access to certs. For the STIR case, however, that hint might be useful to disambiguate for verifiers which authority signed a SIP request, when there are multiple authorities for a single number (the function the CIDER "public key index value" would serve, if I understand correctly). Part of the reason I think we're all talking past each other here is that certs are relatively self-contained documents, and you could get them in a number of ways, and I don't think there's any pressing need for us to restrict those ways. For DNS proposals (if they don't just stick CA certs in the DNS), on the other hand, the way you get a credential is inextricably coupled to the semantics of the credential itself, which is why the CIDER proposal isn't just a protocol, it's a whole deployment architecture. The credentials lose any semantics if they are divorced from the deployment environment you're supposed to fetch them from. All credentials must be uploaded through that central service and all credentials must be downloaded from its (distributed) deployment. There doesn't need to be a "national authority" cloud service that manages access to certs in this way. The reason you trust a cert isn't because you downloaded it from the right place, it's because you trust the trust anchor that signed the cert. This isn't about HTTP - it doesn't matter if you found the cert lying on the ground. This is why I don't understand the need for "hard cider," or indeed why it would be important for a verification service to be able to derive a single canonical location from which it will download a cert by studying the originating number alone. I kind of see why this is important for a DNS-based solution (though the harm DNS URI Identity-Info would do there isn't clear to me - if it points to something you don't trust, don't trust it), but not for a cert-based solution. If you could, for example, just receive the cert in-band with the request, that would seem to obviate the need to go ask anyone for it. I'm a bit unsure as well of the high-level structure of the arguments below, effectively that carriers are the only sorts of verifiers that matter, and that carriers probably can't use anything other than DNS. Carriers do matter, and so do enterprises, and so do endpoints, as potential verifiers. Of course it's true that carriers use DNS, as do enterprises and endpoints. But none of them perform anything like the STIR in-band verifier function today, and new code will have to be written and new stuff deployed to make this happen - arguing that this has to be the same stuff that's used for an unrelated existing function in the network just doesn't persuade, given the huge differences in usage. I don't think it would be unreasonable for DNS to play a role in credential delivery to verifiers, for environments where it makes sense. I don't see how this proposed use of the DNS has some decisive advantage over certificates, though. This makes me want to hedge bets from the start. I think the flexibility of something like Identity-Info is a way to approach that. Jon Peterson Neustar, Inc. On 7/21/13 8:50 AM, "Hadriel Kaplan" wrote: > >I've been thinking about your questions and it occurred to me we may be >talking past each other, or I'm not being clear enough. It's hard to >discuss some of this stuff in email, but anyway let me try a different >tack... > >So far, there is one relatively concrete proposal for how HTTP would be >used: RFC4474 or 4474bis, which use certs signed by someone, and >indicates where to get the cert in an HTTP URL encoded in the SIP message >Identity-Info header. That model has a whole host of issues, and if by >"HTTP" you mean that model, then we could drill-down on the practical >problems I believe it would have. > >There is another way it could work using HTTP, which is essentially to >copy the CIDER proposal but replace the DNS query-answer with HTTP >query-answer. The verifier would generate its own HTTP URL to resolve, >based on the received identity information in SIP, and we'd define how it >does that, what the cert model and encoding would be, how it gets secured >redirection, how it times out cached copies, how to get the cert signer's >cert, how to time that out, etc. Let's call such a model "HARD CIDER", >for "Http-based Access of Registry Data" or some such.[1] > >For a Hard Cider model to be used in a public Internet access model, we'd >still be relying on DNS and DNSSEC, to perform resolution of the HTTP URL >in a secure manner. And using a generated HTTP URL implies the national >registries are deployed as a Google/Facebook/Amazon type cloudy >infrastructure with internal horizontal scaling technologies, etc. But >let's ignore that for now. > >The bigger problem is the target user environment: where we expect to be >using this stuff, in carriers. In practice, HTTP isn't frequently used >by real-time call-handling network devices in most carriers. It is used >by the carrier as a corporation of course, in various other >areas/groups/functions; and it's used in some call-control cases, usually >by application servers providing features for specific users or calls, in >specific scenarios. It's far less common to have it used for every call, >and essentially never gets used by SBCs or X-CSCFs on an every-call >basis. There are a variety of practical reasons for that, but it doesn't >really matter why. What matters is it would be a barrier to >deployability and adoption, in the real world, if we chose it. > >Arguably, DIAMETER is a far more common protocol for many carriers to use >for this type of stuff than HTTP or even DNS. DIAMETER has its own >challenges in actual carrier deployments, mostly around scalability and >manageability, but we couldn't pick DIAMETER anyway because it's only >used in some carriers and not all carriers, and rarely used by anyone >else. > >As a protocol, DNS happens to be used by everyone - it's only used as >private ENUM by some carriers not all obviously, but virtually all of >them use DNS for at least hostname resolution, even internally. And DNS >client implementation happens to be available in code in all systems, >whether it be SBCs or X-CSCFs or app servers or whatever; and its >performance, scalability and manageability characteristics happen to be >really good in actual carrier deployments. > >Having said all that, another way we could go in STIR is to just hedge >our bets and define multiple protocols: DNS, HTTP, and maybe even >DIAMETER. To do that, though, it still has to be deployable as DNS, >still have to be based on the verifier generating the URL and not have it >sent by the originator, still have to specify the caching and clearing >behavior, still have to support both a centralized and distributed model >of database deployment for numbers, etc. We've done that sort of hedging >before in the IETF, rarely - it's a LOT more work, obviously, but it lets >the market decide for itself what to do. > >If we do hedge our bets, however, I believe the most straight-forward way >to actually do that would be to define the DNS one *first*, and then >figure out the HTTP or DIAMETER mechanics required for doing the same >things accessing stuff from a deployed DNS database infrastructure. >That's because DNS as a protocol already defines the semantics, >mechanics, and database structure; and if its used in a public Internet >access manner then it's The Public DNS. So a use of HTTP or DIAMETER >would need to access it and follow its behavior. And that has some >bizarre deployment expectations for all parties, for example for >international call scenarios, or for an email-style identity model. > >A more reasonable approach might be to define the DNS model, and then >only define how an HTTP or DIAMETER access to the local DNS resolver >could also work, where the verifier can only be a stub. That's still a >lot of work, and still involves localhost caching rules and such, but at >least it constrains the problem somewhat. > >-hadriel >[1] I don't use the term "hard" to mean it will be hard, but rather >because "hard cider" happens to be a specific form of the drink known as >cider. :) > > >On Jul 20, 2013, at 8:13 PM, Hadriel Kaplan >wrote: > >>=20 >> On Jul 20, 2013, at 7:20 PM, Henning Schulzrinne >> wrote: >>=20 >>> I don't see the "benefit" of DNS here. There are two cases, either way: >>>=20 >>> (1) A standard DNS hierarchy, with caching, but no synchronization. In >>>that case, you need short TTLs if you care about revocation. With short >>>TTLs, you get one country-level RTT for every query, even assuming no >>>packet loss. >>=20 >> By "one country-level RTT for every query", do you mean you get one RTT >>on average for every call, and the RTT is likely not long on average >>because it's to a server in your geographic country? If so, sure that >>would likely be the case for public internet access queriers. One RTT >>on average, for a public Internet access model is pretty good, BTW. >>HTTP really won't have one RTT for such public Internet access, not in >>actual practice if this Identity-Info URL model is used. Again, this is >>not CIDER's raison d'etre, but just another plus. >>=20 >>=20 >>> (2) A locally-cached synchronized DNS hierarchy, using some kind of >>>rsync-like mechanism. >>>=20 >>> You can get the same two versions for HTTP and certs. >>=20 >> No, I really don't believe you can. You can get them if we give up on >>the Identity-Info URL thing, and define how HTTP would work without it, >>how the international call thing works, and so on. But not if the cert >>is served on some random server indicated by the Identity-Info header. >>=20 >>=20 >>> The locally-cached synchronized DNS has essentially the same overhead >>>as the locally-cached HTTP version, since the connection is nailed down. >>=20 >> Define "overhead". Overhead for whom? For the verifier systems HTTP >>is more overhead - a trivial amount if the stars align, and more if >>reality is included in the equation; but not a massive amount >>regardless. For the carriers, HTTP is more cost and operational >>overhead from a deployment perspective if reality is included, but again >>if we ignore practical realties then it's all equal. So sure, if all >>carriers in all nations deploy Google or Facebook style infrastructures >>and tweak their verifiers' TCP and HTTP implementations - all for the >>benefit of verifying a caller-id - then we're all good-to-go. ;) >>=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 From fluffy@cisco.com Tue Jul 23 20: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 EFCBB11E834A for ; Tue, 23 Jul 2013 20:56:50 -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 PJWMdDZegx1U for ; Tue, 23 Jul 2013 20:56:37 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id EB5BF11E8347 for ; Tue, 23 Jul 2013 20:56:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=980; q=dns/txt; s=iport; t=1374638197; x=1375847797; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=N+x3PcVMOY24aAzz5knvY83YLTXXq6CDi8V+XmH+Jzg=; b=P50ywsfD8cvJrfFigb5utNR19bdc5NxFJiPi/U45w1czFRzVxSZwfyPY l3f7F0LrdxI4iy+clqGjpZ2Cu7pzcGzBybhjZx3CCLEKfQ26pLQeXOh0Q 9P1iQT1PAyUtDc1TajwFX2QCPp5+pLJC9P8j9somXli28tsxVJUOnB870 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQFAOdP71GtJV2c/2dsb2JhbABbgwaBBYJCvj2BFBZ0giQBAQEDATotEgULAgEIIhQQMiUCBA4FCIgCBrgfj0cCMQeDEm4DqSyDFIIq X-IronPort-AV: E=Sophos;i="4.89,732,1367971200"; d="scan'208";a="238692486" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 24 Jul 2013 03:56:35 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6O3uZIr014451 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Jul 2013 03:56:35 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Tue, 23 Jul 2013 22:56:35 -0500 From: "Cullen Jennings (fluffy)" To: Hadriel Kaplan Thread-Topic: [stir] Draft STIR Charter - out of band Thread-Index: AQHOiCHKlKg6nb6y20im3eXea/7AVQ== Date: Wed, 24 Jul 2013 03:56:34 +0000 Message-ID: References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> <457ED3A0-D8D1-4420-A2C3-5B07B16AE641@vigilsec.com> <8D3E41B3-6A3B-4982-8193-C975A3C867BB@oracle.com> In-Reply-To: <8D3E41B3-6A3B-4982-8193-C975A3C867BB@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <8DD20EE6E59BE646BED63A0B09F57CA7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF STIR Mail List Subject: Re: [stir] Draft STIR Charter - 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, 24 Jul 2013 03:56:51 -0000 On Jul 20, 2013, at 12:34 AM, Hadriel Kaplan wr= ote: > The "traditional" and regulated carriers, MSOs, etc., are the ones who w= ant to stop it. I don't really agree with this. If this was true, the class 5 switch that m= y ISDN trunk connects to would only allow me to assert the caller ID on the= ISDN trunk for numbers assigned to me. However, because I am the customer,= and I like to be able to set whatever caller ID I want, and my service pro= vider makes me happy as a customer. Many providers in the US are very happy= to provide me with a ISDN trunk that allows me to set whatever caller ID I= want. I will note this include the bulk of the large carriers with good r= eputations, it's not just fringy operators. I think the key thing is that carriers largely try and meet the needs of th= eir customers. And their customs are often the people that make robo calls,= as well as the people that receive them.=20 From dhc@dcrocker.net Tue Jul 23 21:34: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 A1AEB11E81DF for ; Tue, 23 Jul 2013 21:34: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 I9AATxZQvz85 for ; Tue, 23 Jul 2013 21:33:55 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3F37011E8183 for ; Tue, 23 Jul 2013 21:33:55 -0700 (PDT) Received: from [10.0.0.252] (host217-40-191-246.in-addr.btopenworld.com [217.40.191.246]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r6O4XjYw021117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Jul 2013 21:33:51 -0700 Message-ID: <51EF5925.8090904@dcrocker.net> Date: Wed, 24 Jul 2013 05:33:41 +0100 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Richard Shockey References: <00C069FD01E0324C9FFCADF539701DB3BBC1A683@EX2K10MB1.corp.yaanatech.com> <6EF50BDB-3F41-49FE-83C1-20216D0D0BF0@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1BE03@EX2K10MB1.corp.yaanatech.com> <0073993E-1BC8-461C-9A7E-B5DCFC617DBF@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1C956@EX2K10MB1.corp.yaanatech.com> <011401ce87f2$75e5e880$61b1b980$@shockey.us> In-Reply-To: <011401ce87f2$75e5e880$61b1b980$@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, 23 Jul 2013 21:33:54 -0700 (PDT) Cc: stir@ietf.org Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) 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, 24 Jul 2013 04:34:00 -0000 On 7/23/2013 11:17 PM, Richard Shockey wrote: > I pay people to run the SMTP email servers for my domain. I expect them to > implement tools to reduce SPAM or I will just "port" my domain elsewhere. This highlights a core bit of confusion in this discussion. It concerns the non-normative, architectural difference between may and must. If the technology permits signing and validating use by end-systems (users, enterprises, whatever), then they have the /option/ of doing STIR. The fact that operational convenience makes is strongly likely that most/all use will be by intermediary systems such as service providers, rather than end-systems, is only that: operational choice. If the design restricts use to providers, then there is no opportunity for enterprises or end-users to sign or validate. Believe it or not, some individuals and some enterprises still run their own SMTP servers. That folk like you and me don't does not make it reasonable to prevent others from doing it. d/ ps. DKIM is an example of this choice; it's almost exclusively deployed amongst service hosts; but in fact the architecture permits operation with user agents. -- Dave Crocker Brandenburg InternetWorking bbiw.net From philippe.fouquart@orange.com Wed Jul 24 02:57:15 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C77C11E839C for ; Wed, 24 Jul 2013 02:57:15 -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, NORMAL_HTTP_TO_IP=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 OHwbzvRBOTyx for ; Wed, 24 Jul 2013 02:57:09 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id A549411E8156 for ; Wed, 24 Jul 2013 02:57:09 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id E1990324578; Wed, 24 Jul 2013 11:57:07 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id C469C23804B; Wed, 24 Jul 2013 11:57:07 +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, 24 Jul 2013 11:57:07 +0200 From: To: Hadriel Kaplan Thread-Topic: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt Thread-Index: AQHOfrnJIrVpZ/tZPUKeljXpre8LSZlychJwgABBJQCAANhWAA== Date: Wed, 24 Jul 2013 09:57:07 +0000 Message-ID: <7699_1374659827_51EFA4F3_7699_4570_1_B5939C6860701C49AA39C5DA5189448B0B576C@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <20130712043221.11767.74779.idtracker@ietfa.amsl.com> <1F4B4D44-BD3E-4995-876A-147832C925F9@oracle.com> <19893_1374596593_51EEADF1_19893_9071_1_B5939C6860701C49AA39C5DA5189448B0B55A6@PEXCVZYM12.corporate.adroot.infra.ftgroup> <15BB6D07-F5D4-4945-80B9-0648CB32A6CA@oracle.com> In-Reply-To: <15BB6D07-F5D4-4945-80B9-0648CB32A6CA@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.7.24.85422 Cc: "stir@ietf.org" Subject: Re: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jul 2013 09:57:15 -0000 Thanks for clarifying. A follow-up on the last two points, in-line.=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, July 23, 2013 11:11 PM To: FOUQUART Philippe OLNC/OLN Cc: stir@ietf.org Subject: Re: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt [snip]=20 >=20 >> Likewise for nationally-specific number codes, the IKES process=20 >> generates a canonical representation of the number code. A leading=20 >> country-code is prepended to the number code, to indicate the=20 >> national numbering plan they are for. >=20 > I suppose you've been waiting for this but the usual problem of using suc= h "pseudo E.164 numbers" for non E.164 numbers instead of local numbers is = that, for countries that use national trunk codes eg 0, you can have an ove= rlap between the short codes and the initial digits of the E.164 NDC or the= SN. It's obviously not a problem as long as we stay in the dialing plan (a= ctually that's precisely what the national trunk code is here for, to have = more spare values to use) but it seems this would mean that the assignee of= say range 112 could legitimately sign +CC-112, I'm not sure that's a good = thing. (although this particular one 112 is indeed generally reserved in th= e national E.164 numbering plan but I use it to get the picture).=20 Yup, I've been waiting for that. :) So right now in the CIDER draft it talks about there being a different doma= in name anchor for E.164s vs. number-codes. So "cid.example.com" might be = the E.164 anchor, while "nid.example.com" might be used for number-codes. = So a key holder for the whole E.164 range prefixed by +33-112 couldn't succ= essfully sign a number-code of 112 in France, because the IKES-receiving ve= rifier would look the latter E.164 up as "2.1.1.3.3.nid.example.com", while= the attacker's key is only in "2.1.1.3.3.cid.example.com" and thus only va= lid for that number-code. I think I put an example in where they used the same anchor, which is proba= bly dangerous for the reason you said. If I did, I'll fix it next rev. [PhF] Thanks, I get the picture now (apologies maybe I should have started = with cider, always better to start with the lighter stuff first).=20 I find the term canonical a bit misleading then for two reasons:=20 - the point of converting into a canonical form to me is to have a unique f= orm upon which all subsequent operations can be done whilst the non canonic= al form and related information that lead to it may be discarded altogether= . I now understand why the draft insists on the IKES Generator using the "s= ource identity type" in addition to the "canonical identity", it's just tha= t having two distinct numbers (albeit of a different nature) leading to exa= ctly the same "canonical" string to be processed and signed differently dep= ending on their 'type' is quite confusing.=20 - "canonical [E.164] form" for a number is as you know a very common term t= o describe the international E.164 format of a number stripped out of the v= isual separators. The canonical form in the draft is not that, well, expect= for the E.164 numbers... I wouldn't like this "canonical" form to appear '= as is' in RU/To or From, for that matter, as I said in some numbering plans= in would be problematic.=20 Maybe that would be preferable to use a different term; if you'd rather not= , maybe you want to add something along the lines of 3966 that says that "c= onverting a nationally-specific number code into its canonical form/string = does not make it a valid E.164 number: the string consisting of the leading= country-code prepended to the number code cannot be assumed to be a valid = E.164 number"=20 >> 10. Usage in SS7/ISUP > [...] >> the signature, key=20 >> index, and timestamp are carried in the User-to-User Information=20 >> parameter ; >=20 > (Noted past exchanges on this. Don't think this was addressed) Generally = speaking, what if the UUI is already used for a different purpose? (eg RFC = 6467 use cases) Yeah, I was waiting for the emails discussion around it to coalesce. I thi= nk the right thing to do would be for RFC 6567 to win - the UUI in that cas= e is for a end-to-end UUI as used in inter-PBX/inter-branch cases, so the I= KES Generator or SIP-SS7 interworking gateway should not replace it with th= e IKES stuff. I'm thinking that's ok, because as far as I know those inter= -PBX cases are already in controlled environments and don't have a faked ca= ller-id problem from random sources. Yes/no? [PhF] (thanks, sorry mistyped the rfc number) Well, sort of: a) not all of = them are in "controlled environments" b) it is not uncommon in national "PS= TN" interconnect offerings to support this and pass it on transparently and= c) this type of access may actually be the source if not maliciously-faked= , at least erroneously-configured caller-id. Maybe for c) depending on thei= r use of the UUI, they could privately/bilaterally come up with an index of= sort to assert the "on-net" calls, but I think that's just too complex. ___________________________________________________________________________= ______________________________________________ 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 stephen.farrell@cs.tcd.ie Wed Jul 24 03:44: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 8980311E83CC for ; Wed, 24 Jul 2013 03:44:54 -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 Nv4Irc-5GPQG for ; Wed, 24 Jul 2013 03:44:50 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B17D511E8191 for ; Wed, 24 Jul 2013 03:44:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 005ACBE88; Wed, 24 Jul 2013 11:44:27 +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 8bI-WD+zdCzr; Wed, 24 Jul 2013 11:44:27 +0100 (IST) Received: from [IPv6:2001:770:10:203:bdef:eca1:a64f:4f6a] (unknown [IPv6:2001:770:10:203:bdef:eca1:a64f:4f6a]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C5B15BE5C; Wed, 24 Jul 2013 11:44:27 +0100 (IST) Message-ID: <51EFB00C.3050602@cs.tcd.ie> Date: Wed, 24 Jul 2013 11:44:28 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Peterson, Jon" References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "stir@ietf.org Mail List" , Hadriel Kaplan , Henning Schulzrinne Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jul 2013 10:44:54 -0000 Hi Jon, I think you make some reasonable points below, but wanted to add a bit to one of 'em. I've no position on whether or not STIR ought hedge its bets on credential format/retrieval at the moment btw. so this is a detail, but IMO one that's not insignificant. On 07/24/2013 02:26 AM, Peterson, Jon wrote: > > I've been arguing that we hedge our bets too, but perhaps that we hedge > them even more than you consider below. (Forgive me that I haven't closely > tracked your tight loop with Mike Hammer, in case it sheds any light I > miss here.) > > RFC4474 (/RFC4474bis) doesn't restrict access to certificates to HTTP > fetches. RFC4474 is pretty agnostic about how you get certs. We talked > about certs being included in SIP messages, so they'd arrive along with > the signature. We talked about using SIP itself to fetch them, via > SUBSCRIBE. We considered cases where verifiers had access to caches, or > even local cert stores. At the time we were doing RFC4474, HTTP seemed > like the right thing to hype for a number of reasons, so we encouraged it. > But the URL in Identity-Info is just supposed to be a helpful suggestion, > not the sole and authoritative means of access to certs. For the STIR > case, however, that hint might be useful to disambiguate for verifiers > which authority signed a SIP request, when there are multiple authorities > for a single number (the function the CIDER "public key index value" would > serve, if I understand correctly). > > Part of the reason I think we're all talking past each other here is that > certs are relatively self-contained documents, and you could get them in a > number of ways, and I don't think there's any pressing need for us to > restrict those ways. For DNS proposals (if they don't just stick CA certs > in the DNS), on the other hand, the way you get a credential is > inextricably coupled to the semantics of the credential itself, which is > why the CIDER proposal isn't just a protocol, it's a whole deployment > architecture. The credentials lose any semantics if they are divorced from > the deployment environment you're supposed to fetch them from. All > credentials must be uploaded through that central service and all > credentials must be downloaded from its (distributed) deployment. > > There doesn't need to be a "national authority" cloud service that manages > access to certs in this way. The reason you trust a cert isn't because you > downloaded it from the right place, it's because you trust the trust > anchor that signed the cert. This isn't about HTTP - it doesn't matter if > you found the cert lying on the ground. This is why I don't understand the > need for "hard cider," or indeed why it would be important for a > verification service to be able to derive a single canonical location from > which it will download a cert by studying the originating number alone. I agree that the in-band (or out of band) identifier/blob that the verifier uses to construct the inputs to signature checking (esp. the "right" public key) can be handled in various ways. And as you say the blob could contain an RFC5280/X.509 certificate (chain) or the identifier/blob could be used to retrieve a certificate (chain) or the missing parts thereof. However, at some point you do need to support certificate status checking, and for certs that means OCSP or CRLs. In either case the verifier has to do some more work and access the network to get status information. The tricky point is that CRLs get big and unwieldy, or else are very complex (e.g. delta CRLs [1], the support for which is I think highly variable and maybe sometimes flakey). If you take the OCSP route then the verifier is making a status check call to the network for each signature it verifies (more-or-less), at which point DKIM-like models start to look quite similar. So I hope that the STIR wg, when formed, delves deeply into this question. I doubt that the BoF or any proposal at the BoF can really provide final answers (I include "hedge your bets" as a proposed answer there btw). S. [1] http://tools.ietf.org/html/rfc5280#section-5.2.4 > I > kind of see why this is important for a DNS-based solution (though the > harm DNS URI Identity-Info would do there isn't clear to me - if it points > to something you don't trust, don't trust it), but not for a cert-based > solution. If you could, for example, just receive the cert in-band with > the request, that would seem to obviate the need to go ask anyone for it. > > I'm a bit unsure as well of the high-level structure of the arguments > below, effectively that carriers are the only sorts of verifiers that > matter, and that carriers probably can't use anything other than DNS. > Carriers do matter, and so do enterprises, and so do endpoints, as > potential verifiers. Of course it's true that carriers use DNS, as do > enterprises and endpoints. But none of them perform anything like the STIR > in-band verifier function today, and new code will have to be written and > new stuff deployed to make this happen - arguing that this has to be the > same stuff that's used for an unrelated existing function in the network > just doesn't persuade, given the huge differences in usage. I don't think > it would be unreasonable for DNS to play a role in credential delivery to > verifiers, for environments where it makes sense. I don't see how this > proposed use of the DNS has some decisive advantage over certificates, > though. This makes me want to hedge bets from the start. I think the > flexibility of something like Identity-Info is a way to approach that. > > > Jon Peterson > Neustar, Inc. > > On 7/21/13 8:50 AM, "Hadriel Kaplan" wrote: > >> >> I've been thinking about your questions and it occurred to me we may be >> talking past each other, or I'm not being clear enough. It's hard to >> discuss some of this stuff in email, but anyway let me try a different >> tack... >> >> So far, there is one relatively concrete proposal for how HTTP would be >> used: RFC4474 or 4474bis, which use certs signed by someone, and >> indicates where to get the cert in an HTTP URL encoded in the SIP message >> Identity-Info header. That model has a whole host of issues, and if by >> "HTTP" you mean that model, then we could drill-down on the practical >> problems I believe it would have. >> >> There is another way it could work using HTTP, which is essentially to >> copy the CIDER proposal but replace the DNS query-answer with HTTP >> query-answer. The verifier would generate its own HTTP URL to resolve, >> based on the received identity information in SIP, and we'd define how it >> does that, what the cert model and encoding would be, how it gets secured >> redirection, how it times out cached copies, how to get the cert signer's >> cert, how to time that out, etc. Let's call such a model "HARD CIDER", >> for "Http-based Access of Registry Data" or some such.[1] >> >> For a Hard Cider model to be used in a public Internet access model, we'd >> still be relying on DNS and DNSSEC, to perform resolution of the HTTP URL >> in a secure manner. And using a generated HTTP URL implies the national >> registries are deployed as a Google/Facebook/Amazon type cloudy >> infrastructure with internal horizontal scaling technologies, etc. But >> let's ignore that for now. >> >> The bigger problem is the target user environment: where we expect to be >> using this stuff, in carriers. In practice, HTTP isn't frequently used >> by real-time call-handling network devices in most carriers. It is used >> by the carrier as a corporation of course, in various other >> areas/groups/functions; and it's used in some call-control cases, usually >> by application servers providing features for specific users or calls, in >> specific scenarios. It's far less common to have it used for every call, >> and essentially never gets used by SBCs or X-CSCFs on an every-call >> basis. There are a variety of practical reasons for that, but it doesn't >> really matter why. What matters is it would be a barrier to >> deployability and adoption, in the real world, if we chose it. >> >> Arguably, DIAMETER is a far more common protocol for many carriers to use >> for this type of stuff than HTTP or even DNS. DIAMETER has its own >> challenges in actual carrier deployments, mostly around scalability and >> manageability, but we couldn't pick DIAMETER anyway because it's only >> used in some carriers and not all carriers, and rarely used by anyone >> else. >> >> As a protocol, DNS happens to be used by everyone - it's only used as >> private ENUM by some carriers not all obviously, but virtually all of >> them use DNS for at least hostname resolution, even internally. And DNS >> client implementation happens to be available in code in all systems, >> whether it be SBCs or X-CSCFs or app servers or whatever; and its >> performance, scalability and manageability characteristics happen to be >> really good in actual carrier deployments. >> >> Having said all that, another way we could go in STIR is to just hedge >> our bets and define multiple protocols: DNS, HTTP, and maybe even >> DIAMETER. To do that, though, it still has to be deployable as DNS, >> still have to be based on the verifier generating the URL and not have it >> sent by the originator, still have to specify the caching and clearing >> behavior, still have to support both a centralized and distributed model >> of database deployment for numbers, etc. We've done that sort of hedging >> before in the IETF, rarely - it's a LOT more work, obviously, but it lets >> the market decide for itself what to do. >> >> If we do hedge our bets, however, I believe the most straight-forward way >> to actually do that would be to define the DNS one *first*, and then >> figure out the HTTP or DIAMETER mechanics required for doing the same >> things accessing stuff from a deployed DNS database infrastructure. >> That's because DNS as a protocol already defines the semantics, >> mechanics, and database structure; and if its used in a public Internet >> access manner then it's The Public DNS. So a use of HTTP or DIAMETER >> would need to access it and follow its behavior. And that has some >> bizarre deployment expectations for all parties, for example for >> international call scenarios, or for an email-style identity model. >> >> A more reasonable approach might be to define the DNS model, and then >> only define how an HTTP or DIAMETER access to the local DNS resolver >> could also work, where the verifier can only be a stub. That's still a >> lot of work, and still involves localhost caching rules and such, but at >> least it constrains the problem somewhat. >> >> -hadriel >> [1] I don't use the term "hard" to mean it will be hard, but rather >> because "hard cider" happens to be a specific form of the drink known as >> cider. :) >> >> >> On Jul 20, 2013, at 8:13 PM, Hadriel Kaplan >> wrote: >> >>> >>> On Jul 20, 2013, at 7:20 PM, Henning Schulzrinne >>> wrote: >>> >>>> I don't see the "benefit" of DNS here. There are two cases, either way: >>>> >>>> (1) A standard DNS hierarchy, with caching, but no synchronization. In >>>> that case, you need short TTLs if you care about revocation. With short >>>> TTLs, you get one country-level RTT for every query, even assuming no >>>> packet loss. >>> >>> By "one country-level RTT for every query", do you mean you get one RTT >>> on average for every call, and the RTT is likely not long on average >>> because it's to a server in your geographic country? If so, sure that >>> would likely be the case for public internet access queriers. One RTT >>> on average, for a public Internet access model is pretty good, BTW. >>> HTTP really won't have one RTT for such public Internet access, not in >>> actual practice if this Identity-Info URL model is used. Again, this is >>> not CIDER's raison d'etre, but just another plus. >>> >>> >>>> (2) A locally-cached synchronized DNS hierarchy, using some kind of >>>> rsync-like mechanism. >>>> >>>> You can get the same two versions for HTTP and certs. >>> >>> No, I really don't believe you can. You can get them if we give up on >>> the Identity-Info URL thing, and define how HTTP would work without it, >>> how the international call thing works, and so on. But not if the cert >>> is served on some random server indicated by the Identity-Info header. >>> >>> >>>> The locally-cached synchronized DNS has essentially the same overhead >>>> as the locally-cached HTTP version, since the connection is nailed down. >>> >>> Define "overhead". Overhead for whom? For the verifier systems HTTP >>> is more overhead - a trivial amount if the stars align, and more if >>> reality is included in the equation; but not a massive amount >>> regardless. For the carriers, HTTP is more cost and operational >>> overhead from a deployment perspective if reality is included, but again >>> if we ignore practical realties then it's all equal. So sure, if all >>> carriers in all nations deploy Google or Facebook style infrastructures >>> and tweak their verifiers' TCP and HTTP implementations - all for the >>> benefit of verifying a caller-id - then we're all good-to-go. ;) >>> >>> -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 br@brianrosen.net Wed Jul 24 05:47:58 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B6011E80E0 for ; Wed, 24 Jul 2013 05:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.05 X-Spam-Level: X-Spam-Status: No, score=-99.05 tagged_above=-999 required=5 tests=[AWL=1.072, 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 japRbANlUJKe for ; Wed, 24 Jul 2013 05:47:51 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id A961811E80DC for ; Wed, 24 Jul 2013 05:47:51 -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=YzQRyYA0iVbqv+Giu9FY01UDFwjz5udFf7t7i7SyyFQ=; b=HzFEgJ81COtNhFtpdman4O2cWUMcbQx/0JhC6efVvOiy/CXKrlqOnmtNEV/71FAnLH7tqb3xY7IBC6OQ5rTEPdXVBRgWYbMbKjlh3DToUUKjdwANG8oQoYkYI5+zIp9APgj52ixvDiF2FVgdSKlGsaM5j9kPeeMUccW7bpabAuw=; Received: from neustargw.va.neustar.com ([209.173.53.233]:46562 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1V1yTu-0003Gs-MH; Wed, 24 Jul 2013 08:47:50 -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: <011401ce87f2$75e5e880$61b1b980$@shockey.us> Date: Wed, 24 Jul 2013 08:47:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00C069FD01E0324C9FFCADF539701DB3BBC1A683@EX2K10MB1.corp.yaanatech.com> <6EF50BDB-3F41-49FE-83C1-20216D0D0BF0@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1BE03@EX2K10MB1.corp.yaanatech.com> <0073993E-1BC8-461C-9A7E-B5DCFC617DBF@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1C956@EX2K10MB1.corp.yaanatech.com> <011401ce87f2$75e5e880$61b1b980$@shockey.us> To: Richard Shockey 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] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 12:47:58 -0000 I think enterprise PBXs will assert and check identity if we provide the = right tools. That would mean automated mechanisms to acquire = credentials. If we provided provisioning mechanisms that loaded = authorized numbers and credentials from the service provider who = delegated the numbers, and we provided an automated way for the PBX to = get the public keys to verify, I think many PBX vendors would implement = that. If it was no-touch, which I think it could be, I think that it = would be a very common deployment model. At some point, those same protocols could be extended to endpoints. I = don't see that happening real soon perhaps, but I think it will happen. This probably takes work beyond IETF efforts (SIPforum perhaps, = extensions or adjuncts to SIPconnect) Brian On Jul 23, 2013, at 6:17 PM, Richard Shockey wrote: > +1 People pay for a service and contrary to popular opinion SIP/IMS = is > actually a good business for service providers. I have zero = confidence > calling party is going to sign for themselves for much the same reason = I > don't have a lot of confidence that we will see handsets actually = doing the > validation in significant numbers.=20 >=20 > I pay people to run the SMTP email servers for my domain. I expect = them to > implement tools to reduce SPAM or I will just "port" my domain = elsewhere.=20 >=20 > As for the policy questions here .. they are not going away but at = least the > structure of authority in E.164 is well known, definable, and in the = case > of the US portions of the NANP the Authority to Act is considered = plenary > and fully tested in the courts. Section 251(e) [1] of the US Act for = you > budding amateur teleco lawyers out there. =20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of > Hadriel Kaplan > Sent: Tuesday, July 23, 2013 5:39 PM > To: Michael Hammer > Cc: stir@ietf.org > Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) >=20 >=20 > On Jul 23, 2013, at 3:39 PM, Michael Hammer = > wrote: >=20 >> You keep saying that the SPs would keep the private keys in servers=20= >> for some reason. >> While they need their own keys for administrative actions, The = private=20 >> keys associated with the end-user certs should not be stored. >> I think you are assuming that the SP signs for the calling party. >> I am assuming that the calling party signs themselves. (SIP Internet=20= >> case) >=20 > I was wondering if that was what you meant. You're right - I assume = no > matter what happens, that most of the SPs will be signing for some > significant portion of their subscriber calling parties. That way = they can > sign for the billions of E.164 caller-id's they control, that are not > smartphones, won't be upgraded, etc. I also think they'll be signing = on > behalf of most Enterprise-originated calls too, for that matter. >=20 > I don't think I'm the only one with that assumption, BTW. At the end = of the > day, most SIP service providers provide a service, and most of their > customers expect them to do it. Even for Enterprise cases, most = Enterprises > in the World don't have SIP/VoIP expertise, don't use Asterix, and = don't > want to deal with the details - they pay a service provider to provide > phone-call-type service, and they expect to get their money's worth. = When > something goes wrong, they want to be able to yell at someone else to = fix > it. There are exceptions of course - for example very large = corporations > and companies for whom phone service is their business (e.g., = call-centers), > and of course there are always folks who are unique; but for most = folks it's > a service they use, not something they want to worry about = programming. >=20 >=20 >> Lastly, I can summarize you last 4 paragraphs: >> So long as we maintain the current hierarchy of service providers,=20 >> then it will scale. >> That seems like a public policy question, so I won't go there. >=20 > Totally. But that's implied in the concept of not making the STIR = data > publicly available, isn't it? I mean if SIP were used on the public > Internet in an open manner, like email, but the STIR data was > access-controlled, how would the administrative burden of = access-controlling > it scale even for HTTP? It's not like writing a script to query the = whole > database using HTTP is that difficult. And it's not like a > username/password prevents anything - it just requires you to get a > username/password. It's not like just anybody who passes a captcha = test and > has a personal email account somewhere; in fact we can't even just = only let > "corporations" access it. The implied problem here is we don't want = to give > just anyone access - only "very special" someones. So who are the = very > special someones? How does it administratively scale to have millions = of > very special someones, on a World-wide basis, for just one database > admin/company to control? And why wouldn't or shouldn't the ST IR > access-control model follow the PSTN/SIP hierarchy model, since = they're the > ones who are legally assigned E.164 numbers to begin with? >=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 Wed Jul 24 05:58: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 20FCF11E812C for ; Wed, 24 Jul 2013 05:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAN4fxafEjsY for ; Wed, 24 Jul 2013 05:58:12 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0C111E80E6 for ; Wed, 24 Jul 2013 05:58:12 -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 r6OCwBvk013981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Jul 2013 12:58:11 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 r6OCwAFu004270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jul 2013 12:58:11 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6OCwArD004262; Wed, 24 Jul 2013 12:58:10 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Jul 2013 05:58: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: <7699_1374659827_51EFA4F3_7699_4570_1_B5939C6860701C49AA39C5DA5189448B0B576C@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Wed, 24 Jul 2013 08:58:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4380BD56-E3E5-4CBD-B329-2D9964F91E01@oracle.com> References: <20130712043221.11767.74779.idtracker@ietfa.amsl.com> <1F4B4D44-BD3E-4995-876A-147832C925F9@oracle.com> <19893_1374596593_51EEADF1_19893_9071_1_B5939C6860701C49AA39C5DA5189448B0B55A6@PEXCVZYM12.corporate.adroot.infra.ftgroup> <15BB6D07-F5D4-4945-80B9-0648CB32A6CA@oracle.com> <7699_1374659827_51EFA4F3_7699_4570_1_B5939C6860701C49AA39C5DA5189448B0B576C@PEXCVZYM12.corporate.adroot.infra.ftgroup> To: philippe.fouquart@orange.com X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "stir@ietf.org" Subject: Re: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jul 2013 12:58:19 -0000 On Jul 24, 2013, at 5:57 AM, philippe.fouquart@orange.com wrote: > [PhF] Thanks, I get the picture now (apologies maybe I should have = started with cider, always better to start with the lighter stuff = first).=20 >=20 > I find the term canonical a bit misleading then for two reasons:=20 > - the point of converting into a canonical form to me is to have a = unique form upon which all subsequent operations can be done whilst the = non canonical form and related information that lead to it may be = discarded altogether. I now understand why the draft insists on the IKES = Generator using the "source identity type" in addition to the "canonical = identity", it's just that having two distinct numbers (albeit of a = different nature) leading to exactly the same "canonical" string to be = processed and signed differently depending on their 'type' is quite = confusing.=20 Just to be clear, they're not the same canonical *IKES* string in the = end - an E.164 would end up with a "G:" in front, while a number-code = would end up with a "C:" in front, for the IKES-IF string. > - "canonical [E.164] form" for a number is as you know a very common = term to describe the international E.164 format of a number stripped out = of the visual separators. The canonical form in the draft is not that, = well, expect for the E.164 numbers... I wouldn't like this "canonical" = form to appear 'as is' in RU/To or From, for that matter, as I said in = some numbering plans in would be problematic.=20 Right it doesn't change the SIP message at all, and is only used for = IKES processing internally in the IKES generator/verifier. Can you = suggest a better word than "canonical"? I was thinking "normalized" but = that word is also commonly used. > Maybe that would be preferable to use a different term; if you'd = rather not, maybe you want to add something along the lines of 3966 that = says that "converting a nationally-specific number code into its = canonical form/string does not make it a valid E.164 number: the string = consisting of the leading country-code prepended to the number code = cannot be assumed to be a valid E.164 number"=20 I will add that line too - thanks! But I agree with your earlier = comment as well that using a different term might help. > [PhF] Well, sort of: a) not all of them are in "controlled = environments" b) it is not uncommon in national "PSTN" interconnect = offerings to support this and pass it on transparently and c) this type = of access may actually be the source if not maliciously-faked, at least = erroneously-configured caller-id. Maybe for c) depending on their use of = the UUI, they could privately/bilaterally come up with an index of sort = to assert the "on-net" calls, but I think that's just too complex. Right, but the "threat" for STIR is that someone receiving a INVITE/IAM = gets a calling party number that it uses for caller-id display (or = whatever) and the number is being maliciously misrepresented. Obviously = we don't know when it's being maliciously misrepresented or just an = honest mistake/error, and many INVITES/IAMs won't be signed at all at = least in the beginning, so we likely won't be able to block such calls = for a very long time if ever. Instead we'll either anonymize the = calling number (block number display), or check with some other policy = engine, or log it for later analysis, or send it to an IVR, or whatever = - it's a local policy decision really. So assume you get a INVITE/IAM with a RFC 6567 UUI. It would be a local = policy decision what to do. You can decide that the destination = subscriber doesn't have a UUI service, for example a mobile/home phone = wouldn't, and thus treat it as an unsigned call and anonymize the = calling number or block it or whatever. Or you can decide that the SIP = Trunk to an Enterprise has such UUI "service", and pass the INVITE/IAM = on to it unchanged as you do today. The IP-PBX is then responsible for = deciding whether the INVITE/IAM with such a UUI is valid/allowed - for = example if it's from a branch office or whatever. That's what it has to = decide already today, and we don't seem to have a spoofed caller problem = for those cases today.=20 The danger with letting a RFC 6567 UUI trump an IKES UUI is that = malicious sources could just start adding RFC 6567 UUIs to their = INVITEs. We can easily detect and block that for destinations that = don't expect to get 6567 UUIs. The hard part is how to block it for = IP-PBXs that do expect 6567 UUIs. If it becomes a problem, there are = some potential solutions. One solution is to only support 6567 UUI for = inter-branch calls that stay SIP along the whole path (since the IKES = info is in a SIP header, it can be used at the same time as 6567 UUI for = SIP). That's not unreasonable, because as far as I know such = inter-branch calls typically only work within the same carrier, or only = within a small set of fixed/known/pre-arranged set of carriers in a = country. If that's true, then it's not unreasonable to expect the small = set of carriers to support SIP interconnect, at least by the time this = becomes a problem. So the IP-PBX or penultimate carrier can have a = local policy that it only believes INVITE/IAM with 6567 UUI if it also = has a valid IKES info in a SIP header; and the IP-PBX can even have a = local policy that only allows it if the validated number is for a number = it allows to use 6567 UUI for (ie, it knows the branch office private = number), etc. -hadriel From york@isoc.org Wed Jul 24 06:12: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 1A9D011E810A for ; Wed, 24 Jul 2013 06:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 PgHurP4UweD8 for ; Wed, 24 Jul 2013 06:12:06 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by ietfa.amsl.com (Postfix) with ESMTP id 95A7311E8104 for ; Wed, 24 Jul 2013 06:12:05 -0700 (PDT) Received: from BLUPR06MB067.namprd06.prod.outlook.com (10.242.187.146) by BLUPR06MB066.namprd06.prod.outlook.com (10.242.187.145) with Microsoft SMTP Server (TLS) id 15.0.731.16; Wed, 24 Jul 2013 13:12:04 +0000 Received: from BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.198]) by BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.185]) with mapi id 15.00.0731.000; Wed, 24 Jul 2013 13:12:03 +0000 From: Dan York To: "dcrocker@bbiw.net" , Richard Shockey Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) Thread-Index: AQHOgoic9pdSgcwmt0e4tmOaDZg3MZloJ9mAgAAh1QCAAJo+gIAAEIiAgAACrwCAACgKAIAB7dYAgAADmgCAARvJAIAAGXWAgAAFYQCAABB5AIAALmOAgAB7ZoCAA77ygIAAP4yAgAA2cwCAAT04AIAABgWAgAAuioCAAAd3AIAAIT0AgAAK7oCAAGkJgIAATcaA Date: Wed, 24 Jul 2013 13:12:03 +0000 Message-ID: In-Reply-To: <51EF5925.8090904@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] x-forefront-prvs: 0917DFAC67 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(24454002)(189002)(199002)(52314003)(51704005)(479174003)(51856001)(46102001)(74706001)(63696002)(19580395003)(76786001)(76176001)(83322001)(76796001)(16406001)(36756003)(69226001)(19580385001)(81342001)(77982001)(47736001)(59766001)(54356001)(74876001)(47976001)(50986001)(74366001)(47446002)(54316002)(80022001)(76482001)(31966008)(56816003)(56776001)(81542001)(53806001)(15395725003)(74502001)(65816001)(74662001)(19580405001)(15202345003)(83072001)(49866001)(79102001)(77096001)(4396001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB066; H:BLUPR06MB067.namprd06.prod.outlook.com; CLIP:10.255.101.5; 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: "stir@ietf.org" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 13:12:10 -0000 On 7/24/13 12:33 AM, "Dave Crocker" wrote: >If the technology permits signing and validating use by end-systems >(users, enterprises, whatever), then they have the /option/ of doing >STIR. The fact that operational convenience makes is strongly likely >that most/all use will be by intermediary systems such as service >providers, rather than end-systems, is only that: operational choice. Agreed. Before joining ISOC two years ago, I spent 4 years at a VoIP/IVR application platform company providing both a cloud/hosted service and an on-premise software solution. What I found interesting was that, at that time anyway, the companies using on the on-premise product were often either the very small but technically sophisticated (either a very small company or a small project within a larger company) or the very large who had technical staff. In both cases they wanted to operate their own servers on their own networks. As a company grew there came a point where outsourcing the service to a hosted/cloud platform made sense - and then at some point as the company grew much larger they started to have their own IT and developer staff and often wanted to bring the applications back into their own data centers. There were many exceptions to this trend, of course, but the trend was visible. I suspect the trend will be similar with STIR. We'll have many individuals and smaller entities who will run their own VoIP servers and will want to do the signing and validation themselves. And we'll have very large organizations with IT and developer staff who will want to do the signing and validation. And the VAST majority of users will just have their service providers do it. As Richard noted, many will just expect the SP to do it. >If the design restricts use to providers, then there is no opportunity >for enterprises or end-users to sign or validate. > >Believe it or not, some individuals and some enterprises still run their >own SMTP servers. That folk like you and me don't does not make it >reasonable to prevent others from doing it. Exactly, and there will also be some network environments with high security policies that require them to operate their own equipment and would in this case require them to do their own signing and validating. We need to assume in the design that the signing and validation can be done at any point in the process, even if the operational reality will be that in maybe 90+% of the cases all of that will be done by the service providers. 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/=20 From richard@shockey.us Wed Jul 24 06:34: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 42B1211E8133 for ; Wed, 24 Jul 2013 06:34:39 -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 vCCUZWf-+PGg for ; Wed, 24 Jul 2013 06:34:28 -0700 (PDT) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 725AF11E80FD for ; Wed, 24 Jul 2013 06:34:25 -0700 (PDT) Received: (qmail 18310 invoked by uid 0); 24 Jul 2013 13:34:01 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy13.unifiedlayer.com with SMTP; 24 Jul 2013 13:34:01 -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/Mo/bQ9WHlz5wvJfoa47Qp34qoUdfENwJA30TVjDqo=; b=guo/yEm4AP5K0M6SMgKF67VU+i7TReHbgEzCazwM2IomcVFIAJr3AGsJNvrtqB9AgpffJWxVO9EZGb9eKTuUHtGHamLLhDaJQr2nVFZ3zX86aHhJ4e1+nquOUT8JZRzY; Received: from [71.114.100.16] (port=49441 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V1zCZ-0005qj-Ti; Wed, 24 Jul 2013 07:34:00 -0600 From: "Richard Shockey" To: References: <00C069FD01E0324C9FFCADF539701DB3BBC1A683@EX2K10MB1.corp.yaanatech.com> <6EF50BDB-3F41-49FE-83C1-20216D0D0BF0@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1BE03@EX2K10MB1.corp.yaanatech.com> <0073993E-1BC8-461C-9A7E-B5DCFC617DBF@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1C956@EX2K10MB1.corp.yaanatech.com> <011401ce87f2$75e5e880$61b1b980$@shockey.us> <51EF5925.8090904@dcrocker.net> In-Reply-To: <51EF5925.8090904@dcrocker.net> Date: Wed, 24 Jul 2013 09:33:56 -0400 Message-ID: <009101ce8872$73c47ff0$5b4d7fd0$@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: AQKGYdESuNaKYzjA1MOVC/t4WgLNfwFqNPDrAOTUU78BYLTRJAGN7elAAkH22Z0B6ngrqgFCyxQtl664niA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Cc: stir@ietf.org Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 13:34:56 -0000 Good point Dave .. I would never suggest that the design restrict the use to service providers only that IMHO the likely deployment scenarios would very heavily depend on the role carriers have in the real time communications space and the known hierarchy of authority for the numbering plan. What I am concerned about is that the design, at the very least, understands the ongoing constraints in the service provider architecture and does not propose some brand new mechanism that would be impossible to implement by carriers in a reasonable period of time. -----Original Message----- From: Dave Crocker [mailto:dhc@dcrocker.net] Sent: Wednesday, July 24, 2013 12:34 AM To: Richard Shockey Cc: stir@ietf.org Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) On 7/23/2013 11:17 PM, Richard Shockey wrote: > I pay people to run the SMTP email servers for my domain. I expect > them to implement tools to reduce SPAM or I will just "port" my domain elsewhere. This highlights a core bit of confusion in this discussion. It concerns the non-normative, architectural difference between may and must. If the technology permits signing and validating use by end-systems (users, enterprises, whatever), then they have the /option/ of doing STIR. The fact that operational convenience makes is strongly likely that most/all use will be by intermediary systems such as service providers, rather than end-systems, is only that: operational choice. If the design restricts use to providers, then there is no opportunity for enterprises or end-users to sign or validate. Believe it or not, some individuals and some enterprises still run their own SMTP servers. That folk like you and me don't does not make it reasonable to prevent others from doing it. d/ ps. DKIM is an example of this choice; it's almost exclusively deployed amongst service hosts; but in fact the architecture permits operation with user agents. -- Dave Crocker Brandenburg InternetWorking bbiw.net From hadriel.kaplan@oracle.com Wed Jul 24 06: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 C801C11E80F1 for ; Wed, 24 Jul 2013 06:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgbIHcxH0pY2 for ; Wed, 24 Jul 2013 06:38:17 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBBE11E80ED for ; Wed, 24 Jul 2013 06:38:17 -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 r6ODbwa1023697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Jul 2013 13:37: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 r6ODbwrD013919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jul 2013 13:37:58 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6ODbvvR024613; Wed, 24 Jul 2013 13:37:57 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Jul 2013 06:37: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: Wed, 24 Jul 2013 09:37:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> <457ED3A0-D8D1-4420-A2C3-5B07B16AE641@vigilsec.com> <8D3E41B3-6A3B-4982-8193-C975A3C867BB@oracle.com> To: Cullen Jennings (fluffy) X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: IETF STIR Mail List Subject: Re: [stir] Draft STIR Charter - 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, 24 Jul 2013 13:38:24 -0000 On Jul 23, 2013, at 11:56 PM, Cullen Jennings (fluffy) = wrote: >=20 > On Jul 20, 2013, at 12:34 AM, Hadriel Kaplan = wrote: >=20 >> The "traditional" and regulated carriers, MSOs, etc., are the ones = who want to stop it. >=20 > I don't really agree with this. If this was true, the class 5 switch = that my ISDN trunk connects to would only allow me to assert the caller = ID on the ISDN trunk for numbers assigned to me. However, because I am = the customer, and I like to be able to set whatever caller ID I want, = and my service provider makes me happy as a customer. Many providers in = the US are very happy to provide me with a ISDN trunk that allows me to = set whatever caller ID I want. I will note this include the bulk of the = large carriers with good reputations, it's not just fringy operators. >=20 > I think the key thing is that carriers largely try and meet the needs = of their customers. And their customs are often the people that make = robo calls, as well as the people that receive them.=20 I think we have a different concept of who the bad callers are. My = guess is in your definition is it's just a telemarketer. To me, = "telemarketers" are perfectly legal/legitimate callers. I don't = personally want to get calls from them, but that's up to a = whitelist/blacklist mechanism to handle, whether it be do-not-call lists = or crowd-sourced reputation lists or whatever. To me, the bad guys are = the guys generating bulk calls using *purposefully invalid* calling = numbers, using Asterisk with SIP trunks to non-regulated providers. = They're using invalid calling numbers for the purpose of misleading = their targets, bypassing whitelists/blacklists, etc. I truly don't = think the regulated carriers want to have those guys as their customers. Regulated carriers allow you to assert any caller ID on an ISDN trunk = because they have no real choice - they need to support the outsourced = call-center and branch office call scenarios. They need to let the PBX = choose what caller ID to generate, on a call-by-call basis. The = carriers don't do it because they don't care - they do it because that's = the only way they could handle that use-case in ISDN/SS7/SIP. And it = worked fine for a long time. There *were* cases of fraud and abuse of = course, but the rate was so low the carrier fraud/support departments = could handle it. Regardless, that stuff doesn't really matter. We need their help, if we = want this thing to be widely deployed and helpful/useful, for more than = society's elite. I think the carriers want to help, if for no other = reason than to avoid government mandate. (I honestly think they want to = do it for better reasons than that, fwiw) -hadriel From michael.hammer@yaanatech.com Wed Jul 24 07:08: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 3A85711E80CC for ; Wed, 24 Jul 2013 07:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 IhcVoUSukiLQ for ; Wed, 24 Jul 2013 07:08: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 D26E021F8203 for ; Wed, 24 Jul 2013 07:08:04 -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, 24 Jul 2013 07:07:43 -0700 From: Michael Hammer To: "stephen.farrell@cs.tcd.ie" , "jon.peterson@neustar.biz" Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) - attack model Thread-Index: AQHOhQaUpWBouCrQPUqwnzpS8YN+fJlumFIAgAAQQQCAAAISgIAADtuAgAEFx4CAA8W3gIAAm9gA///DMwA= Date: Wed, 24 Jul 2013 14:07:42 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC1CDA5@EX2K10MB1.corp.yaanatech.com> References: <51EFB00C.3050602@cs.tcd.ie> In-Reply-To: <51EFB00C.3050602@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.97] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_006C_01CE8855.A1BD0480" MIME-Version: 1.0 Cc: "stir@ietf.org" , "hadriel.kaplan@oracle.com" , "Henning.Schulzrinne@fcc.gov" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jul 2013 14:08:10 -0000 ------=_NextPart_000_006C_01CE8855.A1BD0480 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Don't forget though that CRL checks are an Idle state activity, not a per call setup delaying activity. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: Wednesday, July 24, 2013 6:44 AM To: Peterson, Jon Cc: stir@ietf.org Mail List; Hadriel Kaplan; Henning Schulzrinne Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model Hi Jon, I think you make some reasonable points below, but wanted to add a bit to one of 'em. I've no position on whether or not STIR ought hedge its bets on credential format/retrieval at the moment btw. so this is a detail, but IMO one that's not insignificant. On 07/24/2013 02:26 AM, Peterson, Jon wrote: > > I've been arguing that we hedge our bets too, but perhaps that we > hedge them even more than you consider below. (Forgive me that I > haven't closely tracked your tight loop with Mike Hammer, in case it > sheds any light I miss here.) > > RFC4474 (/RFC4474bis) doesn't restrict access to certificates to HTTP > fetches. RFC4474 is pretty agnostic about how you get certs. We talked > about certs being included in SIP messages, so they'd arrive along > with the signature. We talked about using SIP itself to fetch them, > via SUBSCRIBE. We considered cases where verifiers had access to > caches, or even local cert stores. At the time we were doing RFC4474, > HTTP seemed like the right thing to hype for a number of reasons, so we encouraged it. > But the URL in Identity-Info is just supposed to be a helpful > suggestion, not the sole and authoritative means of access to certs. > For the STIR case, however, that hint might be useful to disambiguate > for verifiers which authority signed a SIP request, when there are > multiple authorities for a single number (the function the CIDER > "public key index value" would serve, if I understand correctly). > > Part of the reason I think we're all talking past each other here is > that certs are relatively self-contained documents, and you could get > them in a number of ways, and I don't think there's any pressing need > for us to restrict those ways. For DNS proposals (if they don't just > stick CA certs in the DNS), on the other hand, the way you get a > credential is inextricably coupled to the semantics of the credential > itself, which is why the CIDER proposal isn't just a protocol, it's a > whole deployment architecture. The credentials lose any semantics if > they are divorced from the deployment environment you're supposed to > fetch them from. All credentials must be uploaded through that central > service and all credentials must be downloaded from its (distributed) deployment. > > There doesn't need to be a "national authority" cloud service that > manages access to certs in this way. The reason you trust a cert isn't > because you downloaded it from the right place, it's because you trust > the trust anchor that signed the cert. This isn't about HTTP - it > doesn't matter if you found the cert lying on the ground. This is why > I don't understand the need for "hard cider," or indeed why it would > be important for a verification service to be able to derive a single > canonical location from which it will download a cert by studying the originating number alone. I agree that the in-band (or out of band) identifier/blob that the verifier uses to construct the inputs to signature checking (esp. the "right" public key) can be handled in various ways. And as you say the blob could contain an RFC5280/X.509 certificate (chain) or the identifier/blob could be used to retrieve a certificate (chain) or the missing parts thereof. However, at some point you do need to support certificate status checking, and for certs that means OCSP or CRLs. In either case the verifier has to do some more work and access the network to get status information. The tricky point is that CRLs get big and unwieldy, or else are very complex (e.g. delta CRLs [1], the support for which is I think highly variable and maybe sometimes flakey). If you take the OCSP route then the verifier is making a status check call to the network for each signature it verifies (more-or-less), at which point DKIM-like models start to look quite similar. So I hope that the STIR wg, when formed, delves deeply into this question. I doubt that the BoF or any proposal at the BoF can really provide final answers (I include "hedge your bets" as a proposed answer there btw). S. [1] http://tools.ietf.org/html/rfc5280#section-5.2.4 > I > kind of see why this is important for a DNS-based solution (though the > harm DNS URI Identity-Info would do there isn't clear to me - if it > points to something you don't trust, don't trust it), but not for a > cert-based solution. If you could, for example, just receive the cert > in-band with the request, that would seem to obviate the need to go ask anyone for it. > > I'm a bit unsure as well of the high-level structure of the arguments > below, effectively that carriers are the only sorts of verifiers that > matter, and that carriers probably can't use anything other than DNS. > Carriers do matter, and so do enterprises, and so do endpoints, as > potential verifiers. Of course it's true that carriers use DNS, as do > enterprises and endpoints. But none of them perform anything like the > STIR in-band verifier function today, and new code will have to be > written and new stuff deployed to make this happen - arguing that this > has to be the same stuff that's used for an unrelated existing > function in the network just doesn't persuade, given the huge > differences in usage. I don't think it would be unreasonable for DNS > to play a role in credential delivery to verifiers, for environments > where it makes sense. I don't see how this proposed use of the DNS has > some decisive advantage over certificates, though. This makes me want > to hedge bets from the start. I think the flexibility of something like Identity-Info is a way to approach that. > > > Jon Peterson > Neustar, Inc. > > On 7/21/13 8:50 AM, "Hadriel Kaplan" wrote: > >> >> I've been thinking about your questions and it occurred to me we may >> be talking past each other, or I'm not being clear enough. It's hard >> to discuss some of this stuff in email, but anyway let me try a >> different tack... >> >> So far, there is one relatively concrete proposal for how HTTP would >> be >> used: RFC4474 or 4474bis, which use certs signed by someone, and >> indicates where to get the cert in an HTTP URL encoded in the SIP >> message Identity-Info header. That model has a whole host of issues, >> and if by "HTTP" you mean that model, then we could drill-down on the >> practical problems I believe it would have. >> >> There is another way it could work using HTTP, which is essentially >> to copy the CIDER proposal but replace the DNS query-answer with HTTP >> query-answer. The verifier would generate its own HTTP URL to >> resolve, based on the received identity information in SIP, and we'd >> define how it does that, what the cert model and encoding would be, >> how it gets secured redirection, how it times out cached copies, how >> to get the cert signer's cert, how to time that out, etc. Let's call >> such a model "HARD CIDER", for "Http-based Access of Registry Data" >> or some such.[1] >> >> For a Hard Cider model to be used in a public Internet access model, >> we'd still be relying on DNS and DNSSEC, to perform resolution of the >> HTTP URL in a secure manner. And using a generated HTTP URL implies >> the national registries are deployed as a Google/Facebook/Amazon type >> cloudy infrastructure with internal horizontal scaling technologies, >> etc. But let's ignore that for now. >> >> The bigger problem is the target user environment: where we expect to >> be using this stuff, in carriers. In practice, HTTP isn't frequently >> used by real-time call-handling network devices in most carriers. It >> is used by the carrier as a corporation of course, in various other >> areas/groups/functions; and it's used in some call-control cases, >> usually by application servers providing features for specific users >> or calls, in specific scenarios. It's far less common to have it >> used for every call, and essentially never gets used by SBCs or >> X-CSCFs on an every-call basis. There are a variety of practical >> reasons for that, but it doesn't really matter why. What matters is >> it would be a barrier to deployability and adoption, in the real world, if we chose it. >> >> Arguably, DIAMETER is a far more common protocol for many carriers to >> use for this type of stuff than HTTP or even DNS. DIAMETER has its >> own challenges in actual carrier deployments, mostly around >> scalability and manageability, but we couldn't pick DIAMETER anyway >> because it's only used in some carriers and not all carriers, and >> rarely used by anyone else. >> >> As a protocol, DNS happens to be used by everyone - it's only used as >> private ENUM by some carriers not all obviously, but virtually all of >> them use DNS for at least hostname resolution, even internally. And >> DNS client implementation happens to be available in code in all >> systems, whether it be SBCs or X-CSCFs or app servers or whatever; >> and its performance, scalability and manageability characteristics >> happen to be really good in actual carrier deployments. >> >> Having said all that, another way we could go in STIR is to just >> hedge our bets and define multiple protocols: DNS, HTTP, and maybe >> even DIAMETER. To do that, though, it still has to be deployable as >> DNS, still have to be based on the verifier generating the URL and >> not have it sent by the originator, still have to specify the caching >> and clearing behavior, still have to support both a centralized and >> distributed model of database deployment for numbers, etc. We've >> done that sort of hedging before in the IETF, rarely - it's a LOT >> more work, obviously, but it lets the market decide for itself what to do. >> >> If we do hedge our bets, however, I believe the most straight-forward >> way to actually do that would be to define the DNS one *first*, and >> then figure out the HTTP or DIAMETER mechanics required for doing the >> same things accessing stuff from a deployed DNS database infrastructure. >> That's because DNS as a protocol already defines the semantics, >> mechanics, and database structure; and if its used in a public >> Internet access manner then it's The Public DNS. So a use of HTTP or >> DIAMETER would need to access it and follow its behavior. And that >> has some bizarre deployment expectations for all parties, for example >> for international call scenarios, or for an email-style identity model. >> >> A more reasonable approach might be to define the DNS model, and then >> only define how an HTTP or DIAMETER access to the local DNS resolver >> could also work, where the verifier can only be a stub. That's still >> a lot of work, and still involves localhost caching rules and such, >> but at least it constrains the problem somewhat. >> >> -hadriel >> [1] I don't use the term "hard" to mean it will be hard, but rather >> because "hard cider" happens to be a specific form of the drink known >> as cider. :) >> >> >> On Jul 20, 2013, at 8:13 PM, Hadriel Kaplan >> >> wrote: >> >>> >>> On Jul 20, 2013, at 7:20 PM, Henning Schulzrinne >>> wrote: >>> >>>> I don't see the "benefit" of DNS here. There are two cases, either way: >>>> >>>> (1) A standard DNS hierarchy, with caching, but no synchronization. >>>> In that case, you need short TTLs if you care about revocation. >>>> With short TTLs, you get one country-level RTT for every query, >>>> even assuming no packet loss. >>> >>> By "one country-level RTT for every query", do you mean you get one >>> RTT on average for every call, and the RTT is likely not long on >>> average because it's to a server in your geographic country? If so, >>> sure that would likely be the case for public internet access >>> queriers. One RTT on average, for a public Internet access model is pretty good, BTW. >>> HTTP really won't have one RTT for such public Internet access, not >>> in actual practice if this Identity-Info URL model is used. Again, >>> this is not CIDER's raison d'etre, but just another plus. >>> >>> >>>> (2) A locally-cached synchronized DNS hierarchy, using some kind of >>>> rsync-like mechanism. >>>> >>>> You can get the same two versions for HTTP and certs. >>> >>> No, I really don't believe you can. You can get them if we give up >>> on the Identity-Info URL thing, and define how HTTP would work >>> without it, how the international call thing works, and so on. But >>> not if the cert is served on some random server indicated by the Identity-Info header. >>> >>> >>>> The locally-cached synchronized DNS has essentially the same >>>> overhead as the locally-cached HTTP version, since the connection is nailed down. >>> >>> Define "overhead". Overhead for whom? For the verifier systems >>> HTTP is more overhead - a trivial amount if the stars align, and >>> more if reality is included in the equation; but not a massive >>> amount regardless. For the carriers, HTTP is more cost and >>> operational overhead from a deployment perspective if reality is >>> included, but again if we ignore practical realties then it's all >>> equal. So sure, if all carriers in all nations deploy Google or >>> Facebook style infrastructures and tweak their verifiers' TCP and >>> HTTP implementations - all for the benefit of verifying a caller-id >>> - then we're all good-to-go. ;) >>> >>> -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 > > _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_006C_01CE8855.A1BD0480 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcy NDE0MDc0MFowIwYJKoZIhvcNAQkEMRYEFIZQAqAY68JiYrGSuwosboXquHo+MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAQgGuFoyznn0skwxLUZtdltC01n7boVDqUvV44tKd t8yUiT2A/Nkc4kp52DuFsWIQgcveJa6Voz91JQLEw8lCiR7+HoV/lJBwvjQk0pURoKY30WDXtVMf dSs+9K6NSAF6s/0HyTqLWlr1h2gv7jAkavTNp4CwzQwso/SF8Pnr44WtIp8SGC3XDzpbmrJebp0Q +hY7x2rM/kJVe6ofGi7CiJ29e+PDxvPUiPcu4x2rpz5ZZIlbu2W8RVCBAsunwnDFwT/p+Kcv2Ve4 g3CYfJO+2yomIqypXU+GGZBzVKgljbS4huef/rXRdMjxCdSJlZ5zTIbJkm8NXY3byywhIote+wAA AAAAAA== ------=_NextPart_000_006C_01CE8855.A1BD0480-- From michael.hammer@yaanatech.com Wed Jul 24 07:23:11 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A5121F8497 for ; Wed, 24 Jul 2013 07:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+1ApWjcMlE5 for ; Wed, 24 Jul 2013 07:23: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 D31F211E80F7 for ; Wed, 24 Jul 2013 07:22: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; Wed, 24 Jul 2013 07:22:06 -0700 From: Michael Hammer To: "richard@shockey.us" , "dcrocker@bbiw.net" Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) Thread-Index: AQHOgvzGoW2Sqvrxc0GEvdoogk5ro5lpa5QAgAAoCgCAAe3VAIAAA5sAgAEbyACAABl1gP//jBDQgACJywD//6q3gIAA/xKAgANB3HCAALyhgP//tYrwADfEMAAADkF6MP//woOAgABwijD//7gqAIAACu6AgABpCYCAAJbxAIAAaANg Date: Wed, 24 Jul 2013 14:22:04 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC1CDE4@EX2K10MB1.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC1A683@EX2K10MB1.corp.yaanatech.com> <6EF50BDB-3F41-49FE-83C1-20216D0D0BF0@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1BE03@EX2K10MB1.corp.yaanatech.com> <0073993E-1BC8-461C-9A7E-B5DCFC617DBF@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1C956@EX2K10MB1.corp.yaanatech.com> <011401ce87f2$75e5e880$61b1b980$@shockey.us> <51EF5925.8090904@dcrocker.net> <009101ce8872$73c47ff0$5b4d7fd0$@shockey.us> In-Reply-To: <009101ce8872$73c47ff0$5b4d7fd0$@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.97] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0071_01CE8857.A4406920" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 14:23:15 -0000 ------=_NextPart_000_0071_01CE8857.A4406920 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit So, you are saying that any DNS-based solution would have to be publicly available? Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Wednesday, July 24, 2013 9:34 AM To: dcrocker@bbiw.net Cc: stir@ietf.org Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) Good point Dave .. I would never suggest that the design restrict the use to service providers only that IMHO the likely deployment scenarios would very heavily depend on the role carriers have in the real time communications space and the known hierarchy of authority for the numbering plan. What I am concerned about is that the design, at the very least, understands the ongoing constraints in the service provider architecture and does not propose some brand new mechanism that would be impossible to implement by carriers in a reasonable period of time. -----Original Message----- From: Dave Crocker [mailto:dhc@dcrocker.net] Sent: Wednesday, July 24, 2013 12:34 AM To: Richard Shockey Cc: stir@ietf.org Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) On 7/23/2013 11:17 PM, Richard Shockey wrote: > I pay people to run the SMTP email servers for my domain. I expect > them to implement tools to reduce SPAM or I will just "port" my domain elsewhere. This highlights a core bit of confusion in this discussion. It concerns the non-normative, architectural difference between may and must. If the technology permits signing and validating use by end-systems (users, enterprises, whatever), then they have the /option/ of doing STIR. The fact that operational convenience makes is strongly likely that most/all use will be by intermediary systems such as service providers, rather than end-systems, is only that: operational choice. If the design restricts use to providers, then there is no opportunity for enterprises or end-users to sign or validate. Believe it or not, some individuals and some enterprises still run their own SMTP servers. That folk like you and me don't does not make it reasonable to prevent others from doing it. d/ ps. DKIM is an example of this choice; it's almost exclusively deployed amongst service hosts; but in fact the architecture permits operation with user agents. -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_0071_01CE8857.A4406920 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcy NDE0MjIwM1owIwYJKoZIhvcNAQkEMRYEFHrIjx2LMBUGKBYbWyA6HaLMY/B0MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEACDPjLxB5VGNap3sc86A60EaPrBJ6su1GZkO1vGLC xkPsvxfxSuxbHYMVgILHKYRHtd3bXSSbGd0Cez2gmCT/Yftd1UsXWz7+647Th9fYd0VOqzlAuTvo 0jxaMgUf9SbNZgHEt4pWp/ydcOXd6Uco9fjlNzxA0dokxp4GrdHtIzIjNDaIS2XLKdpWHkIvNQtg qZB5dwgH5W2gsElljWQW2fPuMN0NTeMOa9WIr+XH0AEJptARq7CxQVwat44RfoE9oWdNFx5TSfSf wGYTHTK/niefYzfXSRLX/HkXjZEy6WTpXFD+R14wZ1Iu2q0z8c6iuO//oXSstMlh4jNh6jF9MQAA AAAAAA== ------=_NextPart_000_0071_01CE8857.A4406920-- From stephen.farrell@cs.tcd.ie Wed Jul 24 08: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 24DCA11E80DF for ; Wed, 24 Jul 2013 08:05: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 cDLpmcU+XsoT for ; Wed, 24 Jul 2013 08:05:41 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id EC13C11E821D for ; Wed, 24 Jul 2013 08:05:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 425FBBE6F; Wed, 24 Jul 2013 16:04:32 +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 bDez5JHFYJYk; Wed, 24 Jul 2013 16:04:32 +0100 (IST) Received: from [IPv6:2001:770:10:203:bdef:eca1:a64f:4f6a] (unknown [IPv6:2001:770:10:203:bdef:eca1:a64f:4f6a]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0C315BE68; Wed, 24 Jul 2013 16:04:32 +0100 (IST) Message-ID: <51EFED00.7030603@cs.tcd.ie> Date: Wed, 24 Jul 2013 16:04:32 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Michael Hammer References: <51EFB00C.3050602@cs.tcd.ie> <00C069FD01E0324C9FFCADF539701DB3BBC1CDA5@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC1CDA5@EX2K10MB1.corp.yaanatech.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "stir@ietf.org" , "hadriel.kaplan@oracle.com" , "jon.peterson@neustar.biz" , "Henning.Schulzrinne@fcc.gov" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jul 2013 15:05:46 -0000 On 07/24/2013 03:07 PM, Michael Hammer wrote: > Don't forget though that CRL checks are an Idle state activity, not a per > call setup delaying activity. That could be the case, or maybe it isn't, I don't know. But full CRLs can easily get BIG, even if only consumed periodically. And you'd still need some models of how big in order to know if that's ok or not. So again, there is work to be done to figure that out for this application. Think of all this public key management like its a balloon. You can squeeze one bit to fit what you want but another will then protrude, possibly causing the whole thing to burst. (I guess since this is RAI that should be a liquid filled balloon, but I hope the analogy is clear enough:-) S. > > Mike > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Stephen Farrell > Sent: Wednesday, July 24, 2013 6:44 AM > To: Peterson, Jon > Cc: stir@ietf.org Mail List; Hadriel Kaplan; Henning Schulzrinne > Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model > > > Hi Jon, > > I think you make some reasonable points below, but wanted to add a bit to > one of 'em. I've no position on whether or not STIR ought hedge its bets on > credential format/retrieval at the moment btw. so this is a detail, but IMO > one that's not insignificant. > > > On 07/24/2013 02:26 AM, Peterson, Jon wrote: >> >> I've been arguing that we hedge our bets too, but perhaps that we >> hedge them even more than you consider below. (Forgive me that I >> haven't closely tracked your tight loop with Mike Hammer, in case it >> sheds any light I miss here.) >> >> RFC4474 (/RFC4474bis) doesn't restrict access to certificates to HTTP >> fetches. RFC4474 is pretty agnostic about how you get certs. We talked >> about certs being included in SIP messages, so they'd arrive along >> with the signature. We talked about using SIP itself to fetch them, >> via SUBSCRIBE. We considered cases where verifiers had access to >> caches, or even local cert stores. At the time we were doing RFC4474, >> HTTP seemed like the right thing to hype for a number of reasons, so we > encouraged it. >> But the URL in Identity-Info is just supposed to be a helpful >> suggestion, not the sole and authoritative means of access to certs. >> For the STIR case, however, that hint might be useful to disambiguate >> for verifiers which authority signed a SIP request, when there are >> multiple authorities for a single number (the function the CIDER >> "public key index value" would serve, if I understand correctly). >> >> Part of the reason I think we're all talking past each other here is >> that certs are relatively self-contained documents, and you could get >> them in a number of ways, and I don't think there's any pressing need >> for us to restrict those ways. For DNS proposals (if they don't just >> stick CA certs in the DNS), on the other hand, the way you get a >> credential is inextricably coupled to the semantics of the credential >> itself, which is why the CIDER proposal isn't just a protocol, it's a >> whole deployment architecture. The credentials lose any semantics if >> they are divorced from the deployment environment you're supposed to >> fetch them from. All credentials must be uploaded through that central >> service and all credentials must be downloaded from its (distributed) > deployment. >> >> There doesn't need to be a "national authority" cloud service that >> manages access to certs in this way. The reason you trust a cert isn't >> because you downloaded it from the right place, it's because you trust >> the trust anchor that signed the cert. This isn't about HTTP - it >> doesn't matter if you found the cert lying on the ground. This is why >> I don't understand the need for "hard cider," or indeed why it would >> be important for a verification service to be able to derive a single >> canonical location from which it will download a cert by studying the > originating number alone. > > I agree that the in-band (or out of band) identifier/blob that the verifier > uses to construct the inputs to signature checking (esp. > the "right" public key) can be handled in various ways. And as you say the > blob could contain an RFC5280/X.509 certificate (chain) or the > identifier/blob could be used to retrieve a certificate (chain) or the > missing parts thereof. > > However, at some point you do need to support certificate status checking, > and for certs that means OCSP or CRLs. In either case the verifier has to do > some more work and access the network to get status information. > > The tricky point is that CRLs get big and unwieldy, or else are very complex > (e.g. delta CRLs [1], the support for which is I think highly variable and > maybe sometimes flakey). If you take the OCSP route then the verifier is > making a status check call to the network for each signature it verifies > (more-or-less), at which point DKIM-like models start to look quite similar. > > So I hope that the STIR wg, when formed, delves deeply into this question. I > doubt that the BoF or any proposal at the BoF can really provide final > answers (I include "hedge your bets" > as a proposed answer there btw). > > S. > > [1] http://tools.ietf.org/html/rfc5280#section-5.2.4 > > > >> I >> kind of see why this is important for a DNS-based solution (though the >> harm DNS URI Identity-Info would do there isn't clear to me - if it >> points to something you don't trust, don't trust it), but not for a >> cert-based solution. If you could, for example, just receive the cert >> in-band with the request, that would seem to obviate the need to go ask > anyone for it. >> >> I'm a bit unsure as well of the high-level structure of the arguments >> below, effectively that carriers are the only sorts of verifiers that >> matter, and that carriers probably can't use anything other than DNS. >> Carriers do matter, and so do enterprises, and so do endpoints, as >> potential verifiers. Of course it's true that carriers use DNS, as do >> enterprises and endpoints. But none of them perform anything like the >> STIR in-band verifier function today, and new code will have to be >> written and new stuff deployed to make this happen - arguing that this >> has to be the same stuff that's used for an unrelated existing >> function in the network just doesn't persuade, given the huge >> differences in usage. I don't think it would be unreasonable for DNS >> to play a role in credential delivery to verifiers, for environments >> where it makes sense. I don't see how this proposed use of the DNS has >> some decisive advantage over certificates, though. This makes me want >> to hedge bets from the start. I think the flexibility of something like > Identity-Info is a way to approach that. >> >> >> Jon Peterson >> Neustar, Inc. >> >> On 7/21/13 8:50 AM, "Hadriel Kaplan" wrote: >> >>> >>> I've been thinking about your questions and it occurred to me we may >>> be talking past each other, or I'm not being clear enough. It's hard >>> to discuss some of this stuff in email, but anyway let me try a >>> different tack... >>> >>> So far, there is one relatively concrete proposal for how HTTP would >>> be >>> used: RFC4474 or 4474bis, which use certs signed by someone, and >>> indicates where to get the cert in an HTTP URL encoded in the SIP >>> message Identity-Info header. That model has a whole host of issues, >>> and if by "HTTP" you mean that model, then we could drill-down on the >>> practical problems I believe it would have. >>> >>> There is another way it could work using HTTP, which is essentially >>> to copy the CIDER proposal but replace the DNS query-answer with HTTP >>> query-answer. The verifier would generate its own HTTP URL to >>> resolve, based on the received identity information in SIP, and we'd >>> define how it does that, what the cert model and encoding would be, >>> how it gets secured redirection, how it times out cached copies, how >>> to get the cert signer's cert, how to time that out, etc. Let's call >>> such a model "HARD CIDER", for "Http-based Access of Registry Data" >>> or some such.[1] >>> >>> For a Hard Cider model to be used in a public Internet access model, >>> we'd still be relying on DNS and DNSSEC, to perform resolution of the >>> HTTP URL in a secure manner. And using a generated HTTP URL implies >>> the national registries are deployed as a Google/Facebook/Amazon type >>> cloudy infrastructure with internal horizontal scaling technologies, >>> etc. But let's ignore that for now. >>> >>> The bigger problem is the target user environment: where we expect to >>> be using this stuff, in carriers. In practice, HTTP isn't frequently >>> used by real-time call-handling network devices in most carriers. It >>> is used by the carrier as a corporation of course, in various other >>> areas/groups/functions; and it's used in some call-control cases, >>> usually by application servers providing features for specific users >>> or calls, in specific scenarios. It's far less common to have it >>> used for every call, and essentially never gets used by SBCs or >>> X-CSCFs on an every-call basis. There are a variety of practical >>> reasons for that, but it doesn't really matter why. What matters is >>> it would be a barrier to deployability and adoption, in the real world, > if we chose it. >>> >>> Arguably, DIAMETER is a far more common protocol for many carriers to >>> use for this type of stuff than HTTP or even DNS. DIAMETER has its >>> own challenges in actual carrier deployments, mostly around >>> scalability and manageability, but we couldn't pick DIAMETER anyway >>> because it's only used in some carriers and not all carriers, and >>> rarely used by anyone else. >>> >>> As a protocol, DNS happens to be used by everyone - it's only used as >>> private ENUM by some carriers not all obviously, but virtually all of >>> them use DNS for at least hostname resolution, even internally. And >>> DNS client implementation happens to be available in code in all >>> systems, whether it be SBCs or X-CSCFs or app servers or whatever; >>> and its performance, scalability and manageability characteristics >>> happen to be really good in actual carrier deployments. >>> >>> Having said all that, another way we could go in STIR is to just >>> hedge our bets and define multiple protocols: DNS, HTTP, and maybe >>> even DIAMETER. To do that, though, it still has to be deployable as >>> DNS, still have to be based on the verifier generating the URL and >>> not have it sent by the originator, still have to specify the caching >>> and clearing behavior, still have to support both a centralized and >>> distributed model of database deployment for numbers, etc. We've >>> done that sort of hedging before in the IETF, rarely - it's a LOT >>> more work, obviously, but it lets the market decide for itself what to > do. >>> >>> If we do hedge our bets, however, I believe the most straight-forward >>> way to actually do that would be to define the DNS one *first*, and >>> then figure out the HTTP or DIAMETER mechanics required for doing the >>> same things accessing stuff from a deployed DNS database infrastructure. >>> That's because DNS as a protocol already defines the semantics, >>> mechanics, and database structure; and if its used in a public >>> Internet access manner then it's The Public DNS. So a use of HTTP or >>> DIAMETER would need to access it and follow its behavior. And that >>> has some bizarre deployment expectations for all parties, for example >>> for international call scenarios, or for an email-style identity model. >>> >>> A more reasonable approach might be to define the DNS model, and then >>> only define how an HTTP or DIAMETER access to the local DNS resolver >>> could also work, where the verifier can only be a stub. That's still >>> a lot of work, and still involves localhost caching rules and such, >>> but at least it constrains the problem somewhat. >>> >>> -hadriel >>> [1] I don't use the term "hard" to mean it will be hard, but rather >>> because "hard cider" happens to be a specific form of the drink known >>> as cider. :) >>> >>> >>> On Jul 20, 2013, at 8:13 PM, Hadriel Kaplan >>> >>> wrote: >>> >>>> >>>> On Jul 20, 2013, at 7:20 PM, Henning Schulzrinne >>>> wrote: >>>> >>>>> I don't see the "benefit" of DNS here. There are two cases, either way: >>>>> >>>>> (1) A standard DNS hierarchy, with caching, but no synchronization. >>>>> In that case, you need short TTLs if you care about revocation. >>>>> With short TTLs, you get one country-level RTT for every query, >>>>> even assuming no packet loss. >>>> >>>> By "one country-level RTT for every query", do you mean you get one >>>> RTT on average for every call, and the RTT is likely not long on >>>> average because it's to a server in your geographic country? If so, >>>> sure that would likely be the case for public internet access >>>> queriers. One RTT on average, for a public Internet access model is > pretty good, BTW. >>>> HTTP really won't have one RTT for such public Internet access, not >>>> in actual practice if this Identity-Info URL model is used. Again, >>>> this is not CIDER's raison d'etre, but just another plus. >>>> >>>> >>>>> (2) A locally-cached synchronized DNS hierarchy, using some kind of >>>>> rsync-like mechanism. >>>>> >>>>> You can get the same two versions for HTTP and certs. >>>> >>>> No, I really don't believe you can. You can get them if we give up >>>> on the Identity-Info URL thing, and define how HTTP would work >>>> without it, how the international call thing works, and so on. But >>>> not if the cert is served on some random server indicated by the > Identity-Info header. >>>> >>>> >>>>> The locally-cached synchronized DNS has essentially the same >>>>> overhead as the locally-cached HTTP version, since the connection is > nailed down. >>>> >>>> Define "overhead". Overhead for whom? For the verifier systems >>>> HTTP is more overhead - a trivial amount if the stars align, and >>>> more if reality is included in the equation; but not a massive >>>> amount regardless. For the carriers, HTTP is more cost and >>>> operational overhead from a deployment perspective if reality is >>>> included, but again if we ignore practical realties then it's all >>>> equal. So sure, if all carriers in all nations deploy Google or >>>> Facebook style infrastructures and tweak their verifiers' TCP and >>>> HTTP implementations - all for the benefit of verifying a caller-id >>>> - then we're all good-to-go. ;) >>>> >>>> -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 >> >> > _______________________________________________ > stir mailing 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 Jul 24 08:24: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 2B44F11E8247 for ; Wed, 24 Jul 2013 08:24:03 -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 tb5N+vyp6pPE for ; Wed, 24 Jul 2013 08:23: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 8E6C121F848E for ; Wed, 24 Jul 2013 08:22: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; Wed, 24 Jul 2013 08:22:06 -0700 From: Michael Hammer To: "stephen.farrell@cs.tcd.ie" Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) - attack model Thread-Index: AQHOhQaUpWBouCrQPUqwnzpS8YN+fJlumFIAgAAQQQCAAAISgIAADtuAgAEFx4CAA8W3gIAAm9gA///DMwCAAIV2AP//jo+Q Date: Wed, 24 Jul 2013 15:22:05 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC1D1BB@EX2K10MB1.corp.yaanatech.com> References: <51EFB00C.3050602@cs.tcd.ie> <00C069FD01E0324C9FFCADF539701DB3BBC1CDA5@EX2K10MB1.corp.yaanatech.com> <51EFED00.7030603@cs.tcd.ie> In-Reply-To: <51EFED00.7030603@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.97] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_008B_01CE8860.064E0F20" MIME-Version: 1.0 Cc: "stir@ietf.org" , "hadriel.kaplan@oracle.com" , "jon.peterson@neustar.biz" , "Henning.Schulzrinne@fcc.gov" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jul 2013 15:24:03 -0000 ------=_NextPart_000_008B_01CE8860.064E0F20 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sure. I am open to other ideas folks might have. I was thinking that one is proactive per call, and reactive for revocation, While the other option is reactive per call, and proactive for revocation. Would you consider CIDER as the mother of all Certs and CRLs all wrapped into one? Mike -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, July 24, 2013 11:05 AM To: Michael Hammer Cc: jon.peterson@neustar.biz; stir@ietf.org; hadriel.kaplan@oracle.com; Henning.Schulzrinne@fcc.gov Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model On 07/24/2013 03:07 PM, Michael Hammer wrote: > Don't forget though that CRL checks are an Idle state activity, not a > per call setup delaying activity. That could be the case, or maybe it isn't, I don't know. But full CRLs can easily get BIG, even if only consumed periodically. And you'd still need some models of how big in order to know if that's ok or not. So again, there is work to be done to figure that out for this application. Think of all this public key management like its a balloon. You can squeeze one bit to fit what you want but another will then protrude, possibly causing the whole thing to burst. (I guess since this is RAI that should be a liquid filled balloon, but I hope the analogy is clear enough:-) S. > > Mike > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of Stephen Farrell > Sent: Wednesday, July 24, 2013 6:44 AM > To: Peterson, Jon > Cc: stir@ietf.org Mail List; Hadriel Kaplan; Henning Schulzrinne > Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack > model > > > Hi Jon, > > I think you make some reasonable points below, but wanted to add a bit > to one of 'em. I've no position on whether or not STIR ought hedge its > bets on credential format/retrieval at the moment btw. so this is a > detail, but IMO one that's not insignificant. > > > On 07/24/2013 02:26 AM, Peterson, Jon wrote: >> >> I've been arguing that we hedge our bets too, but perhaps that we >> hedge them even more than you consider below. (Forgive me that I >> haven't closely tracked your tight loop with Mike Hammer, in case it >> sheds any light I miss here.) >> >> RFC4474 (/RFC4474bis) doesn't restrict access to certificates to HTTP >> fetches. RFC4474 is pretty agnostic about how you get certs. We >> talked about certs being included in SIP messages, so they'd arrive >> along with the signature. We talked about using SIP itself to fetch >> them, via SUBSCRIBE. We considered cases where verifiers had access >> to caches, or even local cert stores. At the time we were doing >> RFC4474, HTTP seemed like the right thing to hype for a number of >> reasons, so we > encouraged it. >> But the URL in Identity-Info is just supposed to be a helpful >> suggestion, not the sole and authoritative means of access to certs. >> For the STIR case, however, that hint might be useful to disambiguate >> for verifiers which authority signed a SIP request, when there are >> multiple authorities for a single number (the function the CIDER >> "public key index value" would serve, if I understand correctly). >> >> Part of the reason I think we're all talking past each other here is >> that certs are relatively self-contained documents, and you could get >> them in a number of ways, and I don't think there's any pressing need >> for us to restrict those ways. For DNS proposals (if they don't just >> stick CA certs in the DNS), on the other hand, the way you get a >> credential is inextricably coupled to the semantics of the credential >> itself, which is why the CIDER proposal isn't just a protocol, it's a >> whole deployment architecture. The credentials lose any semantics if >> they are divorced from the deployment environment you're supposed to >> fetch them from. All credentials must be uploaded through that >> central service and all credentials must be downloaded from its >> (distributed) > deployment. >> >> There doesn't need to be a "national authority" cloud service that >> manages access to certs in this way. The reason you trust a cert >> isn't because you downloaded it from the right place, it's because >> you trust the trust anchor that signed the cert. This isn't about >> HTTP - it doesn't matter if you found the cert lying on the ground. >> This is why I don't understand the need for "hard cider," or indeed >> why it would be important for a verification service to be able to >> derive a single canonical location from which it will download a cert >> by studying the > originating number alone. > > I agree that the in-band (or out of band) identifier/blob that the > verifier uses to construct the inputs to signature checking (esp. > the "right" public key) can be handled in various ways. And as you say > the blob could contain an RFC5280/X.509 certificate (chain) or the > identifier/blob could be used to retrieve a certificate (chain) or the > missing parts thereof. > > However, at some point you do need to support certificate status > checking, and for certs that means OCSP or CRLs. In either case the > verifier has to do some more work and access the network to get status information. > > The tricky point is that CRLs get big and unwieldy, or else are very > complex (e.g. delta CRLs [1], the support for which is I think highly > variable and maybe sometimes flakey). If you take the OCSP route then > the verifier is making a status check call to the network for each > signature it verifies (more-or-less), at which point DKIM-like models start to look quite similar. > > So I hope that the STIR wg, when formed, delves deeply into this > question. I doubt that the BoF or any proposal at the BoF can really > provide final answers (I include "hedge your bets" > as a proposed answer there btw). > > S. > > [1] http://tools.ietf.org/html/rfc5280#section-5.2.4 > > > >> I >> kind of see why this is important for a DNS-based solution (though >> the harm DNS URI Identity-Info would do there isn't clear to me - if >> it points to something you don't trust, don't trust it), but not for >> a cert-based solution. If you could, for example, just receive the >> cert in-band with the request, that would seem to obviate the need to >> go ask > anyone for it. >> >> I'm a bit unsure as well of the high-level structure of the arguments >> below, effectively that carriers are the only sorts of verifiers that >> matter, and that carriers probably can't use anything other than DNS. >> Carriers do matter, and so do enterprises, and so do endpoints, as >> potential verifiers. Of course it's true that carriers use DNS, as do >> enterprises and endpoints. But none of them perform anything like the >> STIR in-band verifier function today, and new code will have to be >> written and new stuff deployed to make this happen - arguing that >> this has to be the same stuff that's used for an unrelated existing >> function in the network just doesn't persuade, given the huge >> differences in usage. I don't think it would be unreasonable for DNS >> to play a role in credential delivery to verifiers, for environments >> where it makes sense. I don't see how this proposed use of the DNS >> has some decisive advantage over certificates, though. This makes me >> want to hedge bets from the start. I think the flexibility of >> something like > Identity-Info is a way to approach that. >> >> >> Jon Peterson >> Neustar, Inc. >> >> On 7/21/13 8:50 AM, "Hadriel Kaplan" wrote: >> >>> >>> I've been thinking about your questions and it occurred to me we may >>> be talking past each other, or I'm not being clear enough. It's >>> hard to discuss some of this stuff in email, but anyway let me try a >>> different tack... >>> >>> So far, there is one relatively concrete proposal for how HTTP would >>> be >>> used: RFC4474 or 4474bis, which use certs signed by someone, and >>> indicates where to get the cert in an HTTP URL encoded in the SIP >>> message Identity-Info header. That model has a whole host of >>> issues, and if by "HTTP" you mean that model, then we could >>> drill-down on the practical problems I believe it would have. >>> >>> There is another way it could work using HTTP, which is essentially >>> to copy the CIDER proposal but replace the DNS query-answer with >>> HTTP query-answer. The verifier would generate its own HTTP URL to >>> resolve, based on the received identity information in SIP, and we'd >>> define how it does that, what the cert model and encoding would be, >>> how it gets secured redirection, how it times out cached copies, how >>> to get the cert signer's cert, how to time that out, etc. Let's >>> call such a model "HARD CIDER", for "Http-based Access of Registry Data" >>> or some such.[1] >>> >>> For a Hard Cider model to be used in a public Internet access model, >>> we'd still be relying on DNS and DNSSEC, to perform resolution of >>> the HTTP URL in a secure manner. And using a generated HTTP URL >>> implies the national registries are deployed as a >>> Google/Facebook/Amazon type cloudy infrastructure with internal >>> horizontal scaling technologies, etc. But let's ignore that for now. >>> >>> The bigger problem is the target user environment: where we expect >>> to be using this stuff, in carriers. In practice, HTTP isn't >>> frequently used by real-time call-handling network devices in most >>> carriers. It is used by the carrier as a corporation of course, in >>> various other areas/groups/functions; and it's used in some >>> call-control cases, usually by application servers providing >>> features for specific users or calls, in specific scenarios. It's >>> far less common to have it used for every call, and essentially >>> never gets used by SBCs or X-CSCFs on an every-call basis. There >>> are a variety of practical reasons for that, but it doesn't really >>> matter why. What matters is it would be a barrier to deployability >>> and adoption, in the real world, > if we chose it. >>> >>> Arguably, DIAMETER is a far more common protocol for many carriers >>> to use for this type of stuff than HTTP or even DNS. DIAMETER has >>> its own challenges in actual carrier deployments, mostly around >>> scalability and manageability, but we couldn't pick DIAMETER anyway >>> because it's only used in some carriers and not all carriers, and >>> rarely used by anyone else. >>> >>> As a protocol, DNS happens to be used by everyone - it's only used >>> as private ENUM by some carriers not all obviously, but virtually >>> all of them use DNS for at least hostname resolution, even >>> internally. And DNS client implementation happens to be available >>> in code in all systems, whether it be SBCs or X-CSCFs or app servers >>> or whatever; and its performance, scalability and manageability >>> characteristics happen to be really good in actual carrier deployments. >>> >>> Having said all that, another way we could go in STIR is to just >>> hedge our bets and define multiple protocols: DNS, HTTP, and maybe >>> even DIAMETER. To do that, though, it still has to be deployable as >>> DNS, still have to be based on the verifier generating the URL and >>> not have it sent by the originator, still have to specify the >>> caching and clearing behavior, still have to support both a >>> centralized and distributed model of database deployment for >>> numbers, etc. We've done that sort of hedging before in the IETF, >>> rarely - it's a LOT more work, obviously, but it lets the market >>> decide for itself what to > do. >>> >>> If we do hedge our bets, however, I believe the most >>> straight-forward way to actually do that would be to define the DNS >>> one *first*, and then figure out the HTTP or DIAMETER mechanics >>> required for doing the same things accessing stuff from a deployed DNS database infrastructure. >>> That's because DNS as a protocol already defines the semantics, >>> mechanics, and database structure; and if its used in a public >>> Internet access manner then it's The Public DNS. So a use of HTTP >>> or DIAMETER would need to access it and follow its behavior. And >>> that has some bizarre deployment expectations for all parties, for >>> example for international call scenarios, or for an email-style identity model. >>> >>> A more reasonable approach might be to define the DNS model, and >>> then only define how an HTTP or DIAMETER access to the local DNS >>> resolver could also work, where the verifier can only be a stub. >>> That's still a lot of work, and still involves localhost caching >>> rules and such, but at least it constrains the problem somewhat. >>> >>> -hadriel >>> [1] I don't use the term "hard" to mean it will be hard, but rather >>> because "hard cider" happens to be a specific form of the drink >>> known as cider. :) >>> >>> >>> On Jul 20, 2013, at 8:13 PM, Hadriel Kaplan >>> >>> wrote: >>> >>>> >>>> On Jul 20, 2013, at 7:20 PM, Henning Schulzrinne >>>> wrote: >>>> >>>>> I don't see the "benefit" of DNS here. There are two cases, either way: >>>>> >>>>> (1) A standard DNS hierarchy, with caching, but no synchronization. >>>>> In that case, you need short TTLs if you care about revocation. >>>>> With short TTLs, you get one country-level RTT for every query, >>>>> even assuming no packet loss. >>>> >>>> By "one country-level RTT for every query", do you mean you get one >>>> RTT on average for every call, and the RTT is likely not long on >>>> average because it's to a server in your geographic country? If >>>> so, sure that would likely be the case for public internet access >>>> queriers. One RTT on average, for a public Internet access model >>>> is > pretty good, BTW. >>>> HTTP really won't have one RTT for such public Internet access, not >>>> in actual practice if this Identity-Info URL model is used. Again, >>>> this is not CIDER's raison d'etre, but just another plus. >>>> >>>> >>>>> (2) A locally-cached synchronized DNS hierarchy, using some kind >>>>> of rsync-like mechanism. >>>>> >>>>> You can get the same two versions for HTTP and certs. >>>> >>>> No, I really don't believe you can. You can get them if we give up >>>> on the Identity-Info URL thing, and define how HTTP would work >>>> without it, how the international call thing works, and so on. But >>>> not if the cert is served on some random server indicated by the > Identity-Info header. >>>> >>>> >>>>> The locally-cached synchronized DNS has essentially the same >>>>> overhead as the locally-cached HTTP version, since the connection >>>>> is > nailed down. >>>> >>>> Define "overhead". Overhead for whom? For the verifier systems >>>> HTTP is more overhead - a trivial amount if the stars align, and >>>> more if reality is included in the equation; but not a massive >>>> amount regardless. For the carriers, HTTP is more cost and >>>> operational overhead from a deployment perspective if reality is >>>> included, but again if we ignore practical realties then it's all >>>> equal. So sure, if all carriers in all nations deploy Google or >>>> Facebook style infrastructures and tweak their verifiers' TCP and >>>> HTTP implementations - all for the benefit of verifying a caller-id >>>> - then we're all good-to-go. ;) >>>> >>>> -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 >> >> > _______________________________________________ > stir mailing 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_008B_01CE8860.064E0F20 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcy NDE1MjIwNFowIwYJKoZIhvcNAQkEMRYEFKKmVP7ENDyr1/qiBvte/FdLty0mMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAaC1Rh3N1BACICkF6VjUjApxprol+xvkDBS5d+IbH 3A2SSRk2h1cV5buqjvvnqSA5eCz9TfuI3fIP9r18C4gU3hmq19Y3zXhUll6tleLd2glQINCD1mp+ RyH6F6crJP240zEFLH0hLUY3JZ/aVM61kmPx5DX91/tU0UKodzEE9XDFJsXtROIt97P/PHrvkC1p vlOA+If3FF/l/QW+6mxgPnHfA3yLFsW8GxFix6jfGCxmfJDCYm8nDpQuzOKWnAdjPhr/+Co4ceqi eRGlxJ9/eIlEjkRM/uIyXWfjUkQ2kdwxtNRIazU8bJR2dxvyYh7FlRuAWHzd+7B6dgx6uZtghQAA AAAAAA== ------=_NextPart_000_008B_01CE8860.064E0F20-- From hadriel.kaplan@oracle.com Wed Jul 24 08:37: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 CEB6621F8FCE for ; Wed, 24 Jul 2013 08:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHEYynTJxOV8 for ; Wed, 24 Jul 2013 08:37:03 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id A38FE11E814B for ; Wed, 24 Jul 2013 08:36: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 r6OFaCK3012793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Jul 2013 15:36:13 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 r6OFaCse025359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jul 2013 15:36:12 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 r6OFaBHj015376; Wed, 24 Jul 2013 15:36:11 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Jul 2013 08:36: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: <00C069FD01E0324C9FFCADF539701DB3BBC1CDE4@EX2K10MB1.corp.yaanatech.com> Date: Wed, 24 Jul 2013 11:36:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00C069FD01E0324C9FFCADF539701DB3BBC1A683@EX2K10MB1.corp.yaanatech.com> <6EF50BDB-3F41-49FE-83C1-20216D0D0BF0@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1BE03@EX2K10MB1.corp.yaanatech.com> <0073993E-1BC8-461C-9A7E-B5DCFC617DBF@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1C956@EX2K10MB1.corp.yaanatech.com> <011401ce87f2$75e5e880$61b1b980$@shockey.us> <51EF5925.8090904@dcrocker.net> <009101ce8872$73c47ff0$5b4d7fd0$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBC1CDE4@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 Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 15:37:11 -0000 I think they're both saying that whatever mechanisms we choose, it = should be an operational choice/decision how to deploy it. Rich's point = (and mine) is that while that's of course true, we also have to keep in = mind who the likely target operators of it will be, and try to fit it in = something they can do in practice. To your question: I was originally worried that using DNS for STIR would = require us to make the data publicly available, and put it in The Public = Internet DNS - in some ways I prefer and hope that it be publicly = available, because I think it will be safe to do that and it has some = additional benefits if it is publicly accessible, but I recognize that = it's not my/our decision to make. So the CIDER proposal allows it to be = deployed however the national admins want for themselves. The same = could be true of an HTTP-based solution of course. -hadriel On Jul 24, 2013, at 10:22 AM, Michael Hammer = wrote: > So, you are saying that any DNS-based solution would have to be = publicly > available? >=20 > Mike >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of > Richard Shockey > Sent: Wednesday, July 24, 2013 9:34 AM > To: dcrocker@bbiw.net > Cc: stir@ietf.org > Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) >=20 > Good point Dave ..=20 >=20 > I would never suggest that the design restrict the use to service = providers > only that IMHO the likely deployment scenarios would very heavily = depend on > the role carriers have in the real time communications space and the = known > hierarchy of authority for the numbering plan.=20 >=20 > What I am concerned about is that the design, at the very least, = understands > the ongoing constraints in the service provider architecture and does = not > propose some brand new mechanism that would be impossible to implement = by > carriers in a reasonable period of time. =20 >=20 > -----Original Message----- > From: Dave Crocker [mailto:dhc@dcrocker.net] > Sent: Wednesday, July 24, 2013 12:34 AM > To: Richard Shockey > Cc: stir@ietf.org > Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) >=20 > On 7/23/2013 11:17 PM, Richard Shockey wrote: >> I pay people to run the SMTP email servers for my domain. I expect=20= >> them to implement tools to reduce SPAM or I will just "port" my = domain > elsewhere. >=20 >=20 > This highlights a core bit of confusion in this discussion. It = concerns the > non-normative, architectural difference between may and must. >=20 > If the technology permits signing and validating use by end-systems = (users, > enterprises, whatever), then they have the /option/ of doing STIR. = The fact > that operational convenience makes is strongly likely that most/all = use will > be by intermediary systems such as service providers, rather than > end-systems, is only that: operational choice. >=20 > If the design restricts use to providers, then there is no opportunity = for > enterprises or end-users to sign or validate. >=20 > Believe it or not, some individuals and some enterprises still run = their own > SMTP servers. That folk like you and me don't does not make it = reasonable > to prevent others from doing it. >=20 > d/ >=20 > ps. DKIM is an example of this choice; it's almost exclusively = deployed > amongst service hosts; but in fact the architecture permits operation = with > user agents. >=20 >=20 > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From stephen.farrell@cs.tcd.ie Wed Jul 24 08:46: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 6C24211E8225 for ; Wed, 24 Jul 2013 08:46:00 -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 mH12056pSjwS for ; Wed, 24 Jul 2013 08:45:51 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C77DF11E8153 for ; Wed, 24 Jul 2013 08:45:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 22B8BBE6F; Wed, 24 Jul 2013 16:45:14 +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 pwxV0m-tYH0Y; Wed, 24 Jul 2013 16:45:14 +0100 (IST) Received: from [IPv6:2001:770:10:203:6175:d53c:cfbc:3379] (unknown [IPv6:2001:770:10:203:6175:d53c:cfbc:3379]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E8A8DBE6E; Wed, 24 Jul 2013 16:45:13 +0100 (IST) Message-ID: <51EFF68A.5090905@cs.tcd.ie> Date: Wed, 24 Jul 2013 16:45:14 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Michael Hammer References: <51EFB00C.3050602@cs.tcd.ie> <00C069FD01E0324C9FFCADF539701DB3BBC1CDA5@EX2K10MB1.corp.yaanatech.com> <51EFED00.7030603@cs.tcd.ie> <00C069FD01E0324C9FFCADF539701DB3BBC1D1BB@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC1D1BB@EX2K10MB1.corp.yaanatech.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "stir@ietf.org" , "hadriel.kaplan@oracle.com" , "jon.peterson@neustar.biz" , "Henning.Schulzrinne@fcc.gov" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jul 2013 15:46:03 -0000 On 07/24/2013 04:22 PM, Michael Hammer wrote: > Sure. I am open to other ideas folks might have. > > I was thinking that one is proactive per call, and reactive for revocation, > While the other option is reactive per call, and proactive for revocation. > > Would you consider CIDER as the mother of all Certs and CRLs all wrapped > into one? No. I don't think "mother of all" anything applies. I think its DKIM-like with all the associated pros and cons. S. > > Mike > > > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Wednesday, July 24, 2013 11:05 AM > To: Michael Hammer > Cc: jon.peterson@neustar.biz; stir@ietf.org; hadriel.kaplan@oracle.com; > Henning.Schulzrinne@fcc.gov > Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model > > > > On 07/24/2013 03:07 PM, Michael Hammer wrote: >> Don't forget though that CRL checks are an Idle state activity, not a >> per call setup delaying activity. > > That could be the case, or maybe it isn't, I don't know. > > But full CRLs can easily get BIG, even if only consumed periodically. And > you'd still need some models of how big in order to know if that's ok or > not. So again, there is work to be done to figure that out for this > application. > > Think of all this public key management like its a balloon. > You can squeeze one bit to fit what you want but another will then protrude, > possibly causing the whole thing to burst. (I guess since this is RAI that > should be a liquid filled balloon, but I hope the analogy is clear enough:-) > > S. > >> >> Mike >> >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Stephen Farrell >> Sent: Wednesday, July 24, 2013 6:44 AM >> To: Peterson, Jon >> Cc: stir@ietf.org Mail List; Hadriel Kaplan; Henning Schulzrinne >> Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack >> model >> >> >> Hi Jon, >> >> I think you make some reasonable points below, but wanted to add a bit >> to one of 'em. I've no position on whether or not STIR ought hedge its >> bets on credential format/retrieval at the moment btw. so this is a >> detail, but IMO one that's not insignificant. >> >> >> On 07/24/2013 02:26 AM, Peterson, Jon wrote: >>> >>> I've been arguing that we hedge our bets too, but perhaps that we >>> hedge them even more than you consider below. (Forgive me that I >>> haven't closely tracked your tight loop with Mike Hammer, in case it >>> sheds any light I miss here.) >>> >>> RFC4474 (/RFC4474bis) doesn't restrict access to certificates to HTTP >>> fetches. RFC4474 is pretty agnostic about how you get certs. We >>> talked about certs being included in SIP messages, so they'd arrive >>> along with the signature. We talked about using SIP itself to fetch >>> them, via SUBSCRIBE. We considered cases where verifiers had access >>> to caches, or even local cert stores. At the time we were doing >>> RFC4474, HTTP seemed like the right thing to hype for a number of >>> reasons, so we >> encouraged it. >>> But the URL in Identity-Info is just supposed to be a helpful >>> suggestion, not the sole and authoritative means of access to certs. >>> For the STIR case, however, that hint might be useful to disambiguate >>> for verifiers which authority signed a SIP request, when there are >>> multiple authorities for a single number (the function the CIDER >>> "public key index value" would serve, if I understand correctly). >>> >>> Part of the reason I think we're all talking past each other here is >>> that certs are relatively self-contained documents, and you could get >>> them in a number of ways, and I don't think there's any pressing need >>> for us to restrict those ways. For DNS proposals (if they don't just >>> stick CA certs in the DNS), on the other hand, the way you get a >>> credential is inextricably coupled to the semantics of the credential >>> itself, which is why the CIDER proposal isn't just a protocol, it's a >>> whole deployment architecture. The credentials lose any semantics if >>> they are divorced from the deployment environment you're supposed to >>> fetch them from. All credentials must be uploaded through that >>> central service and all credentials must be downloaded from its >>> (distributed) >> deployment. >>> >>> There doesn't need to be a "national authority" cloud service that >>> manages access to certs in this way. The reason you trust a cert >>> isn't because you downloaded it from the right place, it's because >>> you trust the trust anchor that signed the cert. This isn't about >>> HTTP - it doesn't matter if you found the cert lying on the ground. >>> This is why I don't understand the need for "hard cider," or indeed >>> why it would be important for a verification service to be able to >>> derive a single canonical location from which it will download a cert >>> by studying the >> originating number alone. >> >> I agree that the in-band (or out of band) identifier/blob that the >> verifier uses to construct the inputs to signature checking (esp. >> the "right" public key) can be handled in various ways. And as you say >> the blob could contain an RFC5280/X.509 certificate (chain) or the >> identifier/blob could be used to retrieve a certificate (chain) or the >> missing parts thereof. >> >> However, at some point you do need to support certificate status >> checking, and for certs that means OCSP or CRLs. In either case the >> verifier has to do some more work and access the network to get status > information. >> >> The tricky point is that CRLs get big and unwieldy, or else are very >> complex (e.g. delta CRLs [1], the support for which is I think highly >> variable and maybe sometimes flakey). If you take the OCSP route then >> the verifier is making a status check call to the network for each >> signature it verifies (more-or-less), at which point DKIM-like models > start to look quite similar. >> >> So I hope that the STIR wg, when formed, delves deeply into this >> question. I doubt that the BoF or any proposal at the BoF can really >> provide final answers (I include "hedge your bets" >> as a proposed answer there btw). >> >> S. >> >> [1] http://tools.ietf.org/html/rfc5280#section-5.2.4 >> >> >> >>> I >>> kind of see why this is important for a DNS-based solution (though >>> the harm DNS URI Identity-Info would do there isn't clear to me - if >>> it points to something you don't trust, don't trust it), but not for >>> a cert-based solution. If you could, for example, just receive the >>> cert in-band with the request, that would seem to obviate the need to >>> go ask >> anyone for it. >>> >>> I'm a bit unsure as well of the high-level structure of the arguments >>> below, effectively that carriers are the only sorts of verifiers that >>> matter, and that carriers probably can't use anything other than DNS. >>> Carriers do matter, and so do enterprises, and so do endpoints, as >>> potential verifiers. Of course it's true that carriers use DNS, as do >>> enterprises and endpoints. But none of them perform anything like the >>> STIR in-band verifier function today, and new code will have to be >>> written and new stuff deployed to make this happen - arguing that >>> this has to be the same stuff that's used for an unrelated existing >>> function in the network just doesn't persuade, given the huge >>> differences in usage. I don't think it would be unreasonable for DNS >>> to play a role in credential delivery to verifiers, for environments >>> where it makes sense. I don't see how this proposed use of the DNS >>> has some decisive advantage over certificates, though. This makes me >>> want to hedge bets from the start. I think the flexibility of >>> something like >> Identity-Info is a way to approach that. >>> >>> >>> Jon Peterson >>> Neustar, Inc. >>> >>> On 7/21/13 8:50 AM, "Hadriel Kaplan" wrote: >>> >>>> >>>> I've been thinking about your questions and it occurred to me we may >>>> be talking past each other, or I'm not being clear enough. It's >>>> hard to discuss some of this stuff in email, but anyway let me try a >>>> different tack... >>>> >>>> So far, there is one relatively concrete proposal for how HTTP would >>>> be >>>> used: RFC4474 or 4474bis, which use certs signed by someone, and >>>> indicates where to get the cert in an HTTP URL encoded in the SIP >>>> message Identity-Info header. That model has a whole host of >>>> issues, and if by "HTTP" you mean that model, then we could >>>> drill-down on the practical problems I believe it would have. >>>> >>>> There is another way it could work using HTTP, which is essentially >>>> to copy the CIDER proposal but replace the DNS query-answer with >>>> HTTP query-answer. The verifier would generate its own HTTP URL to >>>> resolve, based on the received identity information in SIP, and we'd >>>> define how it does that, what the cert model and encoding would be, >>>> how it gets secured redirection, how it times out cached copies, how >>>> to get the cert signer's cert, how to time that out, etc. Let's >>>> call such a model "HARD CIDER", for "Http-based Access of Registry Data" >>>> or some such.[1] >>>> >>>> For a Hard Cider model to be used in a public Internet access model, >>>> we'd still be relying on DNS and DNSSEC, to perform resolution of >>>> the HTTP URL in a secure manner. And using a generated HTTP URL >>>> implies the national registries are deployed as a >>>> Google/Facebook/Amazon type cloudy infrastructure with internal >>>> horizontal scaling technologies, etc. But let's ignore that for now. >>>> >>>> The bigger problem is the target user environment: where we expect >>>> to be using this stuff, in carriers. In practice, HTTP isn't >>>> frequently used by real-time call-handling network devices in most >>>> carriers. It is used by the carrier as a corporation of course, in >>>> various other areas/groups/functions; and it's used in some >>>> call-control cases, usually by application servers providing >>>> features for specific users or calls, in specific scenarios. It's >>>> far less common to have it used for every call, and essentially >>>> never gets used by SBCs or X-CSCFs on an every-call basis. There >>>> are a variety of practical reasons for that, but it doesn't really >>>> matter why. What matters is it would be a barrier to deployability >>>> and adoption, in the real world, >> if we chose it. >>>> >>>> Arguably, DIAMETER is a far more common protocol for many carriers >>>> to use for this type of stuff than HTTP or even DNS. DIAMETER has >>>> its own challenges in actual carrier deployments, mostly around >>>> scalability and manageability, but we couldn't pick DIAMETER anyway >>>> because it's only used in some carriers and not all carriers, and >>>> rarely used by anyone else. >>>> >>>> As a protocol, DNS happens to be used by everyone - it's only used >>>> as private ENUM by some carriers not all obviously, but virtually >>>> all of them use DNS for at least hostname resolution, even >>>> internally. And DNS client implementation happens to be available >>>> in code in all systems, whether it be SBCs or X-CSCFs or app servers >>>> or whatever; and its performance, scalability and manageability >>>> characteristics happen to be really good in actual carrier deployments. >>>> >>>> Having said all that, another way we could go in STIR is to just >>>> hedge our bets and define multiple protocols: DNS, HTTP, and maybe >>>> even DIAMETER. To do that, though, it still has to be deployable as >>>> DNS, still have to be based on the verifier generating the URL and >>>> not have it sent by the originator, still have to specify the >>>> caching and clearing behavior, still have to support both a >>>> centralized and distributed model of database deployment for >>>> numbers, etc. We've done that sort of hedging before in the IETF, >>>> rarely - it's a LOT more work, obviously, but it lets the market >>>> decide for itself what to >> do. >>>> >>>> If we do hedge our bets, however, I believe the most >>>> straight-forward way to actually do that would be to define the DNS >>>> one *first*, and then figure out the HTTP or DIAMETER mechanics >>>> required for doing the same things accessing stuff from a deployed DNS > database infrastructure. >>>> That's because DNS as a protocol already defines the semantics, >>>> mechanics, and database structure; and if its used in a public >>>> Internet access manner then it's The Public DNS. So a use of HTTP >>>> or DIAMETER would need to access it and follow its behavior. And >>>> that has some bizarre deployment expectations for all parties, for >>>> example for international call scenarios, or for an email-style identity > model. >>>> >>>> A more reasonable approach might be to define the DNS model, and >>>> then only define how an HTTP or DIAMETER access to the local DNS >>>> resolver could also work, where the verifier can only be a stub. >>>> That's still a lot of work, and still involves localhost caching >>>> rules and such, but at least it constrains the problem somewhat. >>>> >>>> -hadriel >>>> [1] I don't use the term "hard" to mean it will be hard, but rather >>>> because "hard cider" happens to be a specific form of the drink >>>> known as cider. :) >>>> >>>> >>>> On Jul 20, 2013, at 8:13 PM, Hadriel Kaplan >>>> >>>> wrote: >>>> >>>>> >>>>> On Jul 20, 2013, at 7:20 PM, Henning Schulzrinne >>>>> wrote: >>>>> >>>>>> I don't see the "benefit" of DNS here. There are two cases, either > way: >>>>>> >>>>>> (1) A standard DNS hierarchy, with caching, but no synchronization. >>>>>> In that case, you need short TTLs if you care about revocation. >>>>>> With short TTLs, you get one country-level RTT for every query, >>>>>> even assuming no packet loss. >>>>> >>>>> By "one country-level RTT for every query", do you mean you get one >>>>> RTT on average for every call, and the RTT is likely not long on >>>>> average because it's to a server in your geographic country? If >>>>> so, sure that would likely be the case for public internet access >>>>> queriers. One RTT on average, for a public Internet access model >>>>> is >> pretty good, BTW. >>>>> HTTP really won't have one RTT for such public Internet access, not >>>>> in actual practice if this Identity-Info URL model is used. Again, >>>>> this is not CIDER's raison d'etre, but just another plus. >>>>> >>>>> >>>>>> (2) A locally-cached synchronized DNS hierarchy, using some kind >>>>>> of rsync-like mechanism. >>>>>> >>>>>> You can get the same two versions for HTTP and certs. >>>>> >>>>> No, I really don't believe you can. You can get them if we give up >>>>> on the Identity-Info URL thing, and define how HTTP would work >>>>> without it, how the international call thing works, and so on. But >>>>> not if the cert is served on some random server indicated by the >> Identity-Info header. >>>>> >>>>> >>>>>> The locally-cached synchronized DNS has essentially the same >>>>>> overhead as the locally-cached HTTP version, since the connection >>>>>> is >> nailed down. >>>>> >>>>> Define "overhead". Overhead for whom? For the verifier systems >>>>> HTTP is more overhead - a trivial amount if the stars align, and >>>>> more if reality is included in the equation; but not a massive >>>>> amount regardless. For the carriers, HTTP is more cost and >>>>> operational overhead from a deployment perspective if reality is >>>>> included, but again if we ignore practical realties then it's all >>>>> equal. So sure, if all carriers in all nations deploy Google or >>>>> Facebook style infrastructures and tweak their verifiers' TCP and >>>>> HTTP implementations - all for the benefit of verifying a caller-id >>>>> - then we're all good-to-go. ;) >>>>> >>>>> -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 >>> >>> >> _______________________________________________ >> stir mailing 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 Jul 24 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 D95BC11E821C for ; Wed, 24 Jul 2013 08:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npEC+g8is0vw for ; Wed, 24 Jul 2013 08:46:38 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA7111E80EA for ; Wed, 24 Jul 2013 08:46:37 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 9F39632576F; Wed, 24 Jul 2013 17:46:36 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 83BE44C06B; Wed, 24 Jul 2013 17:46:36 +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, 24 Jul 2013 17:46:36 +0200 From: To: Hadriel Kaplan Thread-Topic: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt Thread-Index: AQHOfrnJIrVpZ/tZPUKeljXpre8LSZlychJwgABBJQCAANhWAIAAMFyAgAAkSPA= Date: Wed, 24 Jul 2013 15:46:35 +0000 Message-ID: <17414_1374680796_51EFF6DC_17414_333_1_B5939C6860701C49AA39C5DA5189448B0B5956@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <20130712043221.11767.74779.idtracker@ietfa.amsl.com> <1F4B4D44-BD3E-4995-876A-147832C925F9@oracle.com> <19893_1374596593_51EEADF1_19893_9071_1_B5939C6860701C49AA39C5DA5189448B0B55A6@PEXCVZYM12.corporate.adroot.infra.ftgroup> <15BB6D07-F5D4-4945-80B9-0648CB32A6CA@oracle.com> <7699_1374659827_51EFA4F3_7699_4570_1_B5939C6860701C49AA39C5DA5189448B0B576C@PEXCVZYM12.corporate.adroot.infra.ftgroup> <4380BD56-E3E5-4CBD-B329-2D9964F91E01@oracle.com> In-Reply-To: <4380BD56-E3E5-4CBD-B329-2D9964F91E01@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.6.28.101520 Cc: "stir@ietf.org" Subject: Re: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jul 2013 15:46:46 -0000 Thanks for the clarifications. Some comments in-line.=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: Wednesday, July 24, 2013 2:58 PM To: FOUQUART Philippe OLNC/OLN Cc: stir@ietf.org Subject: Re: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt On Jul 24, 2013, at 5:57 AM, philippe.fouquart@orange.com wrote: > [PhF] Thanks, I get the picture now (apologies maybe I should have starte= d with cider, always better to start with the lighter stuff first).=20 >=20 > I find the term canonical a bit misleading then for two reasons:=20 > - the point of converting into a canonical form to me is to have a unique= form upon which all subsequent operations can be done whilst the non canon= ical form and related information that lead to it may be discarded altogeth= er. I now understand why the draft insists on the IKES Generator using the = "source identity type" in addition to the "canonical identity", it's just t= hat having two distinct numbers (albeit of a different nature) leading to e= xactly the same "canonical" string to be processed and signed differently d= epending on their 'type' is quite confusing.=20 Just to be clear, they're not the same canonical *IKES* string in the end -= an E.164 would end up with a "G:" in front, while a number-code would end = up with a "C:" in front, for the IKES-IF string. [PhF] OK, thanks. Well then maybe the trick would be to say just that, "can= onical IKES string", or even indeed "normalized IKES string", (eg Determini= ng the normalized IKES string for E.164 Numbers and Number Codes for 4.2) r= ather than canonical form, and say as you put it that it's "only used for I= KES processing internally in the IKES generator/verifier". > - "canonical [E.164] form" for a number is as you know a very common term= to describe the international E.164 format of a number stripped out of the= visual separators. The canonical form in the draft is not that, well, expe= ct for the E.164 numbers... I wouldn't like this "canonical" form to appear= 'as is' in RU/To or From, for that matter, as I said in some numbering pla= ns in would be problematic.=20 Right it doesn't change the SIP message at all, and is only used for IKES p= rocessing internally in the IKES generator/verifier. Can you suggest a bet= ter word than "canonical"? I was thinking "normalized" but that word is al= so commonly used. > Maybe that would be preferable to use a different term; if you'd rather n= ot, maybe you want to add something along the lines of 3966 that says that = "converting a nationally-specific number code into its canonical form/strin= g does not make it a valid E.164 number: the string consisting of the leadi= ng country-code prepended to the number code cannot be assumed to be a vali= d E.164 number"=20 I will add that line too - thanks! But I agree with your earlier comment a= s well that using a different term might help. > [PhF] Well, sort of: a) not all of them are in "controlled environments" = b) it is not uncommon in national "PSTN" interconnect offerings to support = this and pass it on transparently and c) this type of access may actually b= e the source if not maliciously-faked, at least erroneously-configured call= er-id. Maybe for c) depending on their use of the UUI, they could privately= /bilaterally come up with an index of sort to assert the "on-net" calls, bu= t I think that's just too complex. Right, but the "threat" for STIR is that someone receiving a INVITE/IAM get= s a calling party number that it uses for caller-id display (or whatever) a= nd the number is being maliciously misrepresented. Obviously we don't know= when it's being maliciously misrepresented or just an honest mistake/error= , and many INVITES/IAMs won't be signed at all at least in the beginning, s= o we likely won't be able to block such calls for a very long time if ever.= Instead we'll either anonymize the calling number (block number display),= or check with some other policy engine, or log it for later analysis, or s= end it to an IVR, or whatever - it's a local policy decision really. So assume you get a INVITE/IAM with a RFC 6567 UUI. It would be a local po= licy decision what to do. You can decide that the destination subscriber d= oesn't have a UUI service, for example a mobile/home phone wouldn't, and th= us treat it as an unsigned call and anonymize the calling number or block i= t or whatever. Or you can decide that the SIP Trunk to an Enterprise has s= uch UUI "service", and pass the INVITE/IAM on to it unchanged as you do tod= ay. The IP-PBX is then responsible for deciding whether the INVITE/IAM wit= h such a UUI is valid/allowed - for example if it's from a branch office or= whatever. That's what it has to decide already today, and we don't seem t= o have a spoofed caller problem for those cases today.=20 The danger with letting a RFC 6567 UUI trump an IKES UUI is that malicious = sources could just start=20 adding RFC 6567 UUIs to their INVITEs. We can easily detect and block that= for destinations that don't=20 expect to get 6567 UUIs. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^=20 [PhF] I'm missing something here: how does an interconnect point detect tha= t a particular end site expect UUI or not? Suppose one of your malicious so= urce adds those RFC 6567 UUIs to get through, how would you possibly know u= pstream whether it is legitimate or not, as you said it's a local policy?= =20 The hard part is how to block it for IP-PBXs that do expect 6567 UUIs.=20= =20 [PhF] It seems to me that part of the problem is precisely that you don't k= now which do and which don't.=20=20 If it becomes a problem, there are some potential solutions. One solution = is to only support 6567 UUI for inter-branch calls that stay SIP along the = whole path (since the IKES info is in a SIP header, it can be used at the s= ame time as 6567 UUI for SIP). That's not unreasonable, because as far as = I know such inter-branch calls typically only work within the same carrier,= or only within a small set of fixed/known/pre-arranged set of carriers in = a country.=20=20 If that's true, then it's not unreasonable to expect the small set of carri= ers to support SIP interconnect,=20 [PhF] As an aside, even if they did support SIP interconnect, this seems to= assume that you don't have ISUP or some encapsulation of it in parallel/ad= dition to "full SIP".=20 at least by the time this becomes a problem. So the IP-PBX or penultimate = carrier can have a local policy that it only believes INVITE/IAM with 6567 = UUI if it also has a valid IKES info in a SIP header; and the IP-PBX can ev= en have a local policy that only allows it if the validated number is for a= number it allows to use 6567 UUI for (ie, it knows the branch office priva= te number), etc. -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 hadriel.kaplan@oracle.com Wed Jul 24 09:09: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 E13F511E812A for ; Wed, 24 Jul 2013 09:09:43 -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.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKFjU-YG7Zdx for ; Wed, 24 Jul 2013 09:09:37 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 47B6B21F848E for ; Wed, 24 Jul 2013 09:09:37 -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 r6OG9Wl4027666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Jul 2013 16:09:33 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 r6OG9Wvv022036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jul 2013 16:09:32 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 r6OG9VcD022021; Wed, 24 Jul 2013 16:09:31 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Jul 2013 09:09: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: Wed, 24 Jul 2013 12:09:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9B548746-39BF-45CE-86E0-5648E10EC96E@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 Mail List" , Henning Schulzrinne Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jul 2013 16:09:44 -0000 Commenting on your email in reverse-order... On Jul 23, 2013, at 9:26 PM, "Peterson, Jon" = wrote: > I'm a bit unsure as well of the high-level structure of the arguments > below, effectively that carriers are the only sorts of verifiers that > matter, and that carriers probably can't use anything other than DNS. I didn't say that - I said they're an important (even vital) target = deployer/adopter of STIR, and that requiring them to use HTTP for the = querying would be a barrier to adoption, and that I think we need to = avoid adding barriers to adoption by the target users/operators. > Carriers do matter, and so do enterprises, and so do endpoints, as > potential verifiers. Of course it's true that carriers use DNS, as do > enterprises and endpoints. But none of them perform anything like the = STIR > in-band verifier function today, and new code will have to be written = and > new stuff deployed to make this happen My goal is to reduce the amount of "new stuff" that needs to be deployed = as much as possible. Upgrading software is one thing, but deploying = entire classes of new systems is a much higher barrier to adoption. = This stuff really does matter. The effort, time and cost required for = software upgrades vs. new systems is enormously different. End-users = can upgrade apps or download new ones, and Enterprises can too for that = matter, without much difficulty. But getting carriers to adopt = something new is a whole different ballgame. You know that. The = impacts of scale, capacity, troubleshooting, and management are on a = different order of magnitude for carriers. > - arguing that this has to be the > same stuff that's used for an unrelated existing function in the = network > just doesn't persuade, given the huge differences in usage. On the contrary, some carriers use private ENUM/DNS for things eerily = similar to, and directly related to, STIR. They use them for CNAM = lookups, which is arguably the exact same point in time and place where = they'd be verifying a caller-id, right before a CNAM lookup, to verify = they're querying for the right CNAM. In fact, the local physical CNAM = servers being queried could respond with both data records at the same = time in the same DNS answer, if they're tied into the STIR database. = For example, you query it for the STIR DNS query key, and it responds = with the TXT RR public key as well as a calling-name NAPTR in the same = answer. Even if it takes two separate DNS queries, but to the same = server, that makes it easier to deploy and manage for the carriers. So there is existing proof contradicting the claim: "none of them = perform anything like STIR" today. Even the deployed server vendors used for routing and number = portability, which already either have the full NPAC copy themselves or = perform some other protocol query to it in the back-end, would be likely = candidates for being the same servers queried by verifiers for STIR = data; likewise for the deployed systems that query them. And some of = those use private ENUM already today. Far more than use HTTP, afaict. -hadriel From housley@vigilsec.com Wed Jul 24 10:25:46 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A443411E8125 for ; Wed, 24 Jul 2013 10:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.692 X-Spam-Level: X-Spam-Status: No, score=-102.692 tagged_above=-999 required=5 tests=[AWL=-0.093, 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 sycvSL9RyipX for ; Wed, 24 Jul 2013 10:25:40 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id B36EC11E8105 for ; Wed, 24 Jul 2013 10:25:39 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 9D24AF2407E for ; Wed, 24 Jul 2013 13:25:50 -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 D9nIhmTDKe4N for ; Wed, 24 Jul 2013 13:25:30 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-154-95.washdc.fios.verizon.net [96.241.154.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 5A7B3F24130 for ; Wed, 24 Jul 2013 13:25:44 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: Date: Wed, 24 Jul 2013 13:25:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3D42BC84-3EC6-4760-BB31-5E412945BB24@vigilsec.com> References: To: IETF STIR Mail List X-Mailer: Apple Mail (2.1085) Subject: Re: [stir] Call for scribes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jul 2013 17:25:46 -0000 Dan York has volunteered to be a jabber scribe. We still need someone = to take minutes. Without someone to take minutes, there will not be a = meeting. Please volunteer. Russ On Jul 17, 2013, at 11:43 AM, Russ Housley wrote: > We are looking for volunteers to take minutes and jabber scribe during = the STIR BOF in Berlin. Please volunteer. >=20 > Thanks in advance, > Russ >=20 From york@isoc.org Wed Jul 24 10:37: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 8F56311E8243 for ; Wed, 24 Jul 2013 10:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Xj6E3-E8bXI7 for ; Wed, 24 Jul 2013 10:37:25 -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 C76F111E81DB for ; Wed, 24 Jul 2013 10:37:25 -0700 (PDT) Received: from BLUPR06MB067.namprd06.prod.outlook.com (10.242.187.146) by BLUPR06MB067.namprd06.prod.outlook.com (10.242.187.146) with Microsoft SMTP Server (TLS) id 15.0.731.16; Wed, 24 Jul 2013 17:37:16 +0000 Received: from BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.198]) by BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.185]) with mapi id 15.00.0731.000; Wed, 24 Jul 2013 17:37:15 +0000 From: Dan York To: Russ Housley , IETF STIR Mail List Thread-Topic: [stir] Call for scribes Thread-Index: AQHOgwRyXvFrLydWC0q6tIXA8q6xoJl0H5AA///ANwA= Date: Wed, 24 Jul 2013 17:37:14 +0000 Message-ID: In-Reply-To: <3D42BC84-3EC6-4760-BB31-5E412945BB24@vigilsec.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: 0917DFAC67 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(479174003)(199002)(189002)(24454002)(76786001)(46102001)(76796001)(76176001)(56816003)(74876001)(80022001)(53806001)(81542001)(56776001)(81342001)(16406001)(54356001)(54316002)(47446002)(83072001)(19580395003)(69226001)(74366001)(83322001)(19580405001)(74662001)(31966008)(74502001)(65816001)(50986001)(47736001)(49866001)(47976001)(76482001)(77096001)(36756003)(74706001)(77982001)(59766001)(79102001)(51856001)(63696002)(4396001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB067; H:BLUPR06MB067.namprd06.prod.outlook.com; CLIP:10.255.101.4; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <2C26EC91E22C7844B553873F7DC4019C@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org Subject: Re: [stir] Call for scribes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jul 2013 17:37:35 -0000 On 7/24/13 1:25 PM, "Russ Housley" wrote: >Dan York has volunteered to be a jabber scribe. I'd also love it if someone else would volunteer to be a "backup" jabber scribe in case there are moments when I am unable to monitor the jabber room (such as when I might go to the mic, which may or may not happen... but, knowing me, probably will). Dan From stpeter@stpeter.im Wed Jul 24 10:42: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 B379411E80F9 for ; Wed, 24 Jul 2013 10:42:05 -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 KSiho--E+gYY for ; Wed, 24 Jul 2013 10:41:50 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C304E11E80F3 for ; Wed, 24 Jul 2013 10:41:50 -0700 (PDT) Received: from sjc-vpn5-361.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AE95640044; Wed, 24 Jul 2013 11:43:42 -0600 (MDT) Message-ID: <51F011DC.5030904@stpeter.im> Date: Wed, 24 Jul 2013 11:41:48 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: stir@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [stir] Call for scribes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jul 2013 17:42:05 -0000 On 7/24/13 11:37 AM, Dan York wrote: > On 7/24/13 1:25 PM, "Russ Housley" wrote: > > >> Dan York has volunteered to be a jabber scribe. > > I'd also love it if someone else would volunteer to be a "backup" jabber > scribe in case there are moments when I am unable to monitor the jabber > room (such as when I might go to the mic, which may or may not happen... > but, knowing me, probably will). I can do that. Peter -- Peter Saint-Andre https://stpeter.im/ From housley@vigilsec.com Wed Jul 24 11:22: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 8DDDE11E824C for ; Wed, 24 Jul 2013 11:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.686 X-Spam-Level: X-Spam-Status: No, score=-102.686 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 mQkdl2hB7MhJ for ; Wed, 24 Jul 2013 11:22:37 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id CBE7B11E824B for ; Wed, 24 Jul 2013 11:22:19 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id CEC13F24125; Wed, 24 Jul 2013 14:21:56 -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 c-NEtT4PEIJh; Wed, 24 Jul 2013 14:21:41 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-154-95.washdc.fios.verizon.net [96.241.154.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id C7BFFF2407E; Wed, 24 Jul 2013 14:21:54 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley X-Priority: 2 (High) In-Reply-To: <51EEA962.8090302@dcrocker.net> Date: Wed, 24 Jul 2013 14:21:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51EEA962.8090302@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1085) Cc: "stir@ietf.org" Subject: Re: [stir] Fwd: 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, 24 Jul 2013 18:22:42 -0000 Dave: I do not see any barriers to forming a WG. Form my perspective, we = should write the charter in a manner that allows the various identified = approaches to be within the scope. In that way, the WG can discussion = them and move forward where there is consensus. I do not anticipate = smooth sailing, but I hope we can have a technical debate with out name = calling and the like. That said, I expect the BOF will argue about the need for in-band, = out-of-band, both, and in what order. This discussion will impact the = words in the charter. Russ On Jul 23, 2013, at 12:03 PM, Dave Crocker wrote: > Russ, et al, >=20 > Dan's query prompted a bit of reflection for me, one result of which = was thinking that a bit of reflection might be good for us all... >=20 > The enclosed provides a rather particular basis for evaluating the = creation of a working group. As we saw immediately after it was posted, = it still leaves some room for debate about its meaning and, therefore, = the detailed criteria that should be applied from it. Still, it's a = view that has substance and especially pragmatics. >=20 > And it was a month ago, and we've continued with list discussions. >=20 > To the extent that you, Russ, have seen discussion that seemed to be = moving towards convergence, or seemed not to, it could be very helpful = to obtain your summary feedback, as of now. >=20 > In effect, I'm asking you to do a bit of an audit, highlighting = barriers you currently see to the formation of a working group. >=20 > This will give us roughly a week to disagree with your assessment and = gain support for the disagreement or -- stated more constructively -- to = scramble to obtain convergence where it is missing. >=20 > Thanks. >=20 > d/ >=20 >=20 > -------- Original Message -------- > Subject: Re: [stir] Do we agree on the basics? > Date: Wed, 19 Jun 2013 17:19:23 -0400 > From: Russ Housley > To: Hadriel Kaplan > CC: stir@ietf.org >=20 > Hadriel: >=20 >> 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 > Russ >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 >=20 >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From jon.peterson@neustar.biz Wed Jul 24 15:36: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 3E38B11E8136 for ; Wed, 24 Jul 2013 15:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.88 X-Spam-Level: X-Spam-Status: No, score=-105.88 tagged_above=-999 required=5 tests=[AWL=0.719, 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 Lgn5NlJlahYx for ; Wed, 24 Jul 2013 15:36:07 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 7C21A11E811E for ; Wed, 24 Jul 2013 15:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1374705269; x=1690059323; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=4YusbHfvGl ee1yeFeowKs7NrYBNSGWtz1ZcVNhft8DE=; b=aLkGEAFn+BU8BiwpRy0HCvFmac 7HrPAppVyoSqys7RemyS9RcL1AvNCHhZn0VJPnPkQfVbjzJMpCoMFB6fkPSw== Received: from ([10.31.58.71]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.21463509; Wed, 24 Jul 2013 18:34:28 -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, 24 Jul 2013 18:35:50 -0400 From: "Peterson, Jon" To: Stephen Farrell Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) - attack model Thread-Index: AQHOhN3XlLvfS0GEU02eRKlH1yvyDZltRmkAgAEf8ACAABBBAIAAAhKAgAAO24CAAQXHgIADUFyAgAERMwCAAFFkgA== Date: Wed, 24 Jul 2013 22:35:49 +0000 Message-ID: In-Reply-To: <51EFB00C.3050602@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.149] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: foxMKagqj4UTGLN/3ZTI7Q== Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6F43CB2BF8CDB94D936B47F560166AE6@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org Mail List" , Hadriel Kaplan , Henning Schulzrinne Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jul 2013 22:36:11 -0000 Understood that there are trade-offs in maintaining cert freshness, just as there are trade-offs in maintaining the freshness of DNS records (caching, TTLs, etc.) I don't mean to suggest that there's no need for a function like OCSP, nor that if you had to do OCSP, this wouldn't have similar properties to making a DNS query. I guess that when you try to engineer either approach to the same operational requirements, in terms of how fresh credentials must be and how often you check them, they're going to end up with some very similar properties. This is kind of a worst-case scenario for reaching consensus, though, because it's always hardest to choose between things that are similar. That=B9s why I believe a beauty contest, or a food fight, would take a huge amount of effort, possibly wasted effort given that market forces could find a place for either or both. There are subtle differences though, I think, and they have a lot to do with how well delegation models map to the authority structures of the telephone network, and how we scope credentials and aggregate authority. Some of this is relevant to freshness, even. This gets into questions that are way beyond BoF scope and well into the proposed working group, but imagine a Carrier A wants to have a single credential that can sign for all their numbers (and say Carrier A isn't worried about what verifiers could analyze from that). Imagine they control many large discontinuous blocks of numbers. We could build a DNS service that synthesizes responses and returns to verifiers the same public key for all the numbers that Carrier A is authoritative for. The caching properties of that approach, though, could be very different than having a single public cert that has that entire number range under its authority. Now imagine that instead of just one such credential, Carrier A may want five, or fifteen, or fifty, all with the same authority, that it wants to put into different signing systems in different parts of their network. From my experience dealing with the back office of telephone number authority services, I'd say these are quite plausible requirements. I'm not saying I have all the answers for how to approach scenarios like that, just that these are the kinds of things we would be taking into account if we chartered work in this credential space. For the level of discussion to have at the BoF, I think it's sufficient for us to say that we believe there are approaches to providing authority for telephone numbers that will work, even if we don't currently agree on any single direction. Jon Peterson Neustar, Inc. On 7/24/13 3:44 AM, "Stephen Farrell" wrote: > >Hi Jon, > >I think you make some reasonable points below, but wanted to >add a bit to one of 'em. I've no position on whether or not >STIR ought hedge its bets on credential format/retrieval at >the moment btw. so this is a detail, but IMO one that's not >insignificant. > >On 07/24/2013 02:26 AM, Peterson, Jon wrote: >>=20 >> I've been arguing that we hedge our bets too, but perhaps that we hedge >> them even more than you consider below. (Forgive me that I haven't >>closely >> tracked your tight loop with Mike Hammer, in case it sheds any light I >> miss here.) >>=20 >> RFC4474 (/RFC4474bis) doesn't restrict access to certificates to HTTP >> fetches. RFC4474 is pretty agnostic about how you get certs. We talked >> about certs being included in SIP messages, so they'd arrive along with >> the signature. We talked about using SIP itself to fetch them, via >> SUBSCRIBE. We considered cases where verifiers had access to caches, or >> even local cert stores. At the time we were doing RFC4474, HTTP seemed >> like the right thing to hype for a number of reasons, so we encouraged >>it. >> But the URL in Identity-Info is just supposed to be a helpful >>suggestion, >> not the sole and authoritative means of access to certs. For the STIR >> case, however, that hint might be useful to disambiguate for verifiers >> which authority signed a SIP request, when there are multiple >>authorities >> for a single number (the function the CIDER "public key index value" >>would >> serve, if I understand correctly). >>=20 >> Part of the reason I think we're all talking past each other here is >>that >> certs are relatively self-contained documents, and you could get them >>in a >> number of ways, and I don't think there's any pressing need for us to >> restrict those ways. For DNS proposals (if they don't just stick CA >>certs >> in the DNS), on the other hand, the way you get a credential is >> inextricably coupled to the semantics of the credential itself, which is >> why the CIDER proposal isn't just a protocol, it's a whole deployment >> architecture. The credentials lose any semantics if they are divorced >>from >> the deployment environment you're supposed to fetch them from. All >> credentials must be uploaded through that central service and all >> credentials must be downloaded from its (distributed) deployment. >>=20 >> There doesn't need to be a "national authority" cloud service that >>manages >> access to certs in this way. The reason you trust a cert isn't because >>you >> downloaded it from the right place, it's because you trust the trust >> anchor that signed the cert. This isn't about HTTP - it doesn't matter >>if >> you found the cert lying on the ground. This is why I don't understand >>the >> need for "hard cider," or indeed why it would be important for a >> verification service to be able to derive a single canonical location >>from >> which it will download a cert by studying the originating number alone. > >I agree that the in-band (or out of band) identifier/blob that the >verifier uses to construct the inputs to signature checking (esp. >the "right" public key) can be handled in various ways. And as you >say the blob could contain an RFC5280/X.509 certificate (chain) or >the identifier/blob could be used to retrieve a certificate (chain) >or the missing parts thereof. > >However, at some point you do need to support certificate status >checking, and for certs that means OCSP or CRLs. In either case >the verifier has to do some more work and access the network to >get status information. > >The tricky point is that CRLs get big and unwieldy, or else are >very complex (e.g. delta CRLs [1], the support for which is I >think highly variable and maybe sometimes flakey). If you take >the OCSP route then the verifier is making a status check call >to the network for each signature it verifies (more-or-less), >at which point DKIM-like models start to look quite similar. > >So I hope that the STIR wg, when formed, delves deeply into this >question. I doubt that the BoF or any proposal at the BoF >can really provide final answers (I include "hedge your bets" >as a proposed answer there btw). > >S. > >[1] http://tools.ietf.org/html/rfc5280#section-5.2.4 > > > >> I >> kind of see why this is important for a DNS-based solution (though the >> harm DNS URI Identity-Info would do there isn't clear to me - if it >>points >> to something you don't trust, don't trust it), but not for a cert-based >> solution. If you could, for example, just receive the cert in-band with >> the request, that would seem to obviate the need to go ask anyone for >>it. >>=20 >> I'm a bit unsure as well of the high-level structure of the arguments >> below, effectively that carriers are the only sorts of verifiers that >> matter, and that carriers probably can't use anything other than DNS. >> Carriers do matter, and so do enterprises, and so do endpoints, as >> potential verifiers. Of course it's true that carriers use DNS, as do >> enterprises and endpoints. But none of them perform anything like the >>STIR >> in-band verifier function today, and new code will have to be written >>and >> new stuff deployed to make this happen - arguing that this has to be the >> same stuff that's used for an unrelated existing function in the network >> just doesn't persuade, given the huge differences in usage. I don't >>think >> it would be unreasonable for DNS to play a role in credential delivery >>to >> verifiers, for environments where it makes sense. I don't see how this >> proposed use of the DNS has some decisive advantage over certificates, >> though. This makes me want to hedge bets from the start. I think the >> flexibility of something like Identity-Info is a way to approach that. >>=20 >>=20 >> Jon Peterson >> Neustar, Inc. >>=20 >> On 7/21/13 8:50 AM, "Hadriel Kaplan" wrote: >>=20 >>> >>> I've been thinking about your questions and it occurred to me we may be >>> talking past each other, or I'm not being clear enough. It's hard to >>> discuss some of this stuff in email, but anyway let me try a different >>> tack... >>> >>> So far, there is one relatively concrete proposal for how HTTP would be >>> used: RFC4474 or 4474bis, which use certs signed by someone, and >>> indicates where to get the cert in an HTTP URL encoded in the SIP >>>message >>> Identity-Info header. That model has a whole host of issues, and if by >>> "HTTP" you mean that model, then we could drill-down on the practical >>> problems I believe it would have. >>> >>> There is another way it could work using HTTP, which is essentially to >>> copy the CIDER proposal but replace the DNS query-answer with HTTP >>> query-answer. The verifier would generate its own HTTP URL to resolve, >>> based on the received identity information in SIP, and we'd define how >>>it >>> does that, what the cert model and encoding would be, how it gets >>>secured >>> redirection, how it times out cached copies, how to get the cert >>>signer's >>> cert, how to time that out, etc. Let's call such a model "HARD CIDER", >>> for "Http-based Access of Registry Data" or some such.[1] >>> >>> For a Hard Cider model to be used in a public Internet access model, >>>we'd >>> still be relying on DNS and DNSSEC, to perform resolution of the HTTP >>>URL >>> in a secure manner. And using a generated HTTP URL implies the >>>national >>> registries are deployed as a Google/Facebook/Amazon type cloudy >>> infrastructure with internal horizontal scaling technologies, etc. But >>> let's ignore that for now. >>> >>> The bigger problem is the target user environment: where we expect to >>>be >>> using this stuff, in carriers. In practice, HTTP isn't frequently used >>> by real-time call-handling network devices in most carriers. It is >>>used >>> by the carrier as a corporation of course, in various other >>> areas/groups/functions; and it's used in some call-control cases, >>>usually >>> by application servers providing features for specific users or calls, >>>in >>> specific scenarios. It's far less common to have it used for every >>>call, >>> and essentially never gets used by SBCs or X-CSCFs on an every-call >>> basis. There are a variety of practical reasons for that, but it >>>doesn't >>> really matter why. What matters is it would be a barrier to >>> deployability and adoption, in the real world, if we chose it. >>> >>> Arguably, DIAMETER is a far more common protocol for many carriers to >>>use >>> for this type of stuff than HTTP or even DNS. DIAMETER has its own >>> challenges in actual carrier deployments, mostly around scalability and >>> manageability, but we couldn't pick DIAMETER anyway because it's only >>> used in some carriers and not all carriers, and rarely used by anyone >>> else. >>> >>> As a protocol, DNS happens to be used by everyone - it's only used as >>> private ENUM by some carriers not all obviously, but virtually all of >>> them use DNS for at least hostname resolution, even internally. And >>>DNS >>> client implementation happens to be available in code in all systems, >>> whether it be SBCs or X-CSCFs or app servers or whatever; and its >>> performance, scalability and manageability characteristics happen to be >>> really good in actual carrier deployments. >>> >>> Having said all that, another way we could go in STIR is to just hedge >>> our bets and define multiple protocols: DNS, HTTP, and maybe even >>> DIAMETER. To do that, though, it still has to be deployable as DNS, >>> still have to be based on the verifier generating the URL and not have >>>it >>> sent by the originator, still have to specify the caching and clearing >>> behavior, still have to support both a centralized and distributed >>>model >>> of database deployment for numbers, etc. We've done that sort of >>>hedging >>> before in the IETF, rarely - it's a LOT more work, obviously, but it >>>lets >>> the market decide for itself what to do. >>> >>> If we do hedge our bets, however, I believe the most straight-forward >>>way >>> to actually do that would be to define the DNS one *first*, and then >>> figure out the HTTP or DIAMETER mechanics required for doing the same >>> things accessing stuff from a deployed DNS database infrastructure. >>> That's because DNS as a protocol already defines the semantics, >>> mechanics, and database structure; and if its used in a public Internet >>> access manner then it's The Public DNS. So a use of HTTP or DIAMETER >>> would need to access it and follow its behavior. And that has some >>> bizarre deployment expectations for all parties, for example for >>> international call scenarios, or for an email-style identity model. >>> >>> A more reasonable approach might be to define the DNS model, and then >>> only define how an HTTP or DIAMETER access to the local DNS resolver >>> could also work, where the verifier can only be a stub. That's still a >>> lot of work, and still involves localhost caching rules and such, but >>>at >>> least it constrains the problem somewhat. >>> >>> -hadriel >>> [1] I don't use the term "hard" to mean it will be hard, but rather >>> because "hard cider" happens to be a specific form of the drink known >>>as >>> cider. :) >>> >>> >>> On Jul 20, 2013, at 8:13 PM, Hadriel Kaplan >>> wrote: >>> >>>> >>>> On Jul 20, 2013, at 7:20 PM, Henning Schulzrinne >>>> wrote: >>>> >>>>> I don't see the "benefit" of DNS here. There are two cases, either >>>>>way: >>>>> >>>>> (1) A standard DNS hierarchy, with caching, but no synchronization. >>>>>In >>>>> that case, you need short TTLs if you care about revocation. With >>>>>short >>>>> TTLs, you get one country-level RTT for every query, even assuming no >>>>> packet loss. >>>> >>>> By "one country-level RTT for every query", do you mean you get one >>>>RTT >>>> on average for every call, and the RTT is likely not long on average >>>> because it's to a server in your geographic country? If so, sure that >>>> would likely be the case for public internet access queriers. One RTT >>>> on average, for a public Internet access model is pretty good, BTW. >>>> HTTP really won't have one RTT for such public Internet access, not in >>>> actual practice if this Identity-Info URL model is used. Again, this >>>>is >>>> not CIDER's raison d'etre, but just another plus. >>>> >>>> >>>>> (2) A locally-cached synchronized DNS hierarchy, using some kind of >>>>> rsync-like mechanism. >>>>> >>>>> You can get the same two versions for HTTP and certs. >>>> >>>> No, I really don't believe you can. You can get them if we give up on >>>> the Identity-Info URL thing, and define how HTTP would work without >>>>it, >>>> how the international call thing works, and so on. But not if the >>>>cert >>>> is served on some random server indicated by the Identity-Info header. >>>> >>>> >>>>> The locally-cached synchronized DNS has essentially the same overhead >>>>> as the locally-cached HTTP version, since the connection is nailed >>>>>down. >>>> >>>> Define "overhead". Overhead for whom? For the verifier systems HTTP >>>> is more overhead - a trivial amount if the stars align, and more if >>>> reality is included in the equation; but not a massive amount >>>> regardless. For the carriers, HTTP is more cost and operational >>>> overhead from a deployment perspective if reality is included, but >>>>again >>>> if we ignore practical realties then it's all equal. So sure, if all >>>> carriers in all nations deploy Google or Facebook style >>>>infrastructures >>>> and tweak their verifiers' TCP and HTTP implementations - all for the >>>> benefit of verifying a caller-id - then we're all good-to-go. ;) >>>> >>>> -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 >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >>=20 From stephen.farrell@cs.tcd.ie Wed Jul 24 15:49: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 CF12B11E811E for ; Wed, 24 Jul 2013 15:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 o7MJNRdDXUGR for ; Wed, 24 Jul 2013 15:49:17 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8E02111E811B for ; Wed, 24 Jul 2013 15:49:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9FB9ABE68; Wed, 24 Jul 2013 23:48:53 +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 F1+7jwF-FSrL; Wed, 24 Jul 2013 23:48:52 +0100 (IST) Received: from [10.87.48.4] (unknown [86.42.16.202]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9C566BE60; Wed, 24 Jul 2013 23:48:52 +0100 (IST) Message-ID: <51F059C7.4050509@cs.tcd.ie> Date: Wed, 24 Jul 2013 23:48:39 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Peterson, Jon" References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "stir@ietf.org Mail List" , Hadriel Kaplan , Henning Schulzrinne Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jul 2013 22:49:24 -0000 On 07/24/2013 11:35 PM, Peterson, Jon wrote: > This is kind of a worst-case > scenario for reaching consensus, though, because it's always hardest to > choose between things that are similar. Very good point. I guess that's why the wg chairs will get the big bucks;-) But yeah, that kind of thing has significant potential to disrupt a wg and figuring out how to handle the difficulty should maybe be very high priority for the wg. OTOH, sometimes what looks like it'll be hugely controversial turns out not to be, e.g. if folks who're very exercised on a topic don't actually turn up to do work in the wg. > That¹s why I believe a beauty > contest, or a food fight, would take a huge amount of effort, possibly > wasted effort given that market forces could find a place for either or > both. Possibly so. The counter argument is two ways to do one thing is a bad outcome. I think everyone involved in PKI still to this day regrets that we did that with CMP and CMC about 15 years ago. And as it happens, I'm just about to clear a DISCUSS on a draft (EST) that is arguably only needed because of that failure then. (In which I was as complicit as others as a co-author of rfc 2510.) Cheers, S. From hadriel.kaplan@oracle.com Wed Jul 24 22:23: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 8FDA521F85E0 for ; Wed, 24 Jul 2013 22:23:03 -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 Thd9PYsnqQgQ for ; Wed, 24 Jul 2013 22:22:57 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 00B5121F85D1 for ; Wed, 24 Jul 2013 22: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 r6P5MsLI010358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Jul 2013 05:22: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 r6P5Mqe8003684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jul 2013 05:22:53 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 r6P5MpdK006522; Thu, 25 Jul 2013 05:22:51 GMT Received: from [10.232.150.69] (/217.41.237.32) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Jul 2013 22:22:51 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <17414_1374680796_51EFF6DC_17414_333_1_B5939C6860701C49AA39C5DA5189448B0B5956@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Thu, 25 Jul 2013 01:22:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130712043221.11767.74779.idtracker@ietfa.amsl.com> <1F4B4D44-BD3E-4995-876A-147832C925F9@oracle.com> <19893_1374596593_51EEADF1_19893_9071_1_B5939C6860701C49AA39C5DA5189448B0B55A6@PEXCVZYM12.corporate.adroot.infra.ftgroup> <15BB6D07-F5D4-4945-80B9-0648CB32A6CA@oracle.com> <7699_1374659827_51EFA4F3_7699_4570_1_B5939C6860701C49AA39C5DA5189448B0B576C@PEXCVZYM12.corporate.adroot.infra.ftgroup> <4380BD56-E3E5-4CBD-B329-2D9964F91E01@oracle.com> <17414_1374680796_51EFF6DC_17414_333_1_B5939C6860701C49AA39C5DA5189448B0B5956@PEXCVZYM12.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "stir@ietf.org" Subject: Re: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jul 2013 05:23:03 -0000 On Jul 24, 2013, at 11:46 AM, wrote: > Right, but the "threat" for STIR is that someone receiving a = INVITE/IAM gets a calling party number that it uses for caller-id = display (or whatever) and the number is being maliciously = misrepresented. Obviously we don't know when it's being maliciously = misrepresented or just an honest mistake/error, and many INVITES/IAMs = won't be signed at all at least in the beginning, so we likely won't be = able to block such calls for a very long time if ever. Instead we'll = either anonymize the calling number (block number display), or check = with some other policy engine, or log it for later analysis, or send it = to an IVR, or whatever - it's a local policy decision really. >=20 > So assume you get a INVITE/IAM with a RFC 6567 UUI. It would be a = local policy decision what to do. You can decide that the destination = subscriber doesn't have a UUI service, for example a mobile/home phone = wouldn't, and thus treat it as an unsigned call and anonymize the = calling number or block it or whatever. Or you can decide that the SIP = Trunk to an Enterprise has such UUI "service", and pass the INVITE/IAM = on to it unchanged as you do today. The IP-PBX is then responsible for = deciding whether the INVITE/IAM with such a UUI is valid/allowed - for = example if it's from a branch office or whatever. That's what it has to = decide already today, and we don't seem to have a spoofed caller problem = for those cases today.=20 > The danger with letting a RFC 6567 UUI trump an IKES UUI is that = malicious sources could just start=20 > adding RFC 6567 UUIs to their INVITEs. We can easily detect and block = that for destinations that don't=20 > expect to get 6567 UUIs. = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^=20 >=20 > [PhF] I'm missing something here: how does an interconnect point = detect that a particular end site expect UUI or not? Suppose one of your = malicious source adds those RFC 6567 UUIs to get through, how would you = possibly know upstream whether it is legitimate or not, as you said it's = a local policy?=20 Sorry, I didn't mean the ingress point (SBC/IBCF) of a carrier could = block it - I just meant the carrier could block it somewhere, for = example in the S-CSCF that routes the call to the IP-PBX's trunk, or an = SBC connecting to the IP-PBX trunk, or whatever. > The hard part is how to block it for IP-PBXs that do expect 6567 UUIs. = =20 > [PhF] It seems to me that part of the problem is precisely that you = don't know which do and which don't. =20 As far as I know, the carriers know if a PBX-trunk/Enterprise-customer = has UUI support or not. For example it's in the service = contract/agreement with the Enterprise for SIP trunk service. Is that = not the case? (I could easily be wrong about that - it was just what I = heard) > If it becomes a problem, there are some potential solutions. One = solution is to only support 6567 UUI for inter-branch calls that stay = SIP along the whole path (since the IKES info is in a SIP header, it can = be used at the same time as 6567 UUI for SIP). That's not unreasonable, = because as far as I know such inter-branch calls typically only work = within the same carrier, or only within a small set of = fixed/known/pre-arranged set of carriers in a country. =20 > If that's true, then it's not unreasonable to expect the small set of = carriers to support SIP interconnect,=20 >=20 > [PhF] As an aside, even if they did support SIP interconnect, this = seems to assume that you don't have ISUP or some encapsulation of it in = parallel/addition to "full SIP".=20 Sorry I should have been clearer. I meant the IKES info is still in a = SIP header, even if there's an ISUP mime body in the SIP message. So = for SIP-SIP scenarios, you can leave the RFC 6567 UUI alone, while still = having IKES. IT should probably be clearer about that in the draft. -hadriel From hadriel.kaplan@oracle.com Thu Jul 25 05:01:59 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347B821F99E9 for ; Thu, 25 Jul 2013 05:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0vmMzHDfxMo for ; Thu, 25 Jul 2013 05:01:53 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 26FF521F9A15 for ; Thu, 25 Jul 2013 05:01:53 -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 r6PC1prS008066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Jul 2013 12:01:52 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6PC1mPB019961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jul 2013 12:01:50 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6PC1mwD019950; Thu, 25 Jul 2013 12:01:48 GMT Received: from [192.168.178.29] (/83.160.129.184) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 25 Jul 2013 05:01:48 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Thu, 25 Jul 2013 02:08:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <969CF0CD-3295-4147-8315-1A548B07EA44@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 List" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jul 2013 12:01:59 -0000 On Jul 23, 2013, at 9:26 PM, "Peterson, Jon" = wrote: > RFC4474 (/RFC4474bis) doesn't restrict access to certificates to HTTP > fetches. RFC4474 is pretty agnostic about how you get certs. We talked > about certs being included in SIP messages, so they'd arrive along = with > the signature. We talked about using SIP itself to fetch them, via > SUBSCRIBE. We considered cases where verifiers had access to caches, = or > even local cert stores. At the time we were doing RFC4474, HTTP seemed > like the right thing to hype for a number of reasons, so we encouraged = it. > But the URL in Identity-Info is just supposed to be a helpful = suggestion, > not the sole and authoritative means of access to certs. The concept of ignoring the URL is so broken, I'm still in mental denial = that 4474 says you can ignore it. Considering how carefully the IESG = reads my drafts for publication, I'm at a loss as to how they let 4474 = through. =20 > For the STIR > case, however, that hint might be useful to disambiguate for verifiers > which authority signed a SIP request, when there are multiple = authorities > for a single number (the function the CIDER "public key index value" = would > serve, if I understand correctly). How does the URL string "http://foo.com/dcjovbneoc.cer" help me figure = out which authority signed the request? I'd have to retrieve the cert = from that URL... and then I'd see some CA signed it, but how do I know = that CA is authoritative for that E.164 number? It's true that the purpose of the CIDER key index value is to let there = be multiple public keys in-use for the same E.164, but they're all = "signed" by the same "CA" - the only one truly authoritative for the = E.164 number. But more to-the-point, it provides a way for changing the = public keys while SIP messages are in-flight. Ultimately, no matter = what protocol we pick, if carriers have local database copies then it = will take some time for the public keys used to sign SIP messages to get = propagated out. So you need a way to change your key in-advance, still = use the old key for some period of time and then switch to using the new = one, and indicate on a per-SIP-message bases which of the keys you're = using. The same thing would have been true if RFC 4474 had ever seen the light = of day. So imagine if the sender was using = "http://foo.com/dcjovbneoc.cer" for some period of time, and then = changed to "http://foo.com/cebcuhlked.cer". How would this work, if a = verifier ignores this URL because 4474 said it was ok? I guess I do agree with one thing you said a while back: we do indeed = have to deprecate RFC 4474. Not because we'll define something better, = but because it's broken. -hadriel From hadriel.kaplan@oracle.com Thu Jul 25 05:04: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 5D43421F9AC1 for ; Thu, 25 Jul 2013 05:04:56 -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.015, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 vgZcNeZ3cbck for ; Thu, 25 Jul 2013 05:04:49 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF6721F9A96 for ; Thu, 25 Jul 2013 05:04:49 -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 r6PC4l6K006340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Jul 2013 12:04:48 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 r6PC4l43008277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jul 2013 12:04:47 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6PC4kjf008271; Thu, 25 Jul 2013 12:04:47 GMT Received: from hadriel-macbook-2.fritz.box (/83.160.129.184) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 25 Jul 2013 05:04: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: Date: Thu, 25 Jul 2013 03:59:05 -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 List" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jul 2013 12:04:56 -0000 On Jul 23, 2013, at 9:26 PM, "Peterson, Jon" = wrote: > Part of the reason I think we're all talking past each other here is = that > certs are relatively self-contained documents, and you could get them = in a > number of ways, and I don't think there's any pressing need for us to > restrict those ways. Part of the problem is in fact that they are "self-contained documents". = Having certs floating around in various places with no rules other than = they age out in a year or two is what raises the concern around = revocations. For example, the fact that 4474 lets the sender of the SIP = message tell people where to get a cert, is the reason we would have the = need for revocations and highly-scalable CRLs. > For DNS proposals (if they don't just stick CA certs > in the DNS), on the other hand, the way you get a credential is > inextricably coupled to the semantics of the credential itself, which = is > why the CIDER proposal isn't just a protocol, it's a whole deployment > architecture. The credentials lose any semantics if they are divorced = from > the deployment environment you're supposed to fetch them from. All > credentials must be uploaded through that central service and all > credentials must be downloaded from its (distributed) deployment. Well... that's not actually true, but yes I would expect it to be = effectively true in practice. I mean you can, for example, have = multiple anchors and multiple DNS admins for a country-code; but it = wouldn't make much sense in my opinion. Or you could, for example, = split a country-code tree among multiple DNS administrations of the = database. But again I don't know why you'd want to. > There doesn't need to be a "national authority" cloud service that = manages > access to certs in this way. There needs to be one or more databases somewhere to get the certs. = We've already agreed (I think?) that we don't want to identify what = carriers own what numbers publicly. Ergo, someone other than the = carriers has to provide a database to get certs - even if it's just a = master copy that's copied into local copies in carriers. > The reason you trust a cert isn't because you > downloaded it from the right place, it's because you trust the trust > anchor that signed the cert. Technically DNSSEC doesn't require the answer to come from "the right = place". There can be caches and resolvers all over the place; you can = even replicate entire trees in random locations, without being = authoritative for them. So long as the signature chain is valid, it's = good. In that sense it's quite similar to certs. > This isn't about HTTP - it doesn't matter if > you found the cert lying on the ground. Simply trusting a CA because it's a "CA" is how we got to DigiNotar. To = avoid that, even if we use certs and HTTP, we'll have to have some way = of scoping the CA's authority, and letting that scope change over time. = The verifiers need to know which CAs are authoritative for which = country-codes, and even within country-codes they need to know which = region prefix CAs are authoritative. For example which area-codes are = under which of the +1 NANP member country admin CAs, including as new = area-codes are added; and as country-codes are added or changed. = Obviously we can accomplish all that using HTTP, by defining how that = would work, defining some encoding/list thingy, where such a list is = retrieved from, how often you check for changes, etc. Using a DNS = structure happens to let all that be done automatically. Automation is = *good*. I know it's boring to not get to define a lot more new things, but I'm = sure we can find something else to do. ;) > This is why I don't understand the > need for "hard cider," or indeed why it would be important for a > verification service to be able to derive a single canonical location = from > which it will download a cert by studying the originating number = alone. The verifier doesn't derive a "single canonical location" from which it = will download the cert. It derives a single canonical query key - in = DNS it's a DNS query key, but for HTTP it could be the URL's path = portion (not hostname). The physical "location" (ie, the server) it = retrieves it from is a local policy administrative decision, but the = query key it uses is consistent no matter what carrier/location it's in. For example, a potential Hard CIDER model would be such that when you = receive a call from +1-603-555-1234 with a key index of 99, you create a = URL like this: http://mylocalserver.mydomain.com/cid/16035551234/99.cer The "mylocalserver.mydomain.com" would be replaced with whatever your = local Hard CIDER server's hostname is, or even 192.168.1.2. Why? So that we actually get some interoperability between verifier = clients and cert-serving servers. So that we can then describe how the = local server might actually know what cert to give back to the client, = how it got the cert, how its local database of certs is synchronized = with a master DB, how we're going to handle international numbers, etc. = You know... specify an actual solution, not just magic pixie dust. > I > kind of see why this is important for a DNS-based solution (though the > harm DNS URI Identity-Info would do there isn't clear to me - if it = points > to something you don't trust, don't trust it), but not for a = cert-based > solution. If you could, for example, just receive the cert in-band = with > the request, that would seem to obviate the need to go ask anyone for = it. That would have the same problem as a HTTP URL in Identity-Info. = Letting the sender of the SIP message tell people where to get a cert = (or directly giving it to them as an attachment), is the reason we would = have the need for revocations and highly-scalable CRLs. Besides, we = can't send the cert in-band. Doubling the SIP message size and relying = on multi-part MIME to work end-to-end is not a way to get this stuff = deployed. -hadriel From hadriel.kaplan@oracle.com Thu Jul 25 05:04: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 9504521F9A96 for ; Thu, 25 Jul 2013 05:04:57 -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.014, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 myElUl5adEyL for ; Thu, 25 Jul 2013 05:04:51 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0E37D21F9ABB for ; Thu, 25 Jul 2013 05:04: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 r6PC4oxQ010851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Jul 2013 12:04:50 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 r6PC4mKK025792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jul 2013 12:04:49 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6PC4me5008303; Thu, 25 Jul 2013 12:04:48 GMT Received: from hadriel-macbook-2.fritz.box (/83.160.129.184) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 25 Jul 2013 05:04:48 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Thu, 25 Jul 2013 04:29:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <78BAA1BD-C066-4857-8563-C84785D055F4@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 List" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jul 2013 12:04:57 -0000 On Jul 24, 2013, at 6:35 PM, "Peterson, Jon" = wrote: >=20 > Understood that there are trade-offs in maintaining cert freshness, = just > as there are trade-offs in maintaining the freshness of DNS records > (caching, TTLs, etc.) I don't mean to suggest that there's no need for = a > function like OCSP, nor that if you had to do OCSP, this wouldn't have > similar properties to making a DNS query. I guess that when you try to > engineer either approach to the same operational requirements, in = terms of > how fresh credentials must be and how often you check them, they're = going > to end up with some very similar properties. This is kind of a = worst-case > scenario for reaching consensus, though, because it's always hardest = to > choose between things that are similar. They're not similar. At least not so far, as written. RFC 4474 (or = 4474bis for that matter) and CIDER are dramatically different, with very = different properties and behaviors. Trying to paint them as "similar" is a clever gambit, though.=20 > imagine a Carrier A wants to have a single credential that can sign = for > all their numbers (and say Carrier A isn't worried about what = verifiers > could analyze from that). Imagine they control many large = discontinuous > blocks of numbers. We could build a DNS service that synthesizes = responses > and returns to verifiers the same public key for all the numbers that > Carrier A is authoritative for. The caching properties of that = approach, > though, could be very different than having a single public cert that = has > that entire number range under its authority. Now imagine that instead = of > just one such credential, Carrier A may want five, or fifteen, or = fifty, > all with the same authority, that it wants to put into different = signing > systems in different parts of their network. =46rom my experience = dealing > with the back office of telephone number authority services, I'd say = these > are quite plausible requirements. As discussed previously, if a carrier doesn't care whether folks can = figure out what numbers it owns, and it has actual "blocks" of numbers, = then we can make CIDER have a way to optimize such cases: for example, = not only by storing it as a pointer, but also indicating it as such in = the TXT RR, so that the verifier could know to go look for a key in a = root-branch and cache it for the whole branch of nodes; or another = alternative is not "synthesizing" node responses, but only responding = with the root-branch one. Those types of things are the details we'll = have to get into, no doubt. Open numbering plan issues too, fwiw. -hadriel From stephen.farrell@cs.tcd.ie Thu Jul 25 05:12: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 39DF221F9AD1 for ; Thu, 25 Jul 2013 05:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5VHSqmv3+Iu for ; Thu, 25 Jul 2013 05:12:25 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5E67B21F9AD2 for ; Thu, 25 Jul 2013 05:12:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B03F8BE60; Thu, 25 Jul 2013 13:11:53 +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 b-zDmZrZeOrv; Thu, 25 Jul 2013 13:11:52 +0100 (IST) Received: from [10.37.97.245] (unknown [95.83.248.160]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F410FBE5F; Thu, 25 Jul 2013 13:11:51 +0100 (IST) References: <78BAA1BD-C066-4857-8563-C84785D055F4@oracle.com> Mime-Version: 1.0 (1.0) In-Reply-To: <78BAA1BD-C066-4857-8563-C84785D055F4@oracle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B329) From: Stephen Farrell Date: Thu, 25 Jul 2013 13:11:41 +0100 To: Hadriel Kaplan Cc: "stir@ietf.org List" , "Peterson, Jon" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jul 2013 12:12:30 -0000 On 25 Jul 2013, at 09:29, Hadriel Kaplan wrote: >=20 > On Jul 24, 2013, at 6:35 PM, "Peterson, Jon" wr= ote: >=20 >>=20 >> Understood that there are trade-offs in maintaining cert freshness, just >> as there are trade-offs in maintaining the freshness of DNS records >> (caching, TTLs, etc.) I don't mean to suggest that there's no need for a >> function like OCSP, nor that if you had to do OCSP, this wouldn't have >> similar properties to making a DNS query. I guess that when you try to >> engineer either approach to the same operational requirements, in terms o= f >> how fresh credentials must be and how often you check them, they're going= >> to end up with some very similar properties. This is kind of a worst-case= >> scenario for reaching consensus, though, because it's always hardest to >> choose between things that are similar. >=20 > They're not similar. At least not so far, as written. RFC 4474 (or 4474b= is for that matter) and CIDER are dramatically different, with very differen= t properties and behaviors. >=20 > Trying to paint them as "similar" is a clever gambit, though.=20 I'm not sure that's fair since they are solving the same problem and are rou= ghly similar in terms of levels of imperfection, so I think Jon's point hold= s S >=20 >=20 >=20 >> imagine a Carrier A wants to have a single credential that can sign for >> all their numbers (and say Carrier A isn't worried about what verifiers >> could analyze from that). Imagine they control many large discontinuous >> blocks of numbers. We could build a DNS service that synthesizes response= s >> and returns to verifiers the same public key for all the numbers that >> Carrier A is authoritative for. The caching properties of that approach, >> though, could be very different than having a single public cert that has= >> that entire number range under its authority. Now imagine that instead of= >> just one such credential, Carrier A may want five, or fifteen, or fifty, >> all with the same authority, that it wants to put into different signing >> systems in different parts of their network. =46rom my experience dealing= >> with the back office of telephone number authority services, I'd say thes= e >> are quite plausible requirements. >=20 > As discussed previously, if a carrier doesn't care whether folks can figur= e out what numbers it owns, and it has actual "blocks" of numbers, then we c= an make CIDER have a way to optimize such cases: for example, not only by st= oring it as a pointer, but also indicating it as such in the TXT RR, so that= the verifier could know to go look for a key in a root-branch and cache it f= or the whole branch of nodes; or another alternative is not "synthesizing" n= ode responses, but only responding with the root-branch one. Those types of= things are the details we'll have to get into, no doubt. Open numbering pl= an issues too, fwiw. >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From michael.hammer@yaanatech.com Thu Jul 25 05:58: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 B3A8E21F90AC for ; Thu, 25 Jul 2013 05:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 NtugT4baE-Cp for ; Thu, 25 Jul 2013 05:57: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 C74E621F8EDF for ; Thu, 25 Jul 2013 05:57: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; Thu, 25 Jul 2013 05:57:54 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" , "jon.peterson@neustar.biz" Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) - attack model Thread-Index: AQHOhQaUpWBouCrQPUqwnzpS8YN+fJlumFIAgAAQQQCAAAISgIAADtuAgAEFx4CAA8W3gIAB4TCA///6uJA= Date: Thu, 25 Jul 2013 12:57:53 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC1D669@EX2K10MB1.corp.yaanatech.com> References: <969CF0CD-3295-4147-8315-1A548B07EA44@oracle.com> In-Reply-To: <969CF0CD-3295-4147-8315-1A548B07EA44@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.88] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0008_01CE8915.0BA87130" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jul 2013 12:58:00 -0000 ------=_NextPart_000_0008_01CE8915.0BA87130 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Please stop making silly statements like this. Somehow we know that the multiple CIDER CAs are good, but somehow we can't know that a cert CA is good. Also, that a CIDER transaction can happen in real-time, but a non-CIDER transaction could not happen in real time. As I pointed out before, if the private/public key pair of the number holder is compromised, there is no difference in how you regenerate the pair and get the private key into the hands of the signer. There is no difference in the time it takes to send the private key or the cert to that user. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Thursday, July 25, 2013 2:09 AM To: Peterson, Jon Cc: stir@ietf.org List Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model On Jul 23, 2013, at 9:26 PM, "Peterson, Jon" wrote: > RFC4474 (/RFC4474bis) doesn't restrict access to certificates to HTTP > fetches. RFC4474 is pretty agnostic about how you get certs. We talked > about certs being included in SIP messages, so they'd arrive along > with the signature. We talked about using SIP itself to fetch them, > via SUBSCRIBE. We considered cases where verifiers had access to > caches, or even local cert stores. At the time we were doing RFC4474, > HTTP seemed like the right thing to hype for a number of reasons, so we > encouraged it. > But the URL in Identity-Info is just supposed to be a helpful > suggestion, not the sole and authoritative means of access to certs. The concept of ignoring the URL is so broken, I'm still in mental denial that 4474 says you can ignore it. Considering how carefully the IESG reads my drafts for publication, I'm at a loss as to how they let 4474 through. > For the STIR > case, however, that hint might be useful to disambiguate for verifiers > which authority signed a SIP request, when there are multiple > authorities for a single number (the function the CIDER "public key > index value" would serve, if I understand correctly). How does the URL string "http://foo.com/dcjovbneoc.cer" help me figure out which authority signed the request? I'd have to retrieve the cert from that URL... and then I'd see some CA signed it, but how do I know that CA is authoritative for that E.164 number? It's true that the purpose of the CIDER key index value is to let there be multiple public keys in-use for the same E.164, but they're all "signed" by the same "CA" - the only one truly authoritative for the E.164 number. But more to-the-point, it provides a way for changing the public keys while SIP messages are in-flight. Ultimately, no matter what protocol we pick, if carriers have local database copies then it will take some time for the public keys used to sign SIP messages to get propagated out. So you need a way to change your key in-advance, still use the old key for some period of time and then switch to using the new one, and indicate on a per-SIP-message bases which of the keys you're using. The same thing would have been true if RFC 4474 had ever seen the light of day. So imagine if the sender was using "http://foo.com/dcjovbneoc.cer" for some period of time, and then changed to "http://foo.com/cebcuhlked.cer". How would this work, if a verifier ignores this URL because 4474 said it was ok? I guess I do agree with one thing you said a while back: we do indeed have to deprecate RFC 4474. Not because we'll define something better, but because it's broken. -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_0008_01CE8915.0BA87130 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcy NTEyNTc1MlowIwYJKoZIhvcNAQkEMRYEFNPuIOwQZ7245p1RvEd9wIvHNYofMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAHW46qBcwpg2qMG4HkslXmOmN4TO7D5Ob3jEWMdgv yWiMRHWkH8uD7mD4gvap8D1JlDQV1saPdMmBRpBO7Nb7e159rNvwvJcUGy8fyTT8E2sw1H6BnhHh zRlY+lqh7B6nT0gzQ+kLFYyzz1dYzY/sVQrmLy+0zuIcFA/+Sxe8P8XUzavFb6+u3nhI0gfPeMRf 0ztsxg4gzXcbwing/1OviW7aG7d+U6ShY0pqGgxLOGexpsG7Z2u5SK4/1K7HBI0zHbTSyjbKO7qz Rsx18Pvr7DD5nbtWq7MGx/RtnAdO+9RTuSoxeVvuqKYoHzvUR7/EPyzxjJjx4gMFqNsjXyuoZAAA AAAAAA== ------=_NextPart_000_0008_01CE8915.0BA87130-- From dhc@dcrocker.net Thu Jul 25 07:47: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 04A3821F9406 for ; Thu, 25 Jul 2013 07:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BjytduDL0Cm for ; Thu, 25 Jul 2013 07:47:50 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 14C0321F938E for ; Thu, 25 Jul 2013 07:47:50 -0700 (PDT) Received: from [192.168.174.86] ([192.173.4.185]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r6PElhuH025630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 25 Jul 2013 07:47:48 -0700 Message-ID: <51F13A8D.8070006@dcrocker.net> Date: Thu, 25 Jul 2013 15:47:41 +0100 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Brian Rosen References: <00C069FD01E0324C9FFCADF539701DB3BBC1A683@EX2K10MB1.corp.yaanatech.com> <6EF50BDB-3F41-49FE-83C1-20216D0D0BF0@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1BE03@EX2K10MB1.corp.yaanatech.com> <0073993E-1BC8-461C-9A7E-B5DCFC617DBF@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1C956@EX2K10MB1.corp.yaanatech.com> <011401ce87f2$75e5e880$61b1b980$@shockey.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 25 Jul 2013 07:47:48 -0700 (PDT) Cc: stir@ietf.org Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) 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, 25 Jul 2013 14:47:55 -0000 On 7/24/2013 1:47 PM, Brian Rosen wrote: > At some point, those same protocols could be extended to endpoints. I don't see that happening real soon perhaps, but I think it will happen. It sounds as if there's a design goal disconnect here. The very general range of actors for the basic, SIP-based STIR environment that has been described on the list is roughly: user-enterprise-+ +--user | | +--provider...provider--+ | | user-+ +--enterprise-user The architectural model that you are describing for this round of effort is: { Provider STIR } +=====================+ / / user-enterprise-+ / STIR / +--user | / / | +--/-provider...provider-/--+ | / / | user-+ / / +--enterprise-user / / +=====================+ Inside the STIR box are signers and verifiers. By saying "at some point... extended to endpoints", you are almost certainly calling for defining an /additional/ technical mechanism, to accomplish the extension. More mechanism means more complexity and typically means component linkages that produce results which are not transparent. (In other words, rough edges through the extension.) The alternative is to have an architecture that immediately /permits/ the extended participation, but probably will have more limited deployment as an /operational/ choice, rather than a technical limitation. Hence: { End-to-End STIR } +============================================================+ / STIR / / user-enterprise-+ +--user / / | | / / +--provider...provider--+ / / | | / / user-+ +--enterprise-user / / / +============================================================+ Again, inside the STIR box are signers and verifiers. An effort to extend the operation will, in this case, be only that -- extended operation -- and won't involve defining or deploying new technology. To the extent that someone claims that a post-hoc extension for the Provider STIR approach does not involve new technology -- new specification, new development, and new deployment -- please offer examples of this being done successfully. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From philippe.fouquart@orange.com Thu Jul 25 08:48:39 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2340721F8423 for ; Thu, 25 Jul 2013 08:48:39 -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 wpDropO5ZP47 for ; Thu, 25 Jul 2013 08:48:34 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id C42FA21F8456 for ; Thu, 25 Jul 2013 08:48:33 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id E3CD022D13C; Thu, 25 Jul 2013 17:48:32 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id C3FB327C06F; Thu, 25 Jul 2013 17:48:32 +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, 25 Jul 2013 17:48:32 +0200 From: To: Hadriel Kaplan Thread-Topic: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt Thread-Index: AQHOfrnJIrVpZ/tZPUKeljXpre8LSZlychJwgABBJQCAANhWAIAAMFyAgAAkSPCAAO7UAIAAz3/Q Date: Thu, 25 Jul 2013 15:48:31 +0000 Message-ID: <28459_1374767312_51F148D0_28459_2743_1_B5939C6860701C49AA39C5DA5189448B0B5B5B@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <20130712043221.11767.74779.idtracker@ietfa.amsl.com> <1F4B4D44-BD3E-4995-876A-147832C925F9@oracle.com> <19893_1374596593_51EEADF1_19893_9071_1_B5939C6860701C49AA39C5DA5189448B0B55A6@PEXCVZYM12.corporate.adroot.infra.ftgroup> <15BB6D07-F5D4-4945-80B9-0648CB32A6CA@oracle.com> <7699_1374659827_51EFA4F3_7699_4570_1_B5939C6860701C49AA39C5DA5189448B0B576C@PEXCVZYM12.corporate.adroot.infra.ftgroup> <4380BD56-E3E5-4CBD-B329-2D9964F91E01@oracle.com> <17414_1374680796_51EFF6DC_17414_333_1_B5939C6860701C49AA39C5DA5189448B0B5956@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.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.25.150624 Cc: "stir@ietf.org" Subject: Re: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jul 2013 15:48:39 -0000 Thanks. More in-line... Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com]=20 Sent: Thursday, July 25, 2013 7:23 AM To: FOUQUART Philippe OLNC/OLN Cc: stir@ietf.org Subject: Re: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt On Jul 24, 2013, at 11:46 AM, wrote: > [PhF] I'm missing something here: how does an interconnect point detect t= hat a particular end site expect UUI or not? Suppose one of your malicious = source adds those RFC 6567 UUIs to get through, how would you possibly know= upstream whether it is legitimate or not, as you said it's a local policy?= =20 Sorry, I didn't mean the ingress point (SBC/IBCF) of a carrier could block = it - I just meant the carrier could block it somewhere, for example in the = S-CSCF that routes the call to the IP-PBX's trunk, or an SBC connecting to = the IP-PBX trunk, or whatever.=20 [PhF] OK, thanks. The difference then is that the call server would then k= now whether UUI is supported to/from a particular site, it doesn't mean tha= t UUI 'must' or 'must not' be present for a particular message. (see next)= =20 > The hard part is how to block it for IP-PBXs that do expect 6567 UUIs.=20= =20 > [PhF] It seems to me that part of the problem is precisely that you don't= know which do and which don't.=20=20 As far as I know, the carriers know if a PBX-trunk/Enterprise-customer has = UUI support or not. For example it's in the service contract/agreement wit= h the Enterprise for SIP trunk service. Is that not the case? (I could eas= ily be wrong about that - it was just what I heard) [PhF] It is. I don't know if it's the general situation for all such contra= cts but indeed for the baseline offer I'm familiar with, UUI is actually al= ways included by default, but the endpoint may or may not use it, or may us= e it only occasionally, so at a given point in time, how would the network = know whether to expect UUI to/from that site?=20 -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 Thu Jul 25 09: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 7BD1821F967C for ; Thu, 25 Jul 2013 09:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.046 X-Spam-Level: X-Spam-Status: No, score=-99.046 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_QP_LONG_LINE=1.396, 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 Samir9-0Uazv for ; Thu, 25 Jul 2013 09:29:13 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id B1D5621F9948 for ; Thu, 25 Jul 2013 09:28: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=tPCoeb5vmAUhfrKlQ2y2x/H0EPj4bGWtE7oZgO+WbYo=; b=WMd0zMpnWQYBBWSf5qe7VlupnMLQTB8pft4iJpNQuehw76B15FAdTNgazKya4G0r6KW1J27hV/cwGCnms2NChT3Smvo5RBfmRUMopJm3e45NjZ/Q2oSS9GrFR7VoTxERTcJ8gnvTC903pY24kyayAz0DqZLwV5yBNFgG+kC774U=; Received: from neustargw.va.neustar.com ([209.173.53.233]:48571 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1V2OPI-0005wb-J8; Thu, 25 Jul 2013 12:28:48 -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: <51F13A8D.8070006@dcrocker.net> Date: Thu, 25 Jul 2013 12:28:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <98DE5818-FD12-49C4-A7E5-A92B18515F03@brianrosen.net> References: <00C069FD01E0324C9FFCADF539701DB3BBC1A683@EX2K10MB1.corp.yaanatech.com> <6EF50BDB-3F41-49FE-83C1-20216D0D0BF0@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1BE03@EX2K10MB1.corp.yaanatech.com> <0073993E-1BC8-461C-9A7E-B5DCFC617DBF@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1C956@EX2K10MB1.corp.yaanatech.com> <011401ce87f2$75e5e880$61b1b980$@shockey.us> <51F13A8D.8070006@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 Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 16:29:18 -0000 I can't follow you, sorry. I think initially service providers will sign and verify on behalf of = their subscribers, but as time goes on the subscriber device will sign = and/or verify. I don't think the protocols change, but if devices have to get = credentials that may be different from service providers (only) needing = to be able to get credentials. I do think that a provisioning protocol needs to be decided upon, and = that may be selecting from existing services that download the = credential into the signer. That might, at first, be how the = centralized credential services interact with service providers. It = eventually needs to be how service providers interact with PBXs, and = further how PBXs and/or service providers interact with devices. The = process is the same, when we assign a number, or range of numbers, we = "download" credentials, where "download" really is more complex in that = it involves how the private key ends up on the signer. Brian On Jul 25, 2013, at 10:47 AM, Dave Crocker wrote: > On 7/24/2013 1:47 PM, Brian Rosen wrote: >> At some point, those same protocols could be extended to endpoints. = I don't see that happening real soon perhaps, but I think it will = happen. >=20 >=20 > It sounds as if there's a design goal disconnect here. >=20 > The very general range of actors for the basic, SIP-based STIR = environment that has been described on the list is roughly: >=20 >=20 > user-enterprise-+ +--user > | | > +--provider...provider--+ > | | > user-+ +--enterprise-user >=20 >=20 > The architectural model that you are describing for this round of = effort is: >=20 >=20 > { Provider STIR } >=20 > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D+ > / / > user-enterprise-+ / STIR / +--user > | / / | > +--/-provider...provider-/--+ > | / / | > user-+ / / +--enterprise-user > / / > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D+ >=20 >=20 > Inside the STIR box are signers and verifiers. >=20 > By saying "at some point... extended to endpoints", you are almost = certainly calling for defining an /additional/ technical mechanism, to = accomplish the extension. More mechanism means more complexity and = typically means component linkages that produce results which are not = transparent. (In other words, rough edges through the extension.) >=20 >=20 > The alternative is to have an architecture that immediately /permits/ = the extended participation, but probably will have more limited = deployment as an /operational/ choice, rather than a technical = limitation. >=20 > Hence: >=20 > { End-to-End STIR } >=20 > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > / STIR / > / user-enterprise-+ +--user / > / | | / > / +--provider...provider--+ / > / | | / > / user-+ +--enterprise-user / > / / > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >=20 > Again, inside the STIR box are signers and verifiers. >=20 > An effort to extend the operation will, in this case, be only that -- = extended operation -- and won't involve defining or deploying new = technology. >=20 > To the extent that someone claims that a post-hoc extension for the = Provider STIR approach does not involve new technology -- new = specification, new development, and new deployment -- please offer = examples of this being done successfully. >=20 > d/ > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net From timothy.dwight@verizon.com Thu Jul 25 10:14: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 6882521F8DDD for ; Thu, 25 Jul 2013 10:14:54 -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 kfWHNok83kFl for ; Thu, 25 Jul 2013 10:14:49 -0700 (PDT) Received: from omzsmtpe01.verizonbusiness.com (omzsmtpe01.verizonbusiness.com [199.249.25.210]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA6421F8DA3 for ; Thu, 25 Jul 2013 10:14:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by omzsmtpe01.verizonbusiness.com with ESMTP; 25 Jul 2013 17:14:47 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.89,744,1367971200"; d="scan'208";a="514555187" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi02.verizon.com with ESMTP; 25 Jul 2013 17:14:47 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Thu, 25 Jul 2013 13:14:47 -0400 To: Brian Rosen , "dcrocker@bbiw.net" Date: Thu, 25 Jul 2013 13:14:45 -0400 Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) Thread-Index: Ac6JVB/7+E+qgqicQkyd85sGsccoZQAAjsPg Message-ID: <2B0F677F0B95454297753F58D4A07FA30129632F71@FHDP1LUMXC7V31.us.one.verizon.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC1A683@EX2K10MB1.corp.yaanatech.com> <6EF50BDB-3F41-49FE-83C1-20216D0D0BF0@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1BE03@EX2K10MB1.corp.yaanatech.com> <0073993E-1BC8-461C-9A7E-B5DCFC617DBF@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1C956@EX2K10MB1.corp.yaanatech.com> <011401ce87f2$75e5e880$61b1b980$@shockey.us> <51F13A8D.8070006@dcrocker.net> <98DE5818-FD12-49C4-A7E5-A92B18515F03@brianrosen.net> In-Reply-To: <98DE5818-FD12-49C4-A7E5-A92B18515F03@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 17:14:54 -0000 The scenario Brian describes seems likely to me, though the *very* first de= ployments might be by non-SP companies with some particular interest in the= issue (e.g., banks, who don't want their phone numbers spoofed as part of = some scam, or organizations that are frequently the victim of spoofing -rel= ated pranks, such as law enforcement agencies). I have 2 related questions. 1) If an SP "signs on behalf of its subscribers", what are they expected to= sign? FROM, P-A-ID, both, FROM but only if no P-A-ID is present or assign= able, something else? Should the SP behavior be different if the user has = already signed the contents of the FROM header? 2) I understand that "prevention of fraudulent caller ID spoofing" is an ob= jective. Are we also trying to facilitate "benign" spoofing? =20 The reason for question #2 is that a "reasonable interpretation" of 3GPP's = OIP/OIR specification (TS 24.607) is that the called UE display to the user= the "network asserted identity" of the calling party (P-A-ID) if available= . It doesn't explicitly say that, but it says enough negative things about= use of the FROM header that that's at least a reasonable interpretation. = So I'm worried about the "benign spoofing" case where the FROM header has a= valid signature but yet the called party never sees the number the caller = intended, because his device gave preference to the contents of P-A-ID. Tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Bri= an Rosen Sent: Thursday, July 25, 2013 11:29 AM To: dcrocker@bbiw.net Cc: stir@ietf.org Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) I can't follow you, sorry. I think initially service providers will sign and verify on behalf of their= subscribers, but as time goes on the subscriber device will sign and/or ve= rify. I don't think the protocols change, but if devices have to get credentials = that may be different from service providers (only) needing to be able to g= et credentials. I do think that a provisioning protocol needs to be decided upon, and that = may be selecting from existing services that download the credential into t= he signer. That might, at first, be how the centralized credential service= s interact with service providers. It eventually needs to be how service p= roviders interact with PBXs, and further how PBXs and/or service providers = interact with devices. The process is the same, when we assign a number, o= r range of numbers, we "download" credentials, where "download" really is m= ore complex in that it involves how the private key ends up on the signer. Brian On Jul 25, 2013, at 10:47 AM, Dave Crocker wrote: > On 7/24/2013 1:47 PM, Brian Rosen wrote: >> At some point, those same protocols could be extended to endpoints. I d= on't see that happening real soon perhaps, but I think it will happen. >=20 >=20 > It sounds as if there's a design goal disconnect here. >=20 > The very general range of actors for the basic, SIP-based STIR environmen= t that has been described on the list is roughly: >=20 >=20 > user-enterprise-+ +--user > | | > +--provider...provider--+ > | | > user-+ +--enterprise-user >=20 >=20 > The architectural model that you are describing for this round of effort = is: >=20 >=20 > { Provider STIR } >=20 > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D+ > / / > user-enterprise-+ / STIR / +--user > | / / | > +--/-provider...provider-/--+ > | / / | > user-+ / / +--enterprise-user > / / > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D+ >=20 >=20 > Inside the STIR box are signers and verifiers. >=20 > By saying "at some point... extended to endpoints", you are almost certai= nly calling for defining an /additional/ technical mechanism, to accomplish= the extension. More mechanism means more complexity and typically means c= omponent linkages that produce results which are not transparent. (In othe= r words, rough edges through the extension.) >=20 >=20 > The alternative is to have an architecture that immediately /permits/ the= extended participation, but probably will have more limited deployment as = an /operational/ choice, rather than a technical limitation. >=20 > Hence: >=20 > { End-to-End STIR } >=20 > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > / STIR / > / user-enterprise-+ +--user / > / | | / > / +--provider...provider--+ / > / | | / > / user-+ +--enterprise-user / > / / > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >=20 > Again, inside the STIR box are signers and verifiers. >=20 > An effort to extend the operation will, in this case, be only that -- ext= ended operation -- and won't involve defining or deploying new technology. >=20 > To the extent that someone claims that a post-hoc extension for the Provi= der STIR approach does not involve new technology -- new specification, new= development, and new deployment -- please offer examples of this being don= e successfully. >=20 > d/ > --=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 Thu Jul 25 10:24: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 473E321F843F for ; Thu, 25 Jul 2013 10:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 8Cr5SjLnYsEo for ; Thu, 25 Jul 2013 10:24: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 5828C21F995F for ; Thu, 25 Jul 2013 10:23:58 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Thu, 25 Jul 2013 10:23:56 -0700 From: Michael Hammer To: "br@brianrosen.net" , "dcrocker@bbiw.net" Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) Thread-Index: AQHOgvzGoW2Sqvrxc0GEvdoogk5ro5lpa5QAgAAoCgCAAe3VAIAAA5sAgAEbyACAABl1gP//jBDQgACJywD//6q3gIAA/xKAgANB3HCAALyhgP//tYrwADfEMAAADkF6MP//woOAgABwijD//7gqAIAACu6AgADzGICAAbPSgIAAHDaAgABpnKA= Date: Thu, 25 Jul 2013 17:23:55 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC1DC78@EX2K10MB1.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC1A683@EX2K10MB1.corp.yaanatech.com> <6EF50BDB-3F41-49FE-83C1-20216D0D0BF0@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1BE03@EX2K10MB1.corp.yaanatech.com> <0073993E-1BC8-461C-9A7E-B5DCFC617DBF@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1C956@EX2K10MB1.corp.yaanatech.com> <011401ce87f2$75e5e880$61b1b980$@shockey.us> <51F13A8D.8070006@dcrocker.net> <98DE5818-FD12-49C4-A7E5-A92B18515F03@brianrosen.net> In-Reply-To: <98DE5818-FD12-49C4-A7E5-A92B18515F03@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.88] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0560_01CE893A.3637AD10" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 17:24:15 -0000 ------=_NextPart_000_0560_01CE893A.3637AD10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am wondering if this could be a proxied protocol based on HTTP. (Could even be SIP or IMS) that requires the path to go backwards through the number delegation chain, but which operates E2E between the end-user and the signing authority to securely deliver the private key/credentials. Each SP could validate each proxy hop, just as they would for IMS today. (Of course, this relies on the link-level security to know how you know who you receive the request from.) For example, end-user creates a one-time encryption key and encrypts that with public key of signing authority. Signing authority uses that symmetric secret key to encrypt the private key going back to the end-user. The proxy chain could start with end-user, PBX, or SP depending on deployment scenario. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Thursday, July 25, 2013 12:29 PM To: dcrocker@bbiw.net Cc: stir@ietf.org Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) I can't follow you, sorry. I think initially service providers will sign and verify on behalf of their subscribers, but as time goes on the subscriber device will sign and/or verify. I don't think the protocols change, but if devices have to get credentials that may be different from service providers (only) needing to be able to get credentials. I do think that a provisioning protocol needs to be decided upon, and that may be selecting from existing services that download the credential into the signer. That might, at first, be how the centralized credential services interact with service providers. It eventually needs to be how service providers interact with PBXs, and further how PBXs and/or service providers interact with devices. The process is the same, when we assign a number, or range of numbers, we "download" credentials, where "download" really is more complex in that it involves how the private key ends up on the signer. Brian On Jul 25, 2013, at 10:47 AM, Dave Crocker wrote: > On 7/24/2013 1:47 PM, Brian Rosen wrote: >> At some point, those same protocols could be extended to endpoints. I don't see that happening real soon perhaps, but I think it will happen. > > > It sounds as if there's a design goal disconnect here. > > The very general range of actors for the basic, SIP-based STIR environment that has been described on the list is roughly: > > > user-enterprise-+ +--user > | | > +--provider...provider--+ > | | > user-+ +--enterprise-user > > > The architectural model that you are describing for this round of effort is: > > > { Provider STIR } > > +=====================+ > / / > user-enterprise-+ / STIR / +--user > | / / | > +--/-provider...provider-/--+ > | / / | > user-+ / / +--enterprise-user > / / > +=====================+ > > > Inside the STIR box are signers and verifiers. > > By saying "at some point... extended to endpoints", you are almost certainly calling for defining an /additional/ technical mechanism, to accomplish the extension. More mechanism means more complexity and typically means component linkages that produce results which are not transparent. (In other words, rough edges through the extension.) > > > The alternative is to have an architecture that immediately /permits/ the extended participation, but probably will have more limited deployment as an /operational/ choice, rather than a technical limitation. > > Hence: > > { End-to-End STIR } > > +============================================================+ > / STIR / > / user-enterprise-+ +--user / > / | | / > / +--provider...provider--+ / > / | | / > / user-+ +--enterprise-user / > / / > +============================================================+ > > Again, inside the STIR box are signers and verifiers. > > An effort to extend the operation will, in this case, be only that -- extended operation -- and won't involve defining or deploying new technology. > > To the extent that someone claims that a post-hoc extension for the Provider STIR approach does not involve new technology -- new specification, new development, and new deployment -- please offer examples of this being done successfully. > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_0560_01CE893A.3637AD10 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcy NTE3MjM1NVowIwYJKoZIhvcNAQkEMRYEFJiL6OQm/EU63n/5qu5t3Ac/yruIMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAbQph8IT3WjATI0N0Oripw3UOYwsKzREPIVM50sbn tcztJ/odJMbsQg5POFUWzLctckwMnoDpDx1mUuSVRTDNXJx8MGpwOwZkI7lsVvbCzRWQEMF3/LgG 1WTKDTRrjhV3Ra6JV3dzQ76wYVAMP4gbGSRKMLQX9cRkRgwqO4RTo1ndFUH447hiUroxfiiDZsjP HUP5PmBzMbmc4EpSTD+XIBvy9sLwTjgs3cWN3InyLzrWBCGG3EwmtR3t5rndOEq/dWhkLFfssRqz FItURGB50aBKWhEv2Bz+NEzAH39ookk5oouCMbPNfcf9sXVa/HnSfUcN6CLbmBNdXK8X7PGrEgAA AAAAAA== ------=_NextPart_000_0560_01CE893A.3637AD10-- From br@brianrosen.net Thu Jul 25 10:25: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 00ADC21F96A8 for ; Thu, 25 Jul 2013 10:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.044 X-Spam-Level: X-Spam-Status: No, score=-99.044 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_QP_LONG_LINE=1.396, 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 Fgi04N83cL4d for ; Thu, 25 Jul 2013 10:25:07 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 7D28D21F9675 for ; Thu, 25 Jul 2013 10:25:07 -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=3V+0HGeQPw1xzQCirELpxlmr8W4k2zcTQ5eo1lhSSSY=; b=Qnfwk1SuT1dC+cLWavwHMI6IE9LK995lqJCYbxD6njFH3sJhtfUtp6l9zyfrItl5RuuQ1YKCPX8Al5VaIQ20+6ovdCSPICoHceMuS0R+pHJWEqWdu206bRofFZXnb2A3ZaBqOvAi8rtYyiglTS1CYPCoD0pNk0qZEnGTmrCDizA=; Received: from neustargw.va.neustar.com ([209.173.53.233]:55817 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1V2PHl-0006cH-CA; Thu, 25 Jul 2013 13:25:05 -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: <2B0F677F0B95454297753F58D4A07FA30129632F71@FHDP1LUMXC7V31.us.one.verizon.com> Date: Thu, 25 Jul 2013 13:25:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <61350158-AF11-4F20-B765-B9EED68F5B0F@brianrosen.net> References: <00C069FD01E0324C9FFCADF539701DB3BBC1A683@EX2K10MB1.corp.yaanatech.com> <6EF50BDB-3F41-49FE-83C1-20216D0D0BF0@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1BE03@EX2K10MB1.corp.yaanatech.com> <0073993E-1BC8-461C-9A7E-B5DCFC617DBF@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1C956@EX2K10MB1.corp.yaanatech.com> <011401ce87f2$75e5e880$61b1b980$@shockey.us> <51F13A8D.8070006@dcrocker.net> <98DE5818-FD12-49C4-A7E5-A92B18515F03@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30129632F71@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" , "dcrocker@bbiw.net" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 17:25:12 -0000 The solution will define what is signed. There are a couple of = proposals on the table, but they both have some form of to, from or PAI, = some form of call id and a timestamp. We'll have to discuss what an SP = does if there is already a signature. It could add one, or it could = decide not to add one. We haven't said much yet about what happens if PAI is not the same TN as = From. We need to decide what to do. We agreed early on that we had to support "benign spoofing". The = general mechanism is that the 3rd party is authorized by the number = holder to do it and gets a credential for that purpose. Think of it as = like another level of delegation. Brian On Jul 25, 2013, at 1:14 PM, "Dwight, Timothy M (Tim)" = wrote: > The scenario Brian describes seems likely to me, though the *very* = first deployments might be by non-SP companies with some particular = interest in the issue (e.g., banks, who don't want their phone numbers = spoofed as part of some scam, or organizations that are frequently the = victim of spoofing -related pranks, such as law enforcement agencies). >=20 > I have 2 related questions. >=20 > 1) If an SP "signs on behalf of its subscribers", what are they = expected to sign? FROM, P-A-ID, both, FROM but only if no P-A-ID is = present or assignable, something else? Should the SP behavior be = different if the user has already signed the contents of the FROM = header? >=20 > 2) I understand that "prevention of fraudulent caller ID spoofing" is = an objective. Are we also trying to facilitate "benign" spoofing? =20 >=20 > The reason for question #2 is that a "reasonable interpretation" of = 3GPP's OIP/OIR specification (TS 24.607) is that the called UE display = to the user the "network asserted identity" of the calling party = (P-A-ID) if available. It doesn't explicitly say that, but it says = enough negative things about use of the FROM header that that's at least = a reasonable interpretation. So I'm worried about the "benign spoofing" = case where the FROM header has a valid signature but yet the called = party never sees the number the caller intended, because his device gave = preference to the contents of P-A-ID. >=20 > Tim >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Brian Rosen > Sent: Thursday, July 25, 2013 11:29 AM > To: dcrocker@bbiw.net > Cc: stir@ietf.org > Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) >=20 > I can't follow you, sorry. >=20 > I think initially service providers will sign and verify on behalf of = their subscribers, but as time goes on the subscriber device will sign = and/or verify. >=20 > I don't think the protocols change, but if devices have to get = credentials that may be different from service providers (only) needing = to be able to get credentials. > I do think that a provisioning protocol needs to be decided upon, and = that may be selecting from existing services that download the = credential into the signer. That might, at first, be how the = centralized credential services interact with service providers. It = eventually needs to be how service providers interact with PBXs, and = further how PBXs and/or service providers interact with devices. The = process is the same, when we assign a number, or range of numbers, we = "download" credentials, where "download" really is more complex in that = it involves how the private key ends up on the signer. >=20 > Brian >=20 > On Jul 25, 2013, at 10:47 AM, Dave Crocker wrote: >=20 >> On 7/24/2013 1:47 PM, Brian Rosen wrote: >>> At some point, those same protocols could be extended to endpoints. = I don't see that happening real soon perhaps, but I think it will = happen. >>=20 >>=20 >> It sounds as if there's a design goal disconnect here. >>=20 >> The very general range of actors for the basic, SIP-based STIR = environment that has been described on the list is roughly: >>=20 >>=20 >> user-enterprise-+ +--user >> | | >> +--provider...provider--+ >> | | >> user-+ +--enterprise-user >>=20 >>=20 >> The architectural model that you are describing for this round of = effort is: >>=20 >>=20 >> { Provider STIR } >>=20 >> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D+ >> / / >> user-enterprise-+ / STIR / +--user >> | / / | >> +--/-provider...provider-/--+ >> | / / | >> user-+ / / +--enterprise-user >> / / >> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D+ >>=20 >>=20 >> Inside the STIR box are signers and verifiers. >>=20 >> By saying "at some point... extended to endpoints", you are almost = certainly calling for defining an /additional/ technical mechanism, to = accomplish the extension. More mechanism means more complexity and = typically means component linkages that produce results which are not = transparent. (In other words, rough edges through the extension.) >>=20 >>=20 >> The alternative is to have an architecture that immediately /permits/ = the extended participation, but probably will have more limited = deployment as an /operational/ choice, rather than a technical = limitation. >>=20 >> Hence: >>=20 >> { End-to-End STIR } >>=20 >> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >> / STIR / >> / user-enterprise-+ +--user / >> / | | / >> / +--provider...provider--+ / >> / | | / >> / user-+ +--enterprise-user / >> / / >> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>=20 >> Again, inside the STIR box are signers and verifiers. >>=20 >> An effort to extend the operation will, in this case, be only that -- = extended operation -- and won't involve defining or deploying new = technology. >>=20 >> To the extent that someone claims that a post-hoc extension for the = Provider STIR approach does not involve new technology -- new = specification, new development, and new deployment -- please offer = examples of this being done successfully. >>=20 >> d/ >> --=20 >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From Henning.Schulzrinne@fcc.gov Thu Jul 25 12: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 1C77F21F859A for ; Thu, 25 Jul 2013 12:10:21 -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 6E+2cQBXh6+M for ; Thu, 25 Jul 2013 12:10: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 1069521F94FD for ; Thu, 25 Jul 2013 12:10:15 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Dan York' , "dcrocker@bbiw.net" , Richard Shockey Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) Thread-Index: AQHOgoiaZJ964/Jc8k6czqEIJ08Lk5loauiAgAAh1ACAAJo+gIAAEIiAgAACsACAACgJAIABqUjggABIKACAANgXq4AAXSeAgAAFYQCAABB6AIAALmKAgAB7ZoCAA77zgIAAP4uAgAA2cwCAAT04AIAABgWAgAAuioCAAAd3AIAAIT0AgAAK7oCAAGkJgIAAkNSAgAGw1jA= Date: Thu, 25 Jul 2013 19:10:12 +0000 References: <51EF5925.8090904@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" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 19:10:21 -0000 An example of the kind of company that may well need to do at least signing= themselves, but possibly also validation, are hosted service providers lik= e Twilio. They have lots of 'bring your own number' customers and customers= that are often short-term, so that it seems unlikely that their SP could k= eep track of them all. Outsourced outbound call centers are likely in the s= ame boat - their SP has no good way of knowing who their real customers are= , given that they may be only short-timers for a specific calling campaign.= That may also be true for multi-site operations such as franchises that ma= y use a single SIP trunking SP for all their locations, each with their own= local number. Universities also have accumulated a hodge podge of numbers = through research centers and various outposts (random example: Columbia Com= puter Science has a completely separate number range from the rest of Colum= bia University), but they are now looking at the Internet2 national SIP pro= vider for all their VoIP needs. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dan= York Sent: Wednesday, July 24, 2013 9:12 AM To: dcrocker@bbiw.net; Richard Shockey Cc: stir@ietf.org Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) On 7/24/13 12:33 AM, "Dave Crocker" wrote: >If the technology permits signing and validating use by end-systems=20 >(users, enterprises, whatever), then they have the /option/ of doing=20 >STIR. The fact that operational convenience makes is strongly likely=20 >that most/all use will be by intermediary systems such as service=20 >providers, rather than end-systems, is only that: operational choice. Agreed. Before joining ISOC two years ago, I spent 4 years at a VoIP/IVR a= pplication platform company providing both a cloud/hosted service and an on= -premise software solution. What I found interesting was that, at that time= anyway, the companies using on the on-premise product were often either th= e very small but technically sophisticated (either a very small company or = a small project within a larger company) or the very large who had technica= l staff. In both cases they wanted to operate their own servers on their o= wn networks. As a company grew there came a point where outsourcing the se= rvice to a hosted/cloud platform made sense - and then at some point as the= company grew much larger they started to have their own IT and developer s= taff and often wanted to bring the applications back into their own data ce= nters. There were many exceptions to this trend, of course, but the trend = was visible. I suspect the trend will be similar with STIR. We'll have many individuals= and smaller entities who will run their own VoIP servers and will want to = do the signing and validation themselves. And we'll have very large organi= zations with IT and developer staff who will want to do the signing and val= idation. And the VAST majority of users will just have their service provi= ders do it. As Richard noted, many will just expect the SP to do it. >If the design restricts use to providers, then there is no opportunity=20 >for enterprises or end-users to sign or validate. > >Believe it or not, some individuals and some enterprises still run=20 >their own SMTP servers. That folk like you and me don't does not make=20 >it reasonable to prevent others from doing it. Exactly, and there will also be some network environments with high securit= y policies that require them to operate their own equipment and would in th= is case require them to do their own signing and validating. We need to assume in the design that the signing and validation can be done= at any point in the process, even if the operational reality will be that = in maybe 90+% of the cases all of that will be done by the service provider= s. 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/=20 _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Thu Jul 25 14:38: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 88E2D21F92A5 for ; Thu, 25 Jul 2013 14:38:27 -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.035, 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 t3-2s59exby7 for ; Thu, 25 Jul 2013 14:38:22 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0E96121F933B for ; Thu, 25 Jul 2013 14:38: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 r6PLcHSS023158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Jul 2013 21:38: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 r6PLcEYS021960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jul 2013 21:38:17 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6PLcEgk021948; Thu, 25 Jul 2013 21:38:14 GMT Received: from hadriel-macbook-2.fritz.box (/83.160.129.184) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 25 Jul 2013 14:38: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: <00C069FD01E0324C9FFCADF539701DB3BBC1D669@EX2K10MB1.corp.yaanatech.com> Date: Thu, 25 Jul 2013 17:38:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <969CF0CD-3295-4147-8315-1A548B07EA44@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1D669@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" , "jon.peterson@neustar.biz" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jul 2013 21:38:27 -0000 On Jul 25, 2013, at 8:57 AM, Michael Hammer = wrote: > Please stop making silly statements like this. Which statement is silly? > Somehow we know that the multiple CIDER CAs are good, but somehow we = can't=20 > know that a cert CA is good. I'm talking below about RFC 4474. And yes, there really is a difference = between a CA constrained in scope to what numbers it can claim, that the = verifier can actually know its authoritative for those numbers, vs. a CA = that can claim any number on the planet it likes. Again, the problem DigiNotar created wasn't just a problem for their = domains that they were compromised - it's that every other domain in the = Internet was affected by them being compromised. There truly is a difference between "limited trust" and "unlimited/blind = trust". > Also, that a CIDER transaction can happen in real-time, but a = non-CIDER=20 > transaction could not happen in real time. Where do I say that, below? > As I pointed out before, if the private/public key pair of the number = holder=20 > is compromised, > there is no difference in how you regenerate the pair and get the = private key=20 > into the hands of the signer. > There is no difference in the time it takes to send the private key or = the=20 > cert to that user. I have no idea what those things have to do with my email below. Are you talking about the same email?? [ Please stop making silly statements like those. ;) ] -hadriel >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of=20 > Hadriel Kaplan > Sent: Thursday, July 25, 2013 2:09 AM > To: Peterson, Jon > Cc: stir@ietf.org List > Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack = model >=20 >=20 > On Jul 23, 2013, at 9:26 PM, "Peterson, Jon" = wrote: >=20 >> RFC4474 (/RFC4474bis) doesn't restrict access to certificates to HTTP >> fetches. RFC4474 is pretty agnostic about how you get certs. We = talked >> about certs being included in SIP messages, so they'd arrive along >> with the signature. We talked about using SIP itself to fetch them, >> via SUBSCRIBE. We considered cases where verifiers had access to >> caches, or even local cert stores. At the time we were doing RFC4474, >> HTTP seemed like the right thing to hype for a number of reasons, so = we=20 >> encouraged it. >> But the URL in Identity-Info is just supposed to be a helpful >> suggestion, not the sole and authoritative means of access to certs. >=20 > The concept of ignoring the URL is so broken, I'm still in mental = denial that=20 > 4474 says you can ignore it. Considering how carefully the IESG reads = my=20 > drafts for publication, I'm at a loss as to how they let 4474 through. >=20 >=20 >> For the STIR >> case, however, that hint might be useful to disambiguate for = verifiers >> which authority signed a SIP request, when there are multiple >> authorities for a single number (the function the CIDER "public key >> index value" would serve, if I understand correctly). >=20 > How does the URL string "http://foo.com/dcjovbneoc.cer" help me figure = out=20 > which authority signed the request? I'd have to retrieve the cert = from that=20 > URL... and then I'd see some CA signed it, but how do I know that CA = is=20 > authoritative for that E.164 number? >=20 > It's true that the purpose of the CIDER key index value is to let = there be=20 > multiple public keys in-use for the same E.164, but they're all = "signed" by=20 > the same "CA" - the only one truly authoritative for the E.164 number. = But=20 > more to-the-point, it provides a way for changing the public keys = while SIP=20 > messages are in-flight. Ultimately, no matter what protocol we pick, = if=20 > carriers have local database copies then it will take some time for = the public=20 > keys used to sign SIP messages to get propagated out. So you need a = way to=20 > change your key in-advance, still use the old key for some period of = time and=20 > then switch to using the new one, and indicate on a per-SIP-message = bases=20 > which of the keys you're using. >=20 > The same thing would have been true if RFC 4474 had ever seen the = light of=20 > day. So imagine if the sender was using = "http://foo.com/dcjovbneoc.cer" for=20 > some period of time, and then changed to = "http://foo.com/cebcuhlked.cer". How=20 > would this work, if a verifier ignores this URL because 4474 said it = was ok? >=20 > I guess I do agree with one thing you said a while back: we do indeed = have to=20 > deprecate RFC 4474. Not because we'll define something better, but = because=20 > it's broken. >=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 From michael.hammer@yaanatech.com Thu Jul 25 15:33: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 3E58221F859A for ; Thu, 25 Jul 2013 15:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 VxAgA2DGmTQa for ; Thu, 25 Jul 2013 15:33: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 4304321F849C for ; Thu, 25 Jul 2013 15:33:37 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Thu, 25 Jul 2013 15:33:36 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) - attack model Thread-Index: AQHOiX9KgCVNuKHctkadSPQtb2t4CJl19sgA Date: Thu, 25 Jul 2013 22:33:35 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC1DF98@EX2K10MB1.corp.yaanatech.com> References: <969CF0CD-3295-4147-8315-1A548B07EA44@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1D669@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.88] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_06A6_01CE8965.789A1870" MIME-Version: 1.0 Cc: "stir@ietf.org" , "jon.peterson@neustar.biz" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jul 2013 22:33:51 -0000 ------=_NextPart_000_06A6_01CE8965.789A1870 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit First, you are using RFC4474 as a proxy for any type of Cert-based system. So, I reserve the right to say that not all Cert-based systems are the same. You clearly have some rules/characteristics that make a "good" CA. You do not show that a Cert-based system could not also be a good CA. (And you know it is silly to try and prove a negative, right?) Second, let me take your statements below one by one: > It's true that the purpose of the CIDER key index value is to let > there be multiple public keys in-use for the same E.164, but they're > all "signed" by the same "CA" - the only one truly authoritative for > the E.164 number. There is no reason that the same could not also be true for Certs. > But more to-the-point, it provides a way for > changing the public keys while SIP messages are in-flight. If you create a new private/public key pair while the SIP message is in-flight, I presume it has already been signed, so the new public key is not usable until the SIP sender has been given the corresponding private key. > Ultimately, no matter what protocol we pick, if carriers have local > database copies then it will take some time for the public keys used > to sign SIP messages to get propagated out. Ummm, you don't sign with the public key. That would be silly, as only the sender could decode it. > So you need a way to > change your key in-advance, still use the old key for some period of > time and then switch to using the new one, and indicate on a per-SIP-message bases which of the keys you're using. Agree. That is the same for CIDER or for Cert-based solution. :) Mike -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Thursday, July 25, 2013 5:38 PM To: Michael Hammer Cc: jon.peterson@neustar.biz; stir@ietf.org Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model On Jul 25, 2013, at 8:57 AM, Michael Hammer wrote: > Please stop making silly statements like this. Which statement is silly? > Somehow we know that the multiple CIDER CAs are good, but somehow we > can't know that a cert CA is good. I'm talking below about RFC 4474. And yes, there really is a difference between a CA constrained in scope to what numbers it can claim, that the verifier can actually know its authoritative for those numbers, vs. a CA that can claim any number on the planet it likes. Again, the problem DigiNotar created wasn't just a problem for their domains that they were compromised - it's that every other domain in the Internet was affected by them being compromised. There truly is a difference between "limited trust" and "unlimited/blind trust". > Also, that a CIDER transaction can happen in real-time, but a > non-CIDER transaction could not happen in real time. Where do I say that, below? > As I pointed out before, if the private/public key pair of the number > holder is compromised, there is no difference in how you regenerate > the pair and get the private key into the hands of the signer. > There is no difference in the time it takes to send the private key or > the cert to that user. I have no idea what those things have to do with my email below. Are you talking about the same email?? [ Please stop making silly statements like those. ;) ] -hadriel > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of Hadriel Kaplan > Sent: Thursday, July 25, 2013 2:09 AM > To: Peterson, Jon > Cc: stir@ietf.org List > Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack > model > > > On Jul 23, 2013, at 9:26 PM, "Peterson, Jon" wrote: > >> RFC4474 (/RFC4474bis) doesn't restrict access to certificates to HTTP >> fetches. RFC4474 is pretty agnostic about how you get certs. We >> talked about certs being included in SIP messages, so they'd arrive >> along with the signature. We talked about using SIP itself to fetch >> them, via SUBSCRIBE. We considered cases where verifiers had access >> to caches, or even local cert stores. At the time we were doing >> RFC4474, HTTP seemed like the right thing to hype for a number of >> reasons, so we encouraged it. >> But the URL in Identity-Info is just supposed to be a helpful >> suggestion, not the sole and authoritative means of access to certs. > > The concept of ignoring the URL is so broken, I'm still in mental > denial that > 4474 says you can ignore it. Considering how carefully the IESG reads > my drafts for publication, I'm at a loss as to how they let 4474 through. > > >> For the STIR >> case, however, that hint might be useful to disambiguate for >> verifiers which authority signed a SIP request, when there are >> multiple authorities for a single number (the function the CIDER >> "public key index value" would serve, if I understand correctly). > > How does the URL string "http://foo.com/dcjovbneoc.cer" help me figure > out which authority signed the request? I'd have to retrieve the cert > from that URL... and then I'd see some CA signed it, but how do I know > that CA is authoritative for that E.164 number? > > It's true that the purpose of the CIDER key index value is to let > there be multiple public keys in-use for the same E.164, but they're > all "signed" by the same "CA" - the only one truly authoritative for > the E.164 number. But more to-the-point, it provides a way for > changing the public keys while SIP messages are in-flight. > Ultimately, no matter what protocol we pick, if carriers have local > database copies then it will take some time for the public keys used > to sign SIP messages to get propagated out. So you need a way to > change your key in-advance, still use the old key for some period of > time and then switch to using the new one, and indicate on a per-SIP-message bases which of the keys you're using. > > The same thing would have been true if RFC 4474 had ever seen the > light of day. So imagine if the sender was using > "http://foo.com/dcjovbneoc.cer" for some period of time, and then > changed to "http://foo.com/cebcuhlked.cer". How would this work, if a verifier ignores this URL because 4474 said it was ok? > > I guess I do agree with one thing you said a while back: we do indeed > have to deprecate RFC 4474. Not because we'll define something > better, but because it's broken. > > -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_06A6_01CE8965.789A1870 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcy NTIyMzMzNFowIwYJKoZIhvcNAQkEMRYEFLCAvatIYM96dipAaBf8uQFijzbuMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAZvjH4iiGJjADgk+vMLgA2Viv/gK7qmdBhcxptbXI ypJz4mDZ2RCv2ZRlCvxjeHqHYMFkHBnvWXXtXsLVPCx0pnJ4JsKZQ1HlEf3+PjBlNibcA9QKTLk6 T6D0kBw7K06gtbrkB9t3erb+4US+KKt0E5zG8dPLYJQZPY4fHgGDJLs80us46iEjUDzBJsFUW0+f qu3iHE6Pf/7FI2cT1vwZ/oDiNUz0iW+1B3Vt+CuY6xHdDf5YQH3vZJBMpuScPMAn1W/6WIgJm+dL FG8DJj7Bi0nFeBLGC4TrCcBkRf+5ZN+FaVorFDgTNjCmPoPyQ8iB4On9dxgrFX24HxZ8CNl0bwAA AAAAAA== ------=_NextPart_000_06A6_01CE8965.789A1870-- From jon.peterson@neustar.biz Thu Jul 25 15:58: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 A808D21F8B04 for ; Thu, 25 Jul 2013 15:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.024 X-Spam-Level: X-Spam-Status: No, score=-106.024 tagged_above=-999 required=5 tests=[AWL=0.575, 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 IDOUHNc1PJPs for ; Thu, 25 Jul 2013 15:58:02 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 554BB21F848A for ; Thu, 25 Jul 2013 15:58:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1374793630; x=1690153402; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=6Hb0deBubX pihvrZBcfOC/jvm8iR6jXPmnDIZv+DLbU=; b=WfBHeI2zov6jtK8eyel1jAlIkR H9Ojv1vvt7Fc4pt8xzpBRchR22EJTOYoCHZrwcZ6OgjDvoaQvVJrAb5nfzzw== Received: from ([10.31.58.71]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.28683852; Thu, 25 Jul 2013 19:07:09 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.178]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Thu, 25 Jul 2013 18:57:55 -0400 From: "Peterson, Jon" To: Hadriel Kaplan Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) - attack model Thread-Index: AQHOiS8sLeSsxyIiBkaYwkYYsmijuZl10CCA Date: Thu, 25 Jul 2013 22:57:54 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [192.168.128.149] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: BOhLqu3W7KMmk0gTKc4RyQ== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org List" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jul 2013 22:58:06 -0000 Well, my aim in sending that mail was to try to show how we're talking past each other, and I do hope this exchange makes that clear. The implementation of a DNS deployment can involve plenty of delegation and caching, and for scalability reasons those tend to be desirable properties. That doesn't change the fact that the DNS is a tree, with a root, and that logically you have to acquire authoritative records from the "right place." What that really means is you get signed records from a service that is rooted in and delegate from the right trust anchor - that trust anchor basically is only accessible through that DNS tree, descending from that root. If you found a bare public key that once lived in a DNS zone lying on the street, nothing intrinsic about the key would let you trust it. It can only be trusted if it's downloaded from the tree where it belongs. Certs have a trust anchor too, but the specific Internet service you use to download a cert doesn't have to have any relationship with that trust anchor. As I've said, it's even possible that a cert could accompany SIP signaling in-band, and it would be just as trustable as it would be if you downloaded it from some kind of "authoritative" store. The fact that Identity-Info suggests a place where a cert can be acquired does not raise any new risks, as far as I can tell, or any requirement to check for revocation that wouldn't exist without Identity-Info. Is it a problem that certs can "float around in various places" for a time? To pretty much the same degree that it's a problem that DNS records can be cached for a time. If there's a requirement for freshness, we'd end up engineering something for either the DNS or certs that checks freshness. As Cullen recently pointed out, the exact requirement here needs some careful scrutiny: we probably don't need to revoke authority from the donating carrier of a port in any great hurry. I think this is engineerable for either the DNS or certs. No one is suggesting that you trust a CA just because it's any old CA. The prospect that there would be multiple CAs with overlapping authority (authority for the same number ranges) is discouraged in the problem statement draft today. But this is very comparable is there being multiple DNS trust roots, perhaps in private deployments or in different nationalities. I don't see a ton of difference here. Another potential difference you raise is how the scope of authority for CAs is specified, and how that compares to a DNS solution. Verifiers do need to know if a CA is authoritative for a country code, say, there's no doubt about it. If we could have an international organization that delegates down to national regulators or what have you, that would make this all a lot clearer. But we could deploy that for either certs or the DNS, right? There's nothing unique about the DNS there. The problem is, it's not clear to me that this is actually desirable or practical. Doing this for the DNS is essentially jumping back into the problem of public ENUM, which wasn't a sterling success. I think the alternative is to try to work from the national level up, instead of an international root down. This is a very important design decision, and exactly the sort of thing we'd need to discuss were this chartered. But I'd say we face that design decision for either CAs or the DNS. So again, I don't see a ton of difference there either. If we can't agree on the respects in which these approaches are similar, we're certainly not going to agree on any respect in which there are differences that could inform later decisions. Jon Peterson Neustar, Inc. On 7/25/13 12:59 AM, "Hadriel Kaplan" wrote: > >On Jul 23, 2013, at 9:26 PM, "Peterson, Jon" >wrote: > >> Part of the reason I think we're all talking past each other here is >>that >> certs are relatively self-contained documents, and you could get them >>in a >> number of ways, and I don't think there's any pressing need for us to >> restrict those ways. > >Part of the problem is in fact that they are "self-contained documents". >Having certs floating around in various places with no rules other than >they age out in a year or two is what raises the concern around >revocations. For example, the fact that 4474 lets the sender of the SIP >message tell people where to get a cert, is the reason we would have the >need for revocations and highly-scalable CRLs. > > >> For DNS proposals (if they don't just stick CA certs >> in the DNS), on the other hand, the way you get a credential is >> inextricably coupled to the semantics of the credential itself, which is >> why the CIDER proposal isn't just a protocol, it's a whole deployment >> architecture. The credentials lose any semantics if they are divorced >>from >> the deployment environment you're supposed to fetch them from. All >> credentials must be uploaded through that central service and all >> credentials must be downloaded from its (distributed) deployment. > >Well... that's not actually true, but yes I would expect it to be >effectively true in practice. I mean you can, for example, have multiple >anchors and multiple DNS admins for a country-code; but it wouldn't make >much sense in my opinion. Or you could, for example, split a >country-code tree among multiple DNS administrations of the database. >But again I don't know why you'd want to. > > >> There doesn't need to be a "national authority" cloud service that >>manages >> access to certs in this way. > >There needs to be one or more databases somewhere to get the certs. >We've already agreed (I think?) that we don't want to identify what >carriers own what numbers publicly. Ergo, someone other than the >carriers has to provide a database to get certs - even if it's just a >master copy that's copied into local copies in carriers. > > >> The reason you trust a cert isn't because you >> downloaded it from the right place, it's because you trust the trust >> anchor that signed the cert. > >Technically DNSSEC doesn't require the answer to come from "the right >place". There can be caches and resolvers all over the place; you can >even replicate entire trees in random locations, without being >authoritative for them. So long as the signature chain is valid, it's >good. In that sense it's quite similar to certs. > > >> This isn't about HTTP - it doesn't matter if >> you found the cert lying on the ground. > >Simply trusting a CA because it's a "CA" is how we got to DigiNotar. To >avoid that, even if we use certs and HTTP, we'll have to have some way of >scoping the CA's authority, and letting that scope change over time. The >verifiers need to know which CAs are authoritative for which >country-codes, and even within country-codes they need to know which >region prefix CAs are authoritative. For example which area-codes are >under which of the +1 NANP member country admin CAs, including as new >area-codes are added; and as country-codes are added or changed. >Obviously we can accomplish all that using HTTP, by defining how that >would work, defining some encoding/list thingy, where such a list is >retrieved from, how often you check for changes, etc. Using a DNS >structure happens to let all that be done automatically. Automation is >*good*. > >I know it's boring to not get to define a lot more new things, but I'm >sure we can find something else to do. ;) > > >> This is why I don't understand the >> need for "hard cider," or indeed why it would be important for a >> verification service to be able to derive a single canonical location >>from >> which it will download a cert by studying the originating number alone. > >The verifier doesn't derive a "single canonical location" from which it >will download the cert. It derives a single canonical query key - in DNS >it's a DNS query key, but for HTTP it could be the URL's path portion >(not hostname). The physical "location" (ie, the server) it retrieves it >from is a local policy administrative decision, but the query key it uses >is consistent no matter what carrier/location it's in. > >For example, a potential Hard CIDER model would be such that when you >receive a call from +1-603-555-1234 with a key index of 99, you create a >URL like this: >http://mylocalserver.mydomain.com/cid/16035551234/99.cer > >The "mylocalserver.mydomain.com" would be replaced with whatever your >local Hard CIDER server's hostname is, or even 192.168.1.2. > >Why? So that we actually get some interoperability between verifier >clients and cert-serving servers. So that we can then describe how the >local server might actually know what cert to give back to the client, >how it got the cert, how its local database of certs is synchronized with >a master DB, how we're going to handle international numbers, etc. You >know... specify an actual solution, not just magic pixie dust. > > >> I >> kind of see why this is important for a DNS-based solution (though the >> harm DNS URI Identity-Info would do there isn't clear to me - if it >>points >> to something you don't trust, don't trust it), but not for a cert-based >> solution. If you could, for example, just receive the cert in-band with >> the request, that would seem to obviate the need to go ask anyone for >>it. > >That would have the same problem as a HTTP URL in Identity-Info. Letting >the sender of the SIP message tell people where to get a cert (or >directly giving it to them as an attachment), is the reason we would have >the need for revocations and highly-scalable CRLs. Besides, we can't >send the cert in-band. Doubling the SIP message size and relying on >multi-part MIME to work end-to-end is not a way to get this stuff >deployed. > >-hadriel > From dhc@dcrocker.net Fri Jul 26 04:22: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 813C621F9306 for ; Fri, 26 Jul 2013 04:22: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 4+n0bgFWjBEJ for ; Fri, 26 Jul 2013 04:22:15 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4BB21F90C3 for ; Fri, 26 Jul 2013 04:22:15 -0700 (PDT) Received: from [192.168.174.125] ([192.173.4.185]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r6QBM6nR012760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Jul 2013 04:22:11 -0700 Message-ID: <51F25BDC.1020907@dcrocker.net> Date: Fri, 26 Jul 2013 12:22:04 +0100 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Brian Rosen References: <00C069FD01E0324C9FFCADF539701DB3BBC1A683@EX2K10MB1.corp.yaanatech.com> <6EF50BDB-3F41-49FE-83C1-20216D0D0BF0@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1BE03@EX2K10MB1.corp.yaanatech.com> <0073993E-1BC8-461C-9A7E-B5DCFC617DBF@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1C956@EX2K10MB1.corp.yaanatech.com> <011401ce87f2$75e5e880$61b1b980$@shockey.us> <51F13A8D.8070006@dcrocker.net> <98DE5818-FD12-49C4-A7E5-A92B18515F03@brianrosen.net> In-Reply-To: <98DE5818-FD12-49C4-A7E5-A92B18515F03@brianrosen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 26 Jul 2013 04:22:14 -0700 (PDT) Cc: stir@ietf.org Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) 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, 26 Jul 2013 11:22:20 -0000 On 7/25/2013 5:28 PM, Brian Rosen wrote: > I don't think the protocols change, Sorry for my confusion. The opening text of your note that I was responding to seemed to imply otherwise: "I think enterprise PBXs will assert and check identity if we provide the right tools. That would mean automated mechanisms to acquire credentials. If we provided provisioning mechanisms that loaded authorized numbers and credentials from the service provider who delegated the numbers, and we provided an automated way for the PBX to get the public keys to verify, I think many PBX vendors would implement that." All of the above sounds to me like new mechanism, which means new technology, which means new protocols. Since you say that you intend it to mean no new protocols, can you explain how to achieve these enhancements? > but if devices have to get > credentials that may be different from service providers (only) > needing to be able to get credentials. Hmmm. That's an interesting vector. New credentials means new operational infrastructure. While it doesn't (necessarily) mean new protocols or software, it's still a significant barrier to adoption... Unless all you mean is the obvious increment of adding credentials for the new actors, rather than meaning a new credential infrastructure? > I do think that a provisioning > protocol needs to be decided upon, and that may be selecting from > existing services that download the credential into the signer. I thought the interesting task was /uploading/ the public key to the queriable database. Given your other comments, I guess your model is that it' the service operator who is dictating to the enterprise what their key will be and, therefore, will download it to them. But in any case, I suspect we have a broad agreement that the provisioning mechanisms are essential and well might require development. > That > might, at first, be how the centralized credential services interact > with service providers. Whenever the topic is a multi-administration, global Internet service, reference to its being 'centralized' does not compute for me, especially when followed by a plural -- serviceS -- since it sounds contradictory. Since STIR will have wide diversity -- at least involving different telco administration but probably also a wide range of enterprises - I do not understand what mean by centralized. Please explain. > It eventually needs to be how service > providers interact with PBXs, and further how PBXs and/or service > providers interact with devices. Service providers? This seems to presume that the public key provision must go through the telco service providers? Just as one's DNS provisioning can be independent of one's ISP, why can't one's STIR key provision be independent of one's telco? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Fri Jul 26 04:34: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 4AAEE21F8FDC for ; Fri, 26 Jul 2013 04:34:52 -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 HqLIme58a5NY for ; Fri, 26 Jul 2013 04:34:47 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 57EEB21F8FD8 for ; Fri, 26 Jul 2013 04:34:47 -0700 (PDT) Received: from [192.168.174.125] ([192.173.4.185]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r6QBYfPR012951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Jul 2013 04:34:46 -0700 Message-ID: <51F25ECF.7010100@dcrocker.net> Date: Fri, 26 Jul 2013 12:34:39 +0100 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: <00C069FD01E0324C9FFCADF539701DB3BBC1A683@EX2K10MB1.corp.yaanatech.com> <6EF50BDB-3F41-49FE-83C1-20216D0D0BF0@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1BE03@EX2K10MB1.corp.yaanatech.com> <0073993E-1BC8-461C-9A7E-B5DCFC617DBF@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1C956@EX2K10MB1.corp.yaanatech.com> <011401ce87f2$75e5e880$61b1b980$@shockey.us> <51F13A8D.8070006@dcrocker.net> <98DE5818-FD12-49C4-A7E5-A92B18515F03@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC1DC78@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC1DC78@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, 26 Jul 2013 04:34:47 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) 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, 26 Jul 2013 11:34:52 -0000 On 7/25/2013 6:23 PM, Michael Hammer wrote: > I am wondering if this could be a proxied protocol based on HTTP. Mike, Sorry, but I don't understand what you mean "proxied protocol based on HTTP". Please explain. (Type slowly since I clearly need to listen more carefully...) > Each SP could validate each proxy hop, Ditto on "proxy hop". The diagrams I provided show relaying, but nothing was meant to be "proxying". For that matter, I'm not sure what it means to "proxy" for this mechanism. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From michael.hammer@yaanatech.com Fri Jul 26 07:21: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 AB1C411E80ED for ; Fri, 26 Jul 2013 07:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 CH1WLDXH4xUu for ; Fri, 26 Jul 2013 07:21: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 611C021F842A for ; Fri, 26 Jul 2013 07:21: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, 26 Jul 2013 07:21:16 -0700 From: Michael Hammer To: "dcrocker@bbiw.net" Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) Thread-Index: AQHOgvzGoW2Sqvrxc0GEvdoogk5ro5lpa5QAgAAoCgCAAe3VAIAAA5sAgAEbyACAABl1gP//jBDQgACJywD//6q3gIAA/xKAgANB3HCAALyhgP//tYrwADfEMAAADkF6MP//woOAgABwijD//7gqAIAACu6AgADzGICAAbPSgIAAHDaAgABpnKCAANaUgIAATIDA Date: Fri, 26 Jul 2013 14:21:14 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC1E2E2@EX2K10MB1.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC1A683@EX2K10MB1.corp.yaanatech.com> <6EF50BDB-3F41-49FE-83C1-20216D0D0BF0@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1BE03@EX2K10MB1.corp.yaanatech.com> <0073993E-1BC8-461C-9A7E-B5DCFC617DBF@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1C956@EX2K10MB1.corp.yaanatech.com> <011401ce87f2$75e5e880$61b1b980$@shockey.us> <51F13A8D.8070006@dcrocker.net> <98DE5818-FD12-49C4-A7E5-A92B18515F03@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC1DC78@EX2K10MB1.corp.yaanatech.com> <51F25ECF.7010100@dcrocker.net> In-Reply-To: <51F25ECF.7010100@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.97] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0029_01CE89E9.DB033990" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 14:21:27 -0000 ------=_NextPart_000_0029_01CE89E9.DB033990 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dave, We have a well-known mechanism with SIP, which is based on HTTP, and which relays the INVITEs from UA through a series of proxies before reaching the destination UA. IMS provides more control around how that occurs. The UA typically registers using credentials with the first proxy. Subsequent hops between proxies within an SP are on secure paths. Subsequent hops between proxies of different SPs are provisioned based on bilateral agreements and also secured. Record-Route keeps track of which proxies stay in the signaling path and is used to create the Route header which allows subsequent transactions to follow a defined path. IMS uses insertion of Route headers to control the path within an SP infrastructure. We could probably do this in on RTT end to end. As this is closely related to the use of SIP for VoIP, I could see there being a new SIP method created, whereby the UA sends a request which is routed up the chain to a national authority (e.g. FCC) controlled server that would bind a new public key to the Tel# and return a signed Cert to the requester along the same path. The national authority and SPs in the path could cache that cert on the return path and make available on publicly available site. We know how to do SIP. We know how to do Certs. Just reuse of well-known technologies. Just thinking aloud here. Mike -----Original Message----- From: Dave Crocker [mailto:dhc@dcrocker.net] Sent: Friday, July 26, 2013 7:35 AM To: Michael Hammer Cc: stir@ietf.org Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) On 7/25/2013 6:23 PM, Michael Hammer wrote: > I am wondering if this could be a proxied protocol based on HTTP. Mike, Sorry, but I don't understand what you mean "proxied protocol based on HTTP". Please explain. (Type slowly since I clearly need to listen more carefully...) > Each SP could validate each proxy hop, Ditto on "proxy hop". The diagrams I provided show relaying, but nothing was meant to be "proxying". For that matter, I'm not sure what it means to "proxy" for this mechanism. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ------=_NextPart_000_0029_01CE89E9.DB033990 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcy NjE0MjExM1owIwYJKoZIhvcNAQkEMRYEFCQj5y1Zc9FcXX388PUFK5CeFjKAMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAXo43SAkLXybKNg0uFJ1wk72zHj9Oa+3KQBaHgKfl 2fCC027QICDu3wL1MLSRlWB6JFkf9Apth5bFsdxq7fMQi5fQfWKd2RKjjg3gcfRc6NIzXJ8ZrNVJ y33l10BGW/4xRoHsmWWSs8F2EWrxYgMZeCS03OEXowuc0iqt6J2A2CXI+eiPoJV3f+QGHd+yyiVu pcupiyTl52dJWKvNvAvGjGv+zHbnwhFptfjQanl5KXMp2B6sgCmecaw6NUxNOGWb2geH1sDKtuJw ZNPlUdleHj0789PkJh7rsm/HMHrEQLKGq/vMy3sEvvHWBOTHRL0SIfxu600Ec+/tSmA9rigaygAA AAAAAA== ------=_NextPart_000_0029_01CE89E9.DB033990-- From br@brianrosen.net Fri Jul 26 07: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 4A24621F99C7 for ; Fri, 26 Jul 2013 07:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.741 X-Spam-Level: X-Spam-Status: No, score=-99.741 tagged_above=-999 required=5 tests=[AWL=0.696, 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 JMWPvxlcawQs for ; Fri, 26 Jul 2013 07:30:12 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id ABFAA21F9993 for ; Fri, 26 Jul 2013 07:30:07 -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=dBL5jzuDE5RS6mv4oTVI6H+a+nvaDBI9txgAgIbO048=; b=B29hXOp1qQcoRNvRC6SDIy1lzrnlJlyGuhxy+5jDsWBoGlfr2Z0w5XbRUMvtpfg/tUlKk7kZh+yrnBwRJWnOR5axM+aSm1AJfPMtpZj39IGvSyTbxS0O1rM1q/oXZAaJwOULWAIeFnxkWSspCR9wyj0N2hOD2+VuU36VQiBJPHM=; Received: from neustargw.va.neustar.com ([209.173.53.233]:59852 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1V2j1y-0003OB-2i; Fri, 26 Jul 2013 10:30:06 -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: <51F25BDC.1020907@dcrocker.net> Date: Fri, 26 Jul 2013 10:30:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00C069FD01E0324C9FFCADF539701DB3BBC1A683@EX2K10MB1.corp.yaanatech.com> <6EF50BDB-3F41-49FE-83C1-20216D0D0BF0@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1BE03@EX2K10MB1.corp.yaanatech.com> <0073993E-1BC8-461C-9A7E-B5DCFC617DBF@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1C956@EX2K10MB1.corp.yaanatech.com> <011401ce87f2$75e5e880$61b1b980$@shockey.us> <51F13A8D.8070006@dcrocker.net> <98DE5818-FD12-49C4-A7E5-A92B18515F03@brianrosen.net> <51F25BDC.1020907@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 Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 14:30:19 -0000 Okay, it's really hard to be completely technology neutral, and actually = communicate clearly. I think that delegation of telephone numbers happen 2-8 times (that is, = there are between two and say 8 delegations of a number from the root = (national telephone number plan administration) to the thing that places = the call. If this was some kind of cert chain, that would mean that verifying the = signing certificate could, in theory, require 7 signature verifications, = plus the actual signature itself. It also means that prior to the call, we repeated a sequence 8 times: a) A delegation is made b) A public and private key pair is created c) The private key is installed in the delegate, and the public key is = stored in some kind of database Regardless of the technology, there is some protocol operation that = accomplishes b and c. If you think that the actual assignment of the = number (or number range) is automated, than in fact there is a protocol = for a also. I think that the protocol needed to accomplish b and c can be used at = every level of delegation, although there isn't any real barrier to = having more than one. One of the delegations is from the national = number authority to a service provider. There could be several = instances of service provider to service provider delegation (number = resell). Another is a service provider to a PBX. Another is from the = PBX to a device, another is from either the PBX or the device to some = authorized 3rd party (the "on behalf of" case). In each case there is a = new credential and a new private/public key pair, where the private key = ends up on the delegate and the public key ends up in a database. In = each case we COULD include the actual provisioning of the number = assignment as well as assuring the private key ends up on the delegate. Notice that I did not state HOW the private key ends up on the delegate. = I usually assume it's generated on the delegate but it could be = downloaded. I think stir needs to define at least one protocol for b and c, and = optionally a. Then, if the database that holds credentials needs to be accessible from = only service providers, even if there are a significant number of them, = that may be a whole lot different from a situation where devices need = those credentials. The former is a controlled set of queriers, and the = latter is a completely public database. =20 Okay, so back to my 8 levels of delegation. In theory, you actually have a chain of 8 signatures. If the database = DNS, the zone is delegated to some entity. I don't think that, so far = anyway, anyone has proposed that we delegate the actual DNS zones one = telephone number at a time. All the proposals have some level of = centralized authority maintaining the actual DNS authoritative server. = That's "centralized". If the database contains certs, in theory, each = of the 8 delegates can have a separate database to hold their certs, but = we don't think that's a good idea. We really do think we should have a = smaller number of actual signers. That means that we have a = "centralized" database maintainer, and the delegations are accomplished = using this centralized service, so the cert that is used to sign is = signed by the centralized server instead of the next level up delegate. = In both cases, the content is controlled by the delegates, but the = database itself is operated by some more centralized entity But in both cases, I don't imply "one". It might be ideal to have one = per country. I think with the DNS solution, you pretty much have to do = that if porting is allowed. With certs, you could, but you could also = allow all 8 to run their own if they insisted, or anything in between.=20= Brian On Jul 26, 2013, at 7:22 AM, Dave Crocker wrote: > On 7/25/2013 5:28 PM, Brian Rosen wrote: >> I don't think the protocols change, >=20 > Sorry for my confusion. The opening text of your note that I was = responding to seemed to imply otherwise: >=20 > "I think enterprise PBXs will assert and check identity if we = provide the right tools. That would mean automated mechanisms to = acquire credentials. If we provided provisioning mechanisms that loaded = authorized numbers and credentials from the service provider who = delegated the numbers, and we provided an automated way for the PBX to = get the public keys to verify, I think many PBX vendors would implement = that." >=20 > All of the above sounds to me like new mechanism, which means new = technology, which means new protocols. Since you say that you intend it = to mean no new protocols, can you explain how to achieve these = enhancements? >=20 >=20 >> but if devices have to get >> credentials that may be different from service providers (only) >> needing to be able to get credentials. >=20 > Hmmm. That's an interesting vector. New credentials means new = operational infrastructure. While it doesn't (necessarily) mean new = protocols or software, it's still a significant barrier to adoption... = Unless all you mean is the obvious increment of adding credentials for = the new actors, rather than meaning a new credential infrastructure? >=20 >=20 >> I do think that a provisioning >> protocol needs to be decided upon, and that may be selecting from >> existing services that download the credential into the signer. >=20 > I thought the interesting task was /uploading/ the public key to the = queriable database. >=20 > Given your other comments, I guess your model is that it' the service = operator who is dictating to the enterprise what their key will be and, = therefore, will download it to them. >=20 > But in any case, I suspect we have a broad agreement that the = provisioning mechanisms are essential and well might require = development. >=20 >=20 >> That >> might, at first, be how the centralized credential services interact >> with service providers. >=20 > Whenever the topic is a multi-administration, global Internet service, = reference to its being 'centralized' does not compute for me, especially = when followed by a plural -- serviceS -- since it sounds contradictory. >=20 > Since STIR will have wide diversity -- at least involving different = telco administration but probably also a wide range of enterprises - I = do not understand what mean by centralized. Please explain. >=20 >=20 > > It eventually needs to be how service >> providers interact with PBXs, and further how PBXs and/or service >> providers interact with devices. >=20 > Service providers? This seems to presume that the public key = provision must go through the telco service providers? Just as one's = DNS provisioning can be independent of one's ISP, why can't one's STIR = key provision be independent of one's telco? >=20 >=20 > d/ >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net From hadriel.kaplan@oracle.com Fri Jul 26 12:29: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 C871911E80F6 for ; Fri, 26 Jul 2013 12:29:01 -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 lxcBtwWp+RtZ for ; Fri, 26 Jul 2013 12:28:55 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5397C11E8127 for ; Fri, 26 Jul 2013 12:28:54 -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 r6QJSqqb023043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 26 Jul 2013 19:28:53 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 r6QJSoJJ011189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Jul 2013 19:28:51 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 r6QJSosN011186; Fri, 26 Jul 2013 19:28:50 GMT Received: from [192.168.11.102] (/31.160.221.177) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 26 Jul 2013 12:28: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: <00C069FD01E0324C9FFCADF539701DB3BBC1DF98@EX2K10MB1.corp.yaanatech.com> Date: Fri, 26 Jul 2013 15:21:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <969CF0CD-3295-4147-8315-1A548B07EA44@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1D669@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC1DF98@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 List" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 26 Jul 2013 19:29:02 -0000 On Jul 25, 2013, at 6:33 PM, Michael Hammer = wrote: > First, you are using RFC4474 as a proxy for any type of Cert-based = system. =20 > So, I reserve the right to say that not all Cert-based systems are the = same. Not in the email I sent I didn't. Jon's email was about RFC 4474 in particular, and my response was about = it in particular. I wasn't arguing about just any random cert-based model. > You clearly have some rules/characteristics that make a "good" CA. > You do not show that a Cert-based system could not also be a good CA. > (And you know it is silly to try and prove a negative, right?) It's true I think there is a fundamental difference between the web-pki = model of trusted CAs, vs. a DANE or DKIM model where the trusted "CAs" = are the authority of domain names themselves. For CIDER, that would = apply to how it handles email-style names. For E.164-based names, it's = not as clear-cut because an E.164 is a separate namespace from domain = names. That's why I have an appendix in the CIDER draft proposing the = authority be the same. Obviously one could come up with a cert-based = model to do that as well. But RFC 4474 doesn't. > Second, let me take your statements below one by one: >=20 >> It's true that the purpose of the CIDER key index value is to let=20 >> there be multiple public keys in-use for the same E.164, but they're=20= >> all "signed" by the same "CA" - the only one truly authoritative for=20= >> the E.164 number. =20 >=20 > There is no reason that the same could not also be true for Certs. Of course. But RFC 4474 doesn't. >> But more to-the-point, it provides a way for=20 >> changing the public keys while SIP messages are in-flight. =20 >=20 > If you create a new private/public key pair while the SIP message is > in-flight, > I presume it has already been signed, so the new public key is not = usable=20 > until the SIP sender has been given the corresponding private key. Yes, although really the sender already has the new private key - I'm = not assuming a model where someone gives the sender a private key. It's = just that the sender can't use the new private key until there's = sufficient time for the system to get its public key twin spread around; = it would use the old private key for a while (like ~15 minutes or so). >=20 >> Ultimately, no matter what protocol we pick, if carriers have local=20= >> database copies then it will take some time for the public keys used=20= >> to sign SIP messages to get propagated out. =20 >=20 > Ummm, you don't sign with the public key. That would be silly, as = only the > sender could decode it. Sorry, meant private key. -hadriel From michael.hammer@yaanatech.com Fri Jul 26 13:15: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 59A2711E8114 for ; Fri, 26 Jul 2013 13:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 LEr9mEt3jIQ1 for ; Fri, 26 Jul 2013 13:15: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 7AFB411E80FB for ; Fri, 26 Jul 2013 13:15: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, 26 Jul 2013 13:15:06 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) - attack model Thread-Index: AQHOiX9KgCVNuKHctkadSPQtb2t4CJl19sgAgAHWHYD//5lBQA== Date: Fri, 26 Jul 2013 20:15:04 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC1E8F3@EX2K10MB1.corp.yaanatech.com> References: <969CF0CD-3295-4147-8315-1A548B07EA44@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1D669@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC1DF98@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.97] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0652_01CE8A1B.4983FD60" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 26 Jul 2013 20:15:18 -0000 ------=_NextPart_000_0652_01CE8A1B.4983FD60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit OK, then I take it back. I was reading too much into it. Have a good weekend. Mike -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Friday, July 26, 2013 3:21 PM To: Michael Hammer Cc: stir@ietf.org List Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) - attack model On Jul 25, 2013, at 6:33 PM, Michael Hammer wrote: > First, you are using RFC4474 as a proxy for any type of Cert-based system. > So, I reserve the right to say that not all Cert-based systems are the same. Not in the email I sent I didn't. Jon's email was about RFC 4474 in particular, and my response was about it in particular. I wasn't arguing about just any random cert-based model. > You clearly have some rules/characteristics that make a "good" CA. > You do not show that a Cert-based system could not also be a good CA. > (And you know it is silly to try and prove a negative, right?) It's true I think there is a fundamental difference between the web-pki model of trusted CAs, vs. a DANE or DKIM model where the trusted "CAs" are the authority of domain names themselves. For CIDER, that would apply to how it handles email-style names. For E.164-based names, it's not as clear-cut because an E.164 is a separate namespace from domain names. That's why I have an appendix in the CIDER draft proposing the authority be the same. Obviously one could come up with a cert-based model to do that as well. But RFC 4474 doesn't. > Second, let me take your statements below one by one: > >> It's true that the purpose of the CIDER key index value is to let >> there be multiple public keys in-use for the same E.164, but they're >> all "signed" by the same "CA" - the only one truly authoritative for >> the E.164 number. > > There is no reason that the same could not also be true for Certs. Of course. But RFC 4474 doesn't. >> But more to-the-point, it provides a way for changing the public keys >> while SIP messages are in-flight. > > If you create a new private/public key pair while the SIP message is > in-flight, I presume it has already been signed, so the new public key > is not usable until the SIP sender has been given the corresponding > private key. Yes, although really the sender already has the new private key - I'm not assuming a model where someone gives the sender a private key. It's just that the sender can't use the new private key until there's sufficient time for the system to get its public key twin spread around; it would use the old private key for a while (like ~15 minutes or so). > >> Ultimately, no matter what protocol we pick, if carriers have local >> database copies then it will take some time for the public keys used >> to sign SIP messages to get propagated out. > > Ummm, you don't sign with the public key. That would be silly, as > only the sender could decode it. Sorry, meant private key. -hadriel ------=_NextPart_000_0652_01CE8A1B.4983FD60 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcy NjIwMTUwNFowIwYJKoZIhvcNAQkEMRYEFN6XYJGh28UxCZD4Wb1k1V5gr0uxMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEALkelYqc8ZkroUBJNIy5ri2ggWANX0GSmXSbv4+GP Sb0E2cL4vZjnYE0dRUseu8L6Eo0dmGnEvnBoEAKcA7SzNIPM48RgWEbowHo8vPmqJs4/MNQijIV6 P1ddUnMM9FZtCM16HNoGegsVlW0krV0/UOOGedGTh8ySDhrH88QY/d6D0xtjefA27n7R4F4K5wSt f1l+4meo/MC1FBBdQJfXNz5mOBhUf4LUfo5ju+KTIHSLv0NLP4lIZJ/t+/e0BvJp9w1Gsv2BFWfn RZqNugA96sdgJxhRj/NE+U3YBi4RvYehXd6kzBegE7cCVZufpZg2V61k4TCqX3WWrH5OVuzowwAA AAAAAA== ------=_NextPart_000_0652_01CE8A1B.4983FD60-- From hadriel.kaplan@oracle.com Sat Jul 27 03:15: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 0768321F9DAA for ; Sat, 27 Jul 2013 03:15:30 -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 7U1P4FOZKbDp for ; Sat, 27 Jul 2013 03:15:23 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2795E21F9DA8 for ; Sat, 27 Jul 2013 03:15: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 r6RAFJsm007676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 27 Jul 2013 10:15:20 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 r6RAFHYx019831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Jul 2013 10:15:18 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 r6RAFGLB019819; Sat, 27 Jul 2013 10:15:17 GMT Received: from [192.168.11.102] (/31.160.221.177) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 27 Jul 2013 03:15:16 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Sat, 27 Jul 2013 06:15:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00C069FD01E0324C9FFCADF539701DB3BBC1A683@EX2K10MB1.corp.yaanatech.com> <6EF50BDB-3F41-49FE-83C1-20216D0D0BF0@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1BE03@EX2K10MB1.corp.yaanatech.com> <0073993E-1BC8-461C-9A7E-B5DCFC617DBF@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1C956@EX2K10MB1.corp.yaanatech.com> <011401ce87f2$75e5e880$61b1b980$@shockey.us> <51F13A8D.8070006@dcrocker.net> <98DE5818-FD12-49C4-A7E5-A92B18515F03@brianrosen.net> <51F25BDC.1020907@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 List" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 10:15:30 -0000 On Jul 26, 2013, at 10:30 AM, Brian Rosen wrote: > Okay, it's really hard to be completely technology neutral, and = actually communicate clearly. > I think that delegation of telephone numbers happen 2-8 times (that = is, there are between two and say 8 delegations of a number from the = root (national telephone number plan administration) to the thing that = places the call. > If this was some kind of cert chain, that would mean that verifying = the signing certificate could, in theory, require 7 signature = verifications, plus the actual signature itself. > It also means that prior to the call, we repeated a sequence 8 times: > a) A delegation is made > b) A public and private key pair is created > c) The private key is installed in the delegate, and the public key is = stored in some kind of database >=20 > Regardless of the technology, there is some protocol operation that = accomplishes b and c. If you think that the actual assignment of the = number (or number range) is automated, than in fact there is a protocol = for a also. >=20 > I think that the protocol needed to accomplish b and c can be used at = every level of delegation, although there isn't any real barrier to = having more than one. One of the delegations is from the national = number authority to a service provider. There could be several = instances of service provider to service provider delegation (number = resell). Another is a service provider to a PBX. Another is from the = PBX to a device, another is from either the PBX or the device to some = authorized 3rd party (the "on behalf of" case). In each case there is a = new credential and a new private/public key pair, where the private key = ends up on the delegate and the public key ends up in a database. In = each case we COULD include the actual provisioning of the number = assignment as well as assuring the private key ends up on the delegate. >=20 > Notice that I did not state HOW the private key ends up on the = delegate. I usually assume it's generated on the delegate but it could = be downloaded. > I think stir needs to define at least one protocol for b and c, and = optionally a. Right, I agree. I put together some requirements for what such a = protocol would need to do for a DNS-based model, in an appendix of the = CIDER draft. I call the new/needed protocol "CAPP" in there. The idea = was an Enterprise could use CAPP to its provider, which could use CAPP = to a carrier, which then uses CAPP to the DNS admin. > Then, if the database that holds credentials needs to be accessible = from only service providers, even if there are a significant number of = them, that may be a whole lot different from a situation where devices = need those credentials. The former is a controlled set of queriers, and = the latter is a completely public database. =20 > Okay, so back to my 8 levels of delegation. >=20 > In theory, you actually have a chain of 8 signatures. If the = database DNS, the zone is delegated to some entity. I don't think that, = so far anyway, anyone has proposed that we delegate the actual DNS zones = one telephone number at a time. All the proposals have some level of = centralized authority maintaining the actual DNS authoritative server. = That's "centralized". If the database contains certs, in theory, each = of the 8 delegates can have a separate database to hold their certs, but = we don't think that's a good idea. We really do think we should have a = smaller number of actual signers. That means that we have a = "centralized" database maintainer, and the delegations are accomplished = using this centralized service, so the cert that is used to sign is = signed by the centralized server instead of the next level up delegate. = In both cases, the content is controlled by the delegates, but the = database itself is operated by some more centralized entity >=20 > But in both cases, I don't imply "one". It might be ideal to have one = per country. I think with the DNS solution, you pretty much have to do = that if porting is allowed. With certs, you could, but you could also = allow all 8 to run their own if they insisted, or anything in between.=20= Right, and I think having a single DNS admin per country does make = sense, if they do porting anyway. Oddly, it's still possible to split = the DB up in half and give management control/responsibility to two or = three companies/admins for a country, even with porting, but it would be = logistically easier to just have one. Regardless, you'd never want to have each of the 8 delegated-chain = assignees run their own databases, if you plan for large carriers to = have a local copy of the database. I've kinda assumed we would want = that to be possible, but it's something to discuss in the WG. -hadriel From dhc@dcrocker.net Sat Jul 27 04:58: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 73D0B21F8C66 for ; Sat, 27 Jul 2013 04:58:33 -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 Fc1wp-fs+1tK for ; Sat, 27 Jul 2013 04:58:28 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 80FEE21F8C20 for ; Sat, 27 Jul 2013 04:58:28 -0700 (PDT) Received: from [10.101.1.114] ([176.12.107.140]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r6RBvheC007419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 27 Jul 2013 04:58:18 -0700 Message-ID: <51F3B5B2.6060105@dcrocker.net> Date: Sat, 27 Jul 2013 12:57:38 +0100 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: <00C069FD01E0324C9FFCADF539701DB3BBC1A683@EX2K10MB1.corp.yaanatech.com> <6EF50BDB-3F41-49FE-83C1-20216D0D0BF0@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1BE03@EX2K10MB1.corp.yaanatech.com> <0073993E-1BC8-461C-9A7E-B5DCFC617DBF@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1C956@EX2K10MB1.corp.yaanatech.com> <011401ce87f2$75e5e880$61b1b980$@shockey.us> <51F13A8D.8070006@dcrocker.net> <98DE5818-FD12-49C4-A7E5-A92B18515F03@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC1DC78@EX2K10MB1.corp.yaanatech.com> <51F25ECF.7010100@dcrocker.net> <00C069FD01E0324C9FFCADF539701DB3BBC1E2E2@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC1E2E2@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]); Sat, 27 Jul 2013 04:58:28 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) 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, 27 Jul 2013 11:58:33 -0000 On 7/26/2013 3:21 PM, Michael Hammer wrote: > Dave, > > We have a well-known mechanism with SIP, which is based on HTTP, and which > relays the INVITEs from UA through a series of proxies before reaching the > destination UA. > IMS provides more control around how that occurs. Mike, Thanks for the quick tutorial. As with any extended system effort, SIP has developed some vocabulary that is distinctive and I hadn't rather stupidly hadn't grokked that that's the model I needed to consult, for parsing the reference. (I /had/ seen the way that SIP uses the term proxy, but had forgotten. Some of this is reminiscent of growing up in O/S and Arpanet land and then running into the database world or, worse, the IBM SNA world. Totally different vocabularies, often for identical constructs.) > As this is closely related to the use of SIP for VoIP, I could see there > being a new SIP method created, > whereby the UA sends a request which is routed up the chain to a national > authority (e.g. FCC) controlled server > that would bind a new public key to the Tel# and return a signed Cert to the > requester along the same path. > The national authority and SPs in the path could cache that cert on the > return path and make available on publicly available site. > > We know how to do SIP. We know how to do Certs. Just reuse of well-known > technologies. > Just thinking aloud here. Given competing design choices, the nature and amount of development and OA&M effort probably shold affect the evaluation. While Marshall Rose was mostly correct that with enough thrust, pigs /can/ fly, thrust isn't free. If one design takes considerably less effort (smaller pig?) it tends to be easier to deploy. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From fluffy@cisco.com Sat Jul 27 06:58: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 C36DE21F8C4B for ; Sat, 27 Jul 2013 06:58:15 -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 exXtqUD4e+uH for ; Sat, 27 Jul 2013 06:58:10 -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 2C92E21F8C20 for ; Sat, 27 Jul 2013 06:58:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3795; q=dns/txt; s=iport; t=1374933490; x=1376143090; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4Mq8Ns8X46eaRqu+ybmDamIISXw+VW9hhCcC618KCXs=; b=RYxpigCSIgERBkkKJz3BnbHquF1sO2FEB9sM4Xi6/RD1Fx8u20kck2C8 aIGnMPO7+nAPuoK2aZ2AIccmSlu3g3qYlEvLdxccwn7pKwzPEWpxDlW9V S2dNN21JiUguej94Nbobnl/r4FL94VIsZeRtet0HtjkIPwrhrqGjdL5BX o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAEXR81GtJXHA/2dsb2JhbABbgwaBBb1dgRYWdIIkAQEBAwE6Hw4SBQsCAQgSBgoUEDIXDgIEDgUIiAIGuEePSgIxB4MWbwOpK4MUgio X-IronPort-AV: E=Sophos;i="4.89,757,1367971200"; d="scan'208";a="240236442" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 27 Jul 2013 13:58:09 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6RDw9wt002922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 27 Jul 2013 13:58:09 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Sat, 27 Jul 2013 08:58:09 -0500 From: "Cullen Jennings (fluffy)" To: Hadriel Kaplan Thread-Topic: [stir] Draft STIR Charter - out of band Thread-Index: AQHOitFTXCnWTMbUbEmYVrVnomoMAg== Date: Sat, 27 Jul 2013 13:58:08 +0000 Message-ID: References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> <457ED3A0-D8D1-4420-A2C3-5B07B16AE641@vigilsec.com> <8D3E41B3-6A3B-4982-8193-C975A3C867BB@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.111.139] Content-Type: text/plain; charset="us-ascii" Content-ID: <38283E2117A2BE4B907F0AEA53D97969@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF STIR Mail List Subject: Re: [stir] Draft STIR Charter - 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, 27 Jul 2013 13:58:15 -0000 On Jul 24, 2013, at 7:37 AM, Hadriel Kaplan wro= te: >=20 > On Jul 23, 2013, at 11:56 PM, Cullen Jennings (fluffy) = wrote: >=20 >>=20 >> On Jul 20, 2013, at 12:34 AM, Hadriel Kaplan = wrote: >>=20 >>> The "traditional" and regulated carriers, MSOs, etc., are the ones who = want to stop it. >>=20 >> I don't really agree with this. If this was true, the class 5 switch tha= t my ISDN trunk connects to would only allow me to assert the caller ID on = the ISDN trunk for numbers assigned to me. However, because I am the custom= er, and I like to be able to set whatever caller ID I want, and my service = provider makes me happy as a customer. Many providers in the US are very ha= ppy to provide me with a ISDN trunk that allows me to set whatever caller I= D I want. I will note this include the bulk of the large carriers with goo= d reputations, it's not just fringy operators. >>=20 >> I think the key thing is that carriers largely try and meet the needs of= their customers. And their customs are often the people that make robo cal= ls, as well as the people that receive them.=20 >=20 > I think we have a different concept of who the bad callers are. My guess= is in your definition is it's just a telemarketer. To me, "telemarketers"= are perfectly legal/legitimate callers. I don't personally want to get ca= lls from them, but that's up to a whitelist/blacklist mechanism to handle, = whether it be do-not-call lists or crowd-sourced reputation lists or whatev= er. To me, the bad guys are the guys generating bulk calls using *purposef= ully invalid* calling numbers, using Asterisk with SIP trunks to non-regula= ted providers. They're using invalid calling numbers for the purpose of mi= sleading their targets, bypassing whitelists/blacklists, etc. I truly don'= t think the regulated carriers want to have those guys as their customers. Oh no, we totally agree on who the bad guys are. But if I was deploying tha= t, I would not be using Astrix, I'd be using a minute smuggling system on t= he Cisco AVID architecture. It is really good for minute smuggling and as y= ou know I don't say that about all Cisco products.=20 >=20 > Regulated carriers allow you to assert any caller ID on an ISDN trunk bec= ause they have no real choice - they need to support the outsourced call-ce= nter and branch office call scenarios. I think we will need to agree to disagree about if they have no choice here= or not. I understand that they have no choice is the party line. In the en= d, I don't think it matters much to this conversation if you are I are rig= ht - we both agree on they don't do it and are not like to start doing it. I am very familiar with the call center and branch office scenarios.=20 > They need to let the PBX choose what caller ID to generate, on a call-by-= call basis. The carriers don't do it because they don't care - they do it = because that's the only way they could handle that use-case in ISDN/SS7/SIP= . And it worked fine for a long time. There *were* cases of fraud and abu= se of course, but the rate was so low the carrier fraud/support departments= could handle it. >=20 > Regardless, that stuff doesn't really matter. We need their help, if we = want this thing to be widely deployed and helpful/useful, for more than soc= iety's elite. I think the carriers want to help, if for no other reason th= an to avoid government mandate. (I honestly think they want to do it for be= tter reasons than that, fwiw) I agree we need their help. But to get that we need to deserve their help a= nd that requires an incentive model that makes sense for them.=20 >=20 > -hadriel >=20 From fluffy@cisco.com Sat Jul 27 06:58: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 3B0FB21F8D0D for ; Sat, 27 Jul 2013 06:58:19 -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 Un-y1TpAAmCN for ; Sat, 27 Jul 2013 06:58:14 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 77C6021F8C3E for ; Sat, 27 Jul 2013 06:58:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7529; q=dns/txt; s=iport; t=1374933494; x=1376143094; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OdcbaHqxYM1cXc8NS7rTNTDh6FIFauU7z26A401uXKE=; b=D9YJn+fPDo3AL1q4wSYZJwSZxMRx0prxd1rCgukA/xWDEPCKp0NRaoCX juRNp31OtOlINYtlnEeRDwzGzzGwSLuzLN6Uszd/v1gvrPYnltlzE/Vfd A8x+LZcRd3a9Q9anLNO6X6Z+XGBeAxWkZNhl0RBup0SOPUKdZI0N+3sp5 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAHLR81GtJV2Z/2dsb2JhbABSCYMGNVC9XYEWFnSCJAEBAQMBAQEBNzQLBQsCAQgOCgoUECcLJQIEDgUIE4dvBgypH48cjkWBBQIxB4MWbwOZCJAjgxSCKg X-IronPort-AV: E=Sophos;i="4.89,757,1367971200"; d="scan'208";a="240345199" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 27 Jul 2013 13:58:13 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6RDwDxq004787 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 27 Jul 2013 13:58:13 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Sat, 27 Jul 2013 08:58:13 -0500 From: "Cullen Jennings (fluffy)" To: Brian Rosen Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) Thread-Index: AQHOitFVPvnZzBu2Wk665Uyl43FCIQ== Date: Sat, 27 Jul 2013 13:58:12 +0000 Message-ID: References: <00C069FD01E0324C9FFCADF539701DB3BBC1A683@EX2K10MB1.corp.yaanatech.com> <6EF50BDB-3F41-49FE-83C1-20216D0D0BF0@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1BE03@EX2K10MB1.corp.yaanatech.com> <0073993E-1BC8-461C-9A7E-B5DCFC617DBF@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1C956@EX2K10MB1.corp.yaanatech.com> <011401ce87f2$75e5e880$61b1b980$@shockey.us> <51F13A8D.8070006@dcrocker.net> <98DE5818-FD12-49C4-A7E5-A92B18515F03@brianrosen.net> <51F25BDC.1020907@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.61.111.139] Content-Type: text/plain; charset="us-ascii" Content-ID: <69A676E641620F438847842027D14227@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 13:58:19 -0000 that makes a lot of sense to me. I also think a needs to be automated to en= sure that the op-ex is low enough that SP are willing to do this. On Jul 26, 2013, at 8:30 AM, Brian Rosen wrote: > Okay, it's really hard to be completely technology neutral, and actually = communicate clearly. >=20 > I think that delegation of telephone numbers happen 2-8 times (that is, t= here are between two and say 8 delegations of a number from the root (natio= nal telephone number plan administration) to the thing that places the call= . >=20 > If this was some kind of cert chain, that would mean that verifying the s= igning certificate could, in theory, require 7 signature verifications, plu= s the actual signature itself. > It also means that prior to the call, we repeated a sequence 8 times: > a) A delegation is made > b) A public and private key pair is created > c) The private key is installed in the delegate, and the public key is st= ored in some kind of database >=20 > Regardless of the technology, there is some protocol operation that accom= plishes b and c. If you think that the actual assignment of the number (or= number range) is automated, than in fact there is a protocol for a also. >=20 > I think that the protocol needed to accomplish b and c can be used at eve= ry level of delegation, although there isn't any real barrier to having mor= e than one. One of the delegations is from the national number authority t= o a service provider. There could be several instances of service provider= to service provider delegation (number resell). Another is a service prov= ider to a PBX. Another is from the PBX to a device, another is from either= the PBX or the device to some authorized 3rd party (the "on behalf of" cas= e). In each case there is a new credential and a new private/public key pa= ir, where the private key ends up on the delegate and the public key ends u= p in a database. In each case we COULD include the actual provisioning of = the number assignment as well as assuring the private key ends up on the de= legate. >=20 > Notice that I did not state HOW the private key ends up on the delegate. = I usually assume it's generated on the delegate but it could be downloaded= . >=20 > I think stir needs to define at least one protocol for b and c, and optio= nally a. >=20 >=20 >=20 > Then, if the database that holds credentials needs to be accessible from = only service providers, even if there are a significant number of them, tha= t may be a whole lot different from a situation where devices need those cr= edentials. The former is a controlled set of queriers, and the latter is a= completely public database. =20 >=20 > Okay, so back to my 8 levels of delegation. >=20 > In theory, you actually have a chain of 8 signatures. If the database D= NS, the zone is delegated to some entity. I don't think that, so far anywa= y, anyone has proposed that we delegate the actual DNS zones one telephone = number at a time. All the proposals have some level of centralized authori= ty maintaining the actual DNS authoritative server. That's "centralized". = If the database contains certs, in theory, each of the 8 delegates can ha= ve a separate database to hold their certs, but we don't think that's a goo= d idea. We really do think we should have a smaller number of actual signe= rs. That means that we have a "centralized" database maintainer, and the d= elegations are accomplished using this centralized service, so the cert tha= t is used to sign is signed by the centralized server instead of the next l= evel up delegate. In both cases, the content is controlled by the delegate= s, but the database itself is operated by some more centralized entity >=20 > But in both cases, I don't imply "one". It might be ideal to have one pe= r country. I think with the DNS solution, you pretty much have to do that = if porting is allowed. With certs, you could, but you could also allow all= 8 to run their own if they insisted, or anything in between.=20 >=20 > Brian >=20 > On Jul 26, 2013, at 7:22 AM, Dave Crocker wrote: >=20 >> On 7/25/2013 5:28 PM, Brian Rosen wrote: >>> I don't think the protocols change, >>=20 >> Sorry for my confusion. The opening text of your note that I was respon= ding to seemed to imply otherwise: >>=20 >> "I think enterprise PBXs will assert and check identity if we provide = the right tools. That would mean automated mechanisms to acquire credentia= ls. If we provided provisioning mechanisms that loaded authorized numbers = and credentials from the service provider who delegated the numbers, and we= provided an automated way for the PBX to get the public keys to verify, I = think many PBX vendors would implement that." >>=20 >> All of the above sounds to me like new mechanism, which means new techno= logy, which means new protocols. Since you say that you intend it to mean n= o new protocols, can you explain how to achieve these enhancements? >>=20 >>=20 >>> but if devices have to get >>> credentials that may be different from service providers (only) >>> needing to be able to get credentials. >>=20 >> Hmmm. That's an interesting vector. New credentials means new operatio= nal infrastructure. While it doesn't (necessarily) mean new protocols or s= oftware, it's still a significant barrier to adoption... Unless all you mea= n is the obvious increment of adding credentials for the new actors, rather= than meaning a new credential infrastructure? >>=20 >>=20 >>> I do think that a provisioning >>> protocol needs to be decided upon, and that may be selecting from >>> existing services that download the credential into the signer. >>=20 >> I thought the interesting task was /uploading/ the public key to the que= riable database. >>=20 >> Given your other comments, I guess your model is that it' the service op= erator who is dictating to the enterprise what their key will be and, there= fore, will download it to them. >>=20 >> But in any case, I suspect we have a broad agreement that the provisioni= ng mechanisms are essential and well might require development. >>=20 >>=20 >>> That >>> might, at first, be how the centralized credential services interact >>> with service providers. >>=20 >> Whenever the topic is a multi-administration, global Internet service, r= eference to its being 'centralized' does not compute for me, especially whe= n followed by a plural -- serviceS -- since it sounds contradictory. >>=20 >> Since STIR will have wide diversity -- at least involving different telc= o administration but probably also a wide range of enterprises - I do not u= nderstand what mean by centralized. Please explain. >>=20 >>=20 >>> It eventually needs to be how service >>> providers interact with PBXs, and further how PBXs and/or service >>> providers interact with devices. >>=20 >> Service providers? This seems to presume that the public key provision = must go through the telco service providers? Just as one's DNS provisioni= ng can be independent of one's ISP, why can't one's STIR key provision be i= ndependent of one's telco? >>=20 >>=20 >> d/ >>=20 >> --=20 >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From fluffy@cisco.com Sat Jul 27 06:58: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 58A5221F8CB0 for ; Sat, 27 Jul 2013 06:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.539 X-Spam-Level: X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 flmuX1NeNPuT for ; Sat, 27 Jul 2013 06:58:24 -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 A6CAB21F8D90 for ; Sat, 27 Jul 2013 06:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=706; q=dns/txt; s=iport; t=1374933503; x=1376143103; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bD+17cn6T55Sf0ym6h3KZsajNhWKyonGvXvghYi+KvQ=; b=UPBKemRC8wVg6Nr1nmAzuN1YeBkhGQuxUyRT4CuKRUsoExI9mtiWV2bb KIQ9/uT0ko5bYBMqF4HZ0qI3NBm4oO0QHirWOhHJLJlvTwPVLB/Zkiqjk WGL+m5uHMxxBDghqmQjwZGoQQSB5xfVeaegM1KFB1R+O/M9nNwYXmKz2n o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAFALfR81GtJV2a/2dsb2JhbABSCYMGgQWCSLsVgRYWdIIlAQEEOj8QAgEIIhQQMiUCBA4FCIgIuEiORYEFAjEHgxZvA6krgxSCKg X-IronPort-AV: E=Sophos;i="4.89,757,1367971200"; d="scan'208";a="237259937" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 27 Jul 2013 13:58:23 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6RDwN7g010563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 27 Jul 2013 13:58:23 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Sat, 27 Jul 2013 08:58:22 -0500 From: "Cullen Jennings (fluffy)" To: "" Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) Thread-Index: AQHOitFaPvnZzBu2Wk665Uyl43FCIQ== Date: Sat, 27 Jul 2013 13:58:21 +0000 Message-ID: References: <00C069FD01E0324C9FFCADF539701DB3BBC1A683@EX2K10MB1.corp.yaanatech.com> <6EF50BDB-3F41-49FE-83C1-20216D0D0BF0@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1BE03@EX2K10MB1.corp.yaanatech.com> <0073993E-1BC8-461C-9A7E-B5DCFC617DBF@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1C956@EX2K10MB1.corp.yaanatech.com> <011401ce87f2$75e5e880$61b1b980$@shockey.us> <51F13A8D.8070006@dcrocker.net> <98DE5818-FD12-49C4-A7E5-A92B18515F03@brianrosen.net> <51F25BDC.1020907@dcrocker.net> In-Reply-To: <51F25BDC.1020907@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.111.139] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Brian Rosen Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 13:58:30 -0000 On Jul 26, 2013, at 5:22 AM, Dave Crocker wrote: > "I think enterprise PBXs will assert and check identity if we provide = the right tools. That would mean automated mechanisms to acquire credentia= ls. If we provided provisioning mechanisms that loaded authorized numbers = and credentials from the service provider who delegated the numbers, and we= provided an automated way for the PBX to get the public keys to verify, I = think many PBX vendors would implement that." I find it easy to imagine a future where the enterprise delegates the numbe= r to the SP instead of the other way around. In some ways we already have t= hat occurring in a bunch of places.= From fluffy@cisco.com Sat Jul 27 06:58: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 905D421F8C20 for ; Sat, 27 Jul 2013 06:58:36 -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 FcZlSBAJxokt for ; Sat, 27 Jul 2013 06:58:31 -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 347C021F8C3E for ; Sat, 27 Jul 2013 06:58:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1703; q=dns/txt; s=iport; t=1374933508; x=1376143108; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zNeAjsIXDKXED4H7GwMvrFWhktmjTSlCnoesvnukZhE=; b=dkHpr1q3hCsj3DTpkPvS42AfORO31/Kht5Z+OTMXEt8Zi/RTir2w4Dko jaRJB5QgECh4J4yttjQEq4LqBouhtj//+ceo8rTZ+i33JQjvqo6GEoHjZ k9rURsffnhbUVUU8AUHk/IX0b11eZwra6PXaeIS7r72++2ScGooMy8EAx I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFALfR81GtJV2Y/2dsb2JhbABbgwaBBb1dgRYWdIIkAQEBAwE6LQ4EBQsCAQgYChQQMiUCBA4FCIgCBrhIj0oCMQeDFm8DqSuDFIFqJBw X-IronPort-AV: E=Sophos;i="4.89,757,1367971200"; d="scan'208";a="240280896" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 27 Jul 2013 13:58:19 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6RDwJgY017335 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 27 Jul 2013 13:58:19 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Sat, 27 Jul 2013 08:58:19 -0500 From: "Cullen Jennings (fluffy)" To: Hadriel Kaplan Thread-Topic: [stir] Draft STIR Charter - out of band Thread-Index: AQHOitFZCW0zEA832U+f5g5LS9Ce2Q== Date: Sat, 27 Jul 2013 13:58:19 +0000 Message-ID: References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> <457ED3A0-D8D1-4420-A2C3-5B07B16AE641@vigilsec.com> <8D3E41B3-6A3B-4982-8193-C975A3C867BB@oracle.com> In-Reply-To: <8D3E41B3-6A3B-4982-8193-C975A3C867BB@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.111.139] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF STIR Mail List Subject: Re: [stir] Draft STIR Charter - 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, 27 Jul 2013 13:58:36 -0000 On Jul 20, 2013, at 12:34 AM, Hadriel Kaplan wr= ote: >=20 > On Jul 19, 2013, at 8:12 PM, Cullen Jennings (fluffy) = wrote: >=20 >> Mobile phones could have done wideband audio long ago, but they did not.= There was no incentive for them to do it since there was no alternative th= at could do do wideband and had the same mobility properties. Then along ca= me smart phones and started providing much better audio quality using thing= s like Skype. Suddenly there was an incentive to do wideband audio on mobil= e phones and you are starting to see that deploy.=20 >=20 > OK, you think Skype is the incentive for providing wideband audio. Might= I suggest that if that were the case, that the reason it was an incentive = is because Skype represented a threat to carrier's business models? How is= Apple/Android/whatever providing out-of-band caller-id validation a threat= to a carrier's business model? If anything, it would relieve some pressur= e on the carriers. I think smart phones are a threat to fixed lines. I think over the over the= top services on smart phones are a threat to traditional mobile minutes on= smart phones. (ditto for SMS)=20 Crocker asked for an example of a place where technology A pushed technolog= y B to deploy and visa versa. I provide HD voice as an example.=20 >=20 > The "threat" right now is an FCC mandate, If I thought the only incentive for this to deploy was stick, not a carrot,= I would not bother to spend another 10 seconds on it.=20 > Carrier's aren't idiots.=20 100% agree there. I think they are incredibly in their ability to make mone= y.=20 From richard@shockey.us Mon Jul 29 00:51: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 0FDB821F9CB0 for ; Mon, 29 Jul 2013 00:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.406 X-Spam-Level: X-Spam-Status: No, score=-100.406 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 qkk4r54VWaUL for ; Mon, 29 Jul 2013 00:51:30 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id CFF7F21F9994 for ; Mon, 29 Jul 2013 00:51:29 -0700 (PDT) Received: (qmail 32331 invoked by uid 0); 29 Jul 2013 07:51:05 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy9.bluehost.com with SMTP; 29 Jul 2013 07:51: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=cyZ/A8dgXMRHvEAzY2tv5p6UtdLNTtEWtzDCxtsOBtU=; b=h/MjLo5MhDrly3eOGNGr4rG8Cba6qlsVen2y3nEVXWakvi/e6QTeevdRDecnaIDLA/ABg61fAJ4167XpuqBoeIjksjo3BHazI9cHhcoXCFWEeNcbmiyLTfbvsBJojaDP; Received: from [130.129.18.184] (port=50281 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V3iES-0006o5-AB; Mon, 29 Jul 2013 01:51:04 -0600 From: "Richard Shockey" To: "'Cullen Jennings \(fluffy\)'" , "'Hadriel Kaplan'" References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> <457ED3A0-D8D1-4420-A2C3-5B07B16AE641@vigilsec.com> <8D3E41B3-6A3B-4982-8193-C975A3C867BB@oracle.com> In-Reply-To: Date: Mon, 29 Jul 2013 03:50:56 -0400 Message-ID: <000501ce8c30$6049ef20$20ddcd60$@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: AQMHICSL0Ph6g4RQ+NeWd1GuIq7+jgID3l/wAmxQJugBDpVPmQF3LcagAw+9nYsCW3nj5wKITVPtAZLcFS8CJdWTNwD3PmWRAiSX2eEB5bu30wGvcJ0Wlj+Cg5A= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 130.129.18.184 authed with richard@shockey.us} Cc: 'IETF STIR Mail List' Subject: Re: [stir] Draft STIR Charter - 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: Mon, 29 Jul 2013 07:51:37 -0000 In line -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Cullen Jennings (fluffy) Sent: Saturday, July 27, 2013 9:58 AM To: Hadriel Kaplan Cc: IETF STIR Mail List Subject: Re: [stir] Draft STIR Charter - out of band On Jul 20, 2013, at 12:34 AM, Hadriel Kaplan wrote: > > On Jul 19, 2013, at 8:12 PM, Cullen Jennings (fluffy) wrote: > >> Mobile phones could have done wideband audio long ago, but they did not. There was no incentive for them to do it since there was no alternative that could do do wideband and had the same mobility properties. Then along came smart phones and started providing much better audio quality using things like Skype. Suddenly there was an incentive to do wideband audio on mobile phones and you are starting to see that deploy. > > OK, you think Skype is the incentive for providing wideband audio. Might I suggest that if that were the case, that the reason it was an incentive is because Skype represented a threat to carrier's business models? How is Apple/Android/whatever providing out-of-band caller-id validation a threat to a carrier's business model? If anything, it would relieve some pressure on the carriers. I think smart phones are a threat to fixed lines. I think over the over the top services on smart phones are a threat to traditional mobile minutes on smart phones. (ditto for SMS) [RS> ] The data is actually somewhat mixed in North America. There is mobile substitution in key 18-35 residential demographics but you can't ignore Enterprise-SMB where fixed lines are not declining and the number utilization data bears that out. Actually the effect of OTT on Voice and SMS in North America has stabilized since NA carriers went to One Rate national plans. As a percentage of total minutes used per sub OTT is still less than 8% after all these years ..International calling is actually different. Europe is of course totally screwed up due to their appalling roaming charges. Crocker asked for an example of a place where technology A pushed technology B to deploy and visa versa. I provide HD voice as an example. > > The "threat" right now is an FCC mandate, If I thought the only incentive for this to deploy was stick, not a carrot, I would not bother to spend another 10 seconds on it. [RS> ] Remember we do not have good data on the scope of the problem in Jurisdictions outside out of North America. The FCC/CRTC problem is in part created by their legislatures. This work is not a silver bullet only one of many different tools that are needed. I would not worry about a FCC mandate anytime soon. It takes the FCC MUCH longer to create a Report and Order than the IETF takes to issue a RFC. > Carrier's aren't idiots. 100% agree there. I think they are incredibly in their ability to make money. [RS> ] Duh .. but they do actually have CAPEX constraints and as other commenters have noted any solution has to understand some of the deployment constraints their existing architecture creates. Simple is good. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From housley@vigilsec.com Mon Jul 29 06: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 0EC3221F9477 for ; Mon, 29 Jul 2013 06:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 DtMu7fqWVZIj for ; Mon, 29 Jul 2013 06:34:27 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9B721F8E98 for ; Mon, 29 Jul 2013 06:34:27 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 609FEF2407E for ; Mon, 29 Jul 2013 09:34:48 -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 VWqdV4n18NRg for ; Mon, 29 Jul 2013 09:34:10 -0400 (EDT) Received: from dhcp-12e3.meeting.ietf.org (dhcp-12e3.meeting.ietf.org [130.129.18.227]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id D8480F2412E for ; Mon, 29 Jul 2013 09:34:45 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: <9757_1374479804_51ECE5BC_9757_151_1_B5939C6860701C49AA39C5DA5189448B0B5151@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Mon, 29 Jul 2013 09:34:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1BDA4C84-F32F-497C-9351-F1FC0C0D3B44@vigilsec.com> References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <51E094AB.4000105@dcrocker.net> <51EA95D4.905@dcrocker.net> <9757_1374479804_51ECE5BC_9757_151_1_B5939C6860701C49AA39C5DA5189448B0B5151@PEXCVZYM12.corporate.adroot.infra.ftgroup> To: IETF STIR Mail List X-Mailer: Apple Mail (2.1085) Subject: [stir] Revised STIR BOF Aganda X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 29 Jul 2013 13:34:33 -0000 Hadriel and I just had a conversation in the hallway. He really wants = to give up his speaking slot in order to create more time for charter = discussion. I have posted a revised agenda. https://datatracker.ietf.org/meeting/87/agenda/stir/ Russ From michael.hammer@yaanatech.com Mon Jul 29 08:12: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 64DDF21F9AE3 for ; Mon, 29 Jul 2013 08:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, J_CHICKENPOX_21=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 dnclZLSTmv-g for ; Mon, 29 Jul 2013 08:12: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 38AFC21F9C72 for ; Mon, 29 Jul 2013 08:12:21 -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, 29 Jul 2013 08:12:18 -0700 From: Michael Hammer To: "dcrocker@bbiw.net" Thread-Topic: [stir] CA Certs (was: Re: Rollout timeframe) Thread-Index: AQHOgvzGoW2Sqvrxc0GEvdoogk5ro5lpa5QAgAAoCgCAAe3VAIAAA5sAgAEbyACAABl1gP//jBDQgACJywD//6q3gIAA/xKAgANB3HCAALyhgP//tYrwADfEMAAADkF6MP//woOAgABwijD//7gqAIAACu6AgADzGICAAbPSgIAAHDaAgABpnKCAANaUgIAATIDAgAFMQQD//RsIMA== Date: Mon, 29 Jul 2013 15:12:17 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC1F2B3@EX2K10MB1.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC1A683@EX2K10MB1.corp.yaanatech.com> <6EF50BDB-3F41-49FE-83C1-20216D0D0BF0@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1BE03@EX2K10MB1.corp.yaanatech.com> <0073993E-1BC8-461C-9A7E-B5DCFC617DBF@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC1C956@EX2K10MB1.corp.yaanatech.com> <011401ce87f2$75e5e880$61b1b980$@shockey.us> <51F13A8D.8070006@dcrocker.net> <98DE5818-FD12-49C4-A7E5-A92B18515F03@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBC1DC78@EX2K10MB1.corp.yaanatech.com> <51F25ECF.7010100@dcrocker.net> <00C069FD01E0324C9FFCADF539701DB3BBC1E2E2@EX2K10MB1.corp.yaanatech.com> <51F3B5B2.6060105@dcrocker.net> In-Reply-To: <51F3B5B2.6060105@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.124] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00FA_01CE8C4C.7C6881F0" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 15:12:27 -0000 ------=_NextPart_000_00FA_01CE8C4C.7C6881F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sorry. I should have been more explicit from the start. When one has a hammer, everything looks like a nail. :) I think we have a few in place systems that can be leveraged. One is DNS, another is SIP, a third would be Diameter (in mobile networks). Mike -----Original Message----- From: Dave Crocker [mailto:dhc@dcrocker.net] Sent: Saturday, July 27, 2013 7:58 AM To: Michael Hammer Cc: stir@ietf.org Subject: Re: [stir] CA Certs (was: Re: Rollout timeframe) On 7/26/2013 3:21 PM, Michael Hammer wrote: > Dave, > > We have a well-known mechanism with SIP, which is based on HTTP, and > which relays the INVITEs from UA through a series of proxies before > reaching the destination UA. > IMS provides more control around how that occurs. Mike, Thanks for the quick tutorial. As with any extended system effort, SIP has developed some vocabulary that is distinctive and I hadn't rather stupidly hadn't grokked that that's the model I needed to consult, for parsing the reference. (I /had/ seen the way that SIP uses the term proxy, but had forgotten. Some of this is reminiscent of growing up in O/S and Arpanet land and then running into the database world or, worse, the IBM SNA world. Totally different vocabularies, often for identical constructs.) > As this is closely related to the use of SIP for VoIP, I could see > there being a new SIP method created, whereby the UA sends a request > which is routed up the chain to a national authority (e.g. FCC) > controlled server that would bind a new public key to the Tel# and > return a signed Cert to the requester along the same path. > The national authority and SPs in the path could cache that cert on > the return path and make available on publicly available site. > > We know how to do SIP. We know how to do Certs. Just reuse of > well-known technologies. > Just thinking aloud here. Given competing design choices, the nature and amount of development and OA&M effort probably shold affect the evaluation. While Marshall Rose was mostly correct that with enough thrust, pigs /can/ fly, thrust isn't free. If one design takes considerably less effort (smaller pig?) it tends to be easier to deploy. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ------=_NextPart_000_00FA_01CE8C4C.7C6881F0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcy OTE1MTIxN1owIwYJKoZIhvcNAQkEMRYEFIDt/q2IDFmpqea85Jrde9rpTOhtMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAI1gMr9w9y4cxZ6eyReCQ2CD3su4ny/BQoBcl4836 CsiHtwcdAkbjJn2VSrNMJ781NDtCvlb7Cs1DQHlccXjIi5S/pOTOv1KN+2azelcotCUaUD0LsD+Z v14NBB6Oy2RFR3KfcIMYhrpzbvyx1usmuvinNbNeuvDz5fWAr8Ha3RWOsh25I8OLLWmP5D38snBg MPhB9TgZIzh+Eb/5cSLFJ3eab8y1GDLhf9DwMDZn/+BPewSQIRMWBicI7AiJmL8xEmEZJRcu740J Q7HhrdBL7FqBN000CdM/Z2+BfkiLCBDSWEz0K6dP8v7H2sxB8PZXKUUnRehvCqWXU8eatObj+AAA AAAAAA== ------=_NextPart_000_00FA_01CE8C4C.7C6881F0-- From oej@edvina.net Mon Jul 29 13:32: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 AD5DE21F94DC for ; Mon, 29 Jul 2013 13:32: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=[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 Ly9AnyFYJ6uG for ; Mon, 29 Jul 2013 13:32:02 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id AF1D821F8FA1 for ; Mon, 29 Jul 2013 13:32:02 -0700 (PDT) Received: from [10.122.157.193] (unknown [217.9.101.140]) by smtp7.webway.se (Postfix) with ESMTPA id B054C93C2A1 for ; Mon, 29 Jul 2013 20:32:00 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <0DA28898-D269-459D-BEA0-F7CC70A78168@edvina.net> Date: Mon, 29 Jul 2013 22:32:02 +0200 To: "stir@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [stir] Caller ID changes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 29 Jul 2013 20:32:03 -0000 Reading the drafts I see no reference to caller ID changes during a = call.=20 See http://tools.ietf.org/html/rfc4916 Does any solution in this potential wg need to consider these mid-call = changes of a caller ID? /O= From hadriel.kaplan@oracle.com Mon Jul 29 13:55: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 8965221F964C for ; Mon, 29 Jul 2013 13:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWrp4cByW+6M for ; Mon, 29 Jul 2013 13:55:50 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id C13B221F96A8 for ; Mon, 29 Jul 2013 13:55:50 -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 r6TKtiJ6001325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 Jul 2013 20:55:45 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 r6TKthjp006503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jul 2013 20:55:44 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6TKthSF006493; Mon, 29 Jul 2013 20:55:43 GMT Received: from [166.144.91.108] (/166.144.91.108) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 29 Jul 2013 13:55:43 -0700 References: <0DA28898-D269-459D-BEA0-F7CC70A78168@edvina.net> Mime-Version: 1.0 (1.0) In-Reply-To: <0DA28898-D269-459D-BEA0-F7CC70A78168@edvina.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <29CE598B-2E28-4550-95A3-5C5EC5D0399E@oracle.com> X-Mailer: iPhone Mail (10B329) From: "hadriel.kaplan@oracle.com" Date: Mon, 29 Jul 2013 22:55:36 +0200 To: "Olle E. Johansson" X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "stir@ietf.org" Subject: Re: [stir] Caller ID changes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 29 Jul 2013 20:55:56 -0000 Yeah we basically assumed we couldn't expect Call-ID to be usable, along wit= h many other SIP headers. Sent from my iPhone On Jul 29, 2013, at 10:32 PM, "Olle E. Johansson" wrote: > Reading the drafts I see no reference to caller ID changes during a call.=20= > See http://tools.ietf.org/html/rfc4916 >=20 > Does any solution in this potential wg need to consider these mid-call cha= nges of a caller ID? >=20 > /O > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From york@isoc.org Mon Jul 29 16: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 EC88721F9DB8 for ; Mon, 29 Jul 2013 16:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ZnP7vbF1L8bY for ; Mon, 29 Jul 2013 16:08:57 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id A45D021F9DAD for ; Mon, 29 Jul 2013 16:08:57 -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.731.12; Mon, 29 Jul 2013 23:08:56 +0000 Received: from BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.198]) by BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.239]) with mapi id 15.00.0731.000; Mon, 29 Jul 2013 23:08:56 +0000 From: Dan York To: "Olle E. Johansson" , "stir@ietf.org" Thread-Topic: [stir] Caller ID changes Thread-Index: AQHOjJq0W079YrIxCEWw/T86mconDJl8aYGA Date: Mon, 29 Jul 2013 23:08:55 +0000 Message-ID: In-Reply-To: <0DA28898-D269-459D-BEA0-F7CC70A78168@edvina.net> 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-prvs: 09222B39F5 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(479174003)(24454002)(51704005)(199002)(189002)(74502001)(74876001)(56816003)(47976001)(80022001)(50986001)(74706001)(47736001)(36756003)(49866001)(69226001)(15202345003)(76786001)(16406001)(76176001)(65816001)(63696002)(77096001)(80976001)(19580395003)(19580405001)(19580385001)(83072001)(79102001)(76796001)(83322001)(59766001)(46102001)(81342001)(47446002)(77982001)(53806001)(51856001)(4396001)(74662001)(31966008)(81542001)(74366001)(54316002)(54356001)(76482001)(56776001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB065; H:BLUPR06MB067.namprd06.prod.outlook.com; CLIP:10.255.101.5; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <2A9CD6501C7E6D44B704E75468B5095D@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org Subject: Re: [stir] Caller ID changes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 29 Jul 2013 23:09:02 -0000 Olle, On 7/29/13 10:32 PM, "Olle E. Johansson" wrote: >Reading the drafts I see no reference to caller ID changes during a call. >See http://tools.ietf.org/html/rfc4916 > >Does any solution in this potential wg need to consider these mid-call >changes of a caller ID? Right now the focus is on getting out a solution as quickly as possible that solves the fundamental issue of delivering a secure caller identifier from the calling party to the recipient. I don't know that we have yet explicitly ruled a mid-call change as "out-of-scope" but I suspect we *will* do so in order to keep the focus tight and deliverable. The other aspect of RFC 4916, the ability to provide an authenticated identifier for the *called party* WAS stated to be out-of-scope in an earlier discussion on the list (and I know this because I was the one who raised the question). Again, the focus is on getting a solution that solves the one main problem and is something that can be deployed rapidly. Items like a mid-call change or identifying the called party are, in my opinion, good candidates for a "STIRbis" once the initial system is out in use. My 2 cents, Dan From oej@edvina.net Mon Jul 29 22: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 4155C21F9F9D for ; Mon, 29 Jul 2013 22:19:57 -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 PTdXyZPrIvbQ for ; Mon, 29 Jul 2013 22:19:56 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8BF21F9F5E for ; Mon, 29 Jul 2013 22:19:55 -0700 (PDT) Received: from [10.122.159.91] (unknown [217.9.101.140]) by smtp7.webway.se (Postfix) with ESMTPA id D23CC93C2A1; Tue, 30 Jul 2013 05:19:52 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 30 Jul 2013 07:19:52 +0200 Content-Transfer-Encoding: 7bit Message-Id: <4CBB987B-EA6B-4C84-A975-22B4953A482D@edvina.net> References: To: Dan York X-Mailer: Apple Mail (2.1508) Cc: "stir@ietf.org" Subject: Re: [stir] Caller ID changes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 30 Jul 2013 05:19:57 -0000 30 jul 2013 kl. 01:08 skrev Dan York : > Olle, > > > On 7/29/13 10:32 PM, "Olle E. Johansson" wrote: > >> Reading the drafts I see no reference to caller ID changes during a call. >> See http://tools.ietf.org/html/rfc4916 >> >> Does any solution in this potential wg need to consider these mid-call >> changes of a caller ID? > > Right now the focus is on getting out a solution as quickly as possible > that solves the fundamental issue of delivering a secure caller identifier > from the calling party to the recipient. I don't know that we have yet > explicitly ruled a mid-call change as "out-of-scope" but I suspect we > *will* do so in order to keep the focus tight and deliverable. > > The other aspect of RFC 4916, the ability to provide an authenticated > identifier for the *called party* WAS stated to be out-of-scope in an > earlier discussion on the list (and I know this because I was the one who > raised the question). Again, the focus is on getting a solution that > solves the one main problem and is something that can be deployed rapidly. > > Items like a mid-call change or identifying the called party are, in my > opinion, good candidates for a "STIRbis" once the initial system is out in > use. > Isn't there a risk that you will get a call and as soon as the call is answered, there will be a caller ID update sent to make it harder to call back? The traces will of course be showing both caller IDs, but the users will still be annoyed. I don't really know how widely updates are supported by providers and I guess this is different by country. I do know that Asterisk supports this in a number of ways, but not RFC4916-style, because of requirements from Germany. /O From alexander.mayrhofer@nic.at Mon Jul 29 23:19: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 4E09821F9FE4 for ; Mon, 29 Jul 2013 23:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.43 X-Spam-Level: X-Spam-Status: No, score=-9.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otocidGd8cls for ; Mon, 29 Jul 2013 23:19:27 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 132BE21F9E34 for ; Mon, 29 Jul 2013 23:19:27 -0700 (PDT) Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.49 ; Tue, 30 Jul 2013 08:19:19 +0200 Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0123.003; Tue, 30 Jul 2013 08:19:17 +0200 From: Alexander Mayrhofer To: "stir@ietf.org" Thread-Topic: Some older related work... Thread-Index: Ac6M7G33ocZ8jH6rTzGWLenqfQ69OA== Date: Tue, 30 Jul 2013 06:19:17 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE0750A2B8360@NICS-EXCH2.sbg.nic.at> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Subject: [stir] Some older related work... X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 30 Jul 2013 06:19:33 -0000 fyi, some years ago i wrote a draft about combining ENUM and DKIM technology in = order to verify telephone number based identities. I'm far from claiming th= at this could solve the (yet to be defined) problem, but maybe some of the = ideas are useful: http://tools.ietf.org/html/draft-mayrhofer-enum-domainkeys-00 Also, we did contemplate often enough about using the validation architectu= re [RFC4725] and the validation token [RFC5105] for purposes outside of the= "pure" ENUM registration - essentially, the validation token is data to as= sert identity of a phone number - and that might be useful in the stir envi= ronment. Alex [and i can see Richard Shockey rolling his eyes] ;-) From eburger@standardstrack.com Mon Jul 29 23:39: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 68B6D21F9F3A for ; Mon, 29 Jul 2013 23:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.889 X-Spam-Level: X-Spam-Status: No, score=-98.889 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_50=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 OsBQvIrwMpaU for ; Mon, 29 Jul 2013 23:39:41 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7B221F93D4 for ; Mon, 29 Jul 2013 23:39:41 -0700 (PDT) Received: from dhcp-64e7.meeting.ietf.org ([130.129.100.231]:50572) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1V43am-0001Cn-5H for stir@ietf.org; Mon, 29 Jul 2013 23:39:32 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_91B3FD28-C295-4269-A3D4-525858D98C07"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <28F711CA-9A31-4276-920B-AF2E561A4B92@standardstrack.com> Date: Tue, 30 Jul 2013 08:39:32 +0200 To: stir@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Subject: [stir] Performance X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 30 Jul 2013 06:39:47 -0000 --Apple-Mail=_91B3FD28-C295-4269-A3D4-525858D98C07 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii One thing I do not see in the charter discussions or the drafts are any = performance requirements. For example, I can well imagine some of the = out-of-band proposals adding seconds to call setup time. Given that one = of the drivers for the work is swatting, this means a big use case of = the solution will be for emergency services. In that environment, = seconds count in an absolute sense. =46rom a user experience = perspective, listening to seconds of digital silence when calling a PSAP = is inviting the caller to hang up and try again. That is not a good use = of resources, and may result in more dead people. Regulators do not like = to be responsible for that, which means we may see "less than ideal" = solutions imposed on us.= --Apple-Mail=_91B3FD28-C295-4269-A3D4-525858D98C07 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEC4QaCuZOyyOuQvrDyAdNqkwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTIwOTA5MDAwMDAwWhcNMTMwOTA5MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxS9AnBs87HgW3Q2Io8htINc6e4Lv7MkYAJ0h9KFHAvNAbW7ivyaont2K5g5OST 2uWwtVxrjDEG55yF04AvcoPdzvrq9mfaKPvC4sAPfFgG2soXNsqWG40Cz0DQZWZjzxt+ExjrClSV SZgafLDB2TTLH2VWC+p75W7LSJYZHwyCR4EmPYCA4uqobVlnSdGU/l3aECqMtK6ILnos+NJf7vup hK+MP7vF+TKSOEc+F1yXAhX9PH5NvIWi0zRzxsj8XjNZCNtjyFMv17clSJut7Wl1ZpWQGpFfkKj7 nggX7pbohyxp2SB4EPv+taKhqE6uk93DL0gWHQ9jj6gR8O3ZTZMCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQJETe7AM8n/jUXTbMmfHnn8Iot 2TAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAS82ejMSWOOIarMLSo u0nanSBhJWv9QT8YfXKPUB54uxYoFk06rNEMxIdL8uYG43pleqinkWV3faaTBnkApl7pja9448UG 61uGjQNWUsNzre3QytO880MeJCUwfAP+/E6hOlCSlWR1x594RJjMXxL0BXBl2IeDNzi3beg9YSRo ZeHYLmVNI0llFDcNvmodtNAXCSDd2Zbo3nw9xKs+ACV0hzdoUy2dxgJylIVqQbWcOPhiM+YshCcm Kgq096UABXMn2D2r5Hg5w5R6SB3PZT4CxVOwMFPeVEyr72YYFwFQYUd9XgsYTxxtrXq4vK7kJ8AT xxxGP6xWxvAGPGN0NxaCMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNzMwMDYzOTMyWjAjBgkqhkiG9w0BCQQxFgQU ebbPEd2sEx0/Ge9izGZ8Zy6t3tYwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQLhBoK5k7LI65C+sPIB02qTCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkw DQYJKoZIhvcNAQEBBQAEggEAU80rkyxU+eaGodvT7arF872b9oC55vaP7RQJ2JNZ+GrGDWZwttQB lfLsNdAQwo4MwAIYUrOA22qVFwkyERKl/YWTyv8i+8lig5wwIhlsRKPISg783euLsPKUjvmXtnwY 0EfJSbL/HsBvqTxRe/Vt6H1/r6/o591yN7J/GMdcuYShRiC3hMzMlU+NUdHz0kKAkZW1Moa/xmuZ OH/mfQbAm3RHDXJiKbyfDsnX1ZBNHhoD57i3ipN821z4cE8D/zi6v/wzrqWvLPs+9L+81dqzNAJ3 FPZoTfG81eyISv8QDnZUiXMSJRzRVr/cu7u/e9xOayOBNjbBtiZUS0WMY/RwigAAAAAAAA== --Apple-Mail=_91B3FD28-C295-4269-A3D4-525858D98C07-- From jan-tilo.kirchhoff@aastra.com Tue Jul 30 00:53: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 9F13C11E81D9 for ; Tue, 30 Jul 2013 00:53:12 -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 YM5LANCIaVkz for ; Tue, 30 Jul 2013 00:53:05 -0700 (PDT) Received: from demail.aastra.com (demail.aastra.com [194.115.52.20]) by ietfa.amsl.com (Postfix) with ESMTP id 27D5111E80F4 for ; Tue, 30 Jul 2013 00:53:03 -0700 (PDT) Received: from bermail01.de.aastra.com ([10.103.2.18]) by demail.aastra.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Jul 2013 09:53:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Jul 2013 09:53:01 +0200 Message-ID: <349B0B00C541E84B938C21B94117075C0186114E@bermail01.de.aastra.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [stir] Draft STIR Charter - out of band Thread-Index: Ac6M+dB40JleUlz1SoacLlUVmjIrBQ== References: <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz><51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net><30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz><432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com><51E080BB.2060403@dcrocker.net><51E094AB.4000105@dcrocker.net><457ED3A0-D8D1-4420-A2C3-5B07B16AE641@vigilsec.com><8D3E41B3-6A3B-4982-8193-C975A3C867BB@oracle.com> From: "Jan-Tilo Kirchhoff" To: "Cullen Jennings (fluffy)" , "Hadriel Kaplan" X-OriginalArrivalTime: 30 Jul 2013 07:53:01.0929 (UTC) FILETIME=[D0DE2D90:01CE8CF9] Cc: IETF STIR Mail List Subject: Re: [stir] Draft STIR Charter - 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: Tue, 30 Jul 2013 07:53:13 -0000 > -----Urspr=FCngliche Nachricht----- > Von: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com] > Gesendet: Samstag, 27. Juli 2013 15:58 > An: Hadriel Kaplan > Cc: IETF STIR Mail List > Betreff: Re: [stir] Draft STIR Charter - out of band >=20 >=20 > On Jul 24, 2013, at 7:37 AM, Hadriel Kaplan = > wrote: >=20 > > > > On Jul 23, 2013, at 11:56 PM, Cullen Jennings (fluffy) > wrote: > > > >> > >> On Jul 20, 2013, at 12:34 AM, Hadriel Kaplan > wrote: > >> > >>> The "traditional" and regulated carriers, MSOs, etc., are the ones > who want to stop it. > >> > >> I don't really agree with this. If this was true, the class 5 = switch > that my ISDN trunk connects to would only allow me to assert the = caller > ID on the ISDN trunk for numbers assigned to me. However, because I am > the customer, and I like to be able to set whatever caller ID I want, > and my service provider makes me happy as a customer. Many providers = in > the US are very happy to provide me with a ISDN trunk that allows me = to > set whatever caller ID I want. I will note this include the bulk of > the large carriers with good reputations, it's not just fringy > operators. > >> > >> I think the key thing is that carriers largely try and meet the > needs of their customers. And their customs are often the people that > make robo calls, as well as the people that receive them. > > > > I think we have a different concept of who the bad callers are. My > guess is in your definition is it's just a telemarketer. To me, > "telemarketers" are perfectly legal/legitimate callers. I don't > personally want to get calls from them, but that's up to a > whitelist/blacklist mechanism to handle, whether it be do-not-call > lists or crowd-sourced reputation lists or whatever. To me, the bad > guys are the guys generating bulk calls using *purposefully invalid* > calling numbers, using Asterisk with SIP trunks to non-regulated > providers. They're using invalid calling numbers for the purpose of > misleading their targets, bypassing whitelists/blacklists, etc. I > truly don't think the regulated carriers want to have those guys as > their customers. >=20 > Oh no, we totally agree on who the bad guys are. But if I was = deploying > that, I would not be using Astrix, I'd be using a minute smuggling > system on the Cisco AVID architecture. It is really good for minute > smuggling and as you know I don't say that about all Cisco products. >=20 > > > > Regulated carriers allow you to assert any caller ID on an ISDN = trunk > because they have no real choice - they need to support the outsourced > call-center and branch office call scenarios. >=20 > I think we will need to agree to disagree about if they have no choice > here or not. I understand that they have no choice is the party line. > In the end, I don't think it matters much to this conversation if you > are I are right - we both agree on they don't do it and are not like = to > start doing it. >=20 > I am very familiar with the call center and branch office scenarios. >=20 > > They need to let the PBX choose what caller ID to generate, on a > call-by-call basis. The carriers don't do it because they don't care = - > they do it because that's the only way they could handle that use-case > in ISDN/SS7/SIP. And it worked fine for a long time. There *were* > cases of fraud and abuse of course, but the rate was so low the = carrier > fraud/support departments could handle it. Actually from my experience with ISDN and Telcos in Germany when a user=20 has activate this feature (often referred to as "CLIP No Screening") the = original calling line ID is transmitted inside the carrier network and=20 sometimes even send to the destination as a secondary ID. The difference = is in the protocol elements used and the presentation and screening=20 indicators. If you're interested I will look up the details in the ETSI=20 standards.=20 Actually I believe that transmission of the "real" number (screened /=20 asserted by the carrier network) is mandatory. Emergency services, = police=20 etc. will always have access to this information, no matter what you = send. > > > > Regardless, that stuff doesn't really matter. We need their help, = if > we want this thing to be widely deployed and helpful/useful, for more > than society's elite. I think the carriers want to help, if for no > other reason than to avoid government mandate. (I honestly think they > want to do it for better reasons than that, fwiw) >=20 > I agree we need their help. But to get that we need to deserve their > help and that requires an incentive model that makes sense for them. >=20 > > > > -hadriel > > >=20 Regards, Tilo -- Dipl. Ing. Jan-Tilo Kirchhoff=A0=A0=A0=20 Portfoliomanagement BluStar, OpenCom & SIP Products Aastra Deutschland=A0GmbH Zeughofstr. 1 10997 Berlin =B7 Germany jan-tilo.kirchhoff@aastra.com www.aastra.de =A0 Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg HRB 37998 Gesch=E4ftsf=FChrer: J=FCrgen Signer, Anthony Shen From hannes.tschofenig@gmx.net Tue Jul 30 00:54: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 CA34A21F9AAE for ; Tue, 30 Jul 2013 00:54: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=[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 yiopXxE0XzqP for ; Tue, 30 Jul 2013 00:54:16 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id B30F511E81D9 for ; Tue, 30 Jul 2013 00:54:10 -0700 (PDT) Received: from dhcp-13ba.meeting.ietf.org ([130.129.19.186]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M5tzh-1UAre42dx3-00xqur for ; Tue, 30 Jul 2013 09:54:09 +0200 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <28F711CA-9A31-4276-920B-AF2E561A4B92@standardstrack.com> Date: Tue, 30 Jul 2013 09:54:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5E487D45-8161-4744-9B7D-D84D8BB2DC55@gmx.net> References: <28F711CA-9A31-4276-920B-AF2E561A4B92@standardstrack.com> To: Eric Burger X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Provags-ID: V03:K0:q32N/8FqFW1ztDNxqnjK4c2U/GsCc2svsDhZrOn6RLGNPZdd/5g Zd8GkZLVEw4b8uddSGnNEnrmx5bm5vXrXaR6FNvCm3okRCfzruXYYJYEy1TGWGfNguSs8cJ T49oSAlorh4+hyS3FL/y7w/yDcVcyyV1eHYwfPyTTMSaberbUTLwLhJ/rhA9eGKRPewr281 Junz3R/5p+izYEJ9bO/6A== Cc: stir@ietf.org, Hannes Tschofenig Subject: Re: [stir] Performance X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 30 Jul 2013 07:54:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Eric, please have a look at this document when it comes to attacks against the = emergency infrastructure: http://tools.ietf.org/html/draft-ietf-ecrit-trustworthy-location-06 A feature of the emergency services infrastructure is that you do not = want to reject incoming calls. For swatting the problem is that the = location retrieval process uses a form of the calling number as input to = the location determination process. The calling party identity is = therefore more useful there for an analysis after an attack. Ciao Hannes On Jul 30, 2013, at 8:39 AM, Eric Burger wrote: > One thing I do not see in the charter discussions or the drafts are = any performance requirements. For example, I can well imagine some of = the out-of-band proposals adding seconds to call setup time. Given that = one of the drivers for the work is swatting, this means a big use case = of the solution will be for emergency services. In that environment, = seconds count in an absolute sense. =46rom a user experience = perspective, listening to seconds of digital silence when calling a PSAP = is inviting the caller to hang up and try again. That is not a good use = of resources, and may result in more dead people. Regulators do not like = to be responsible for that, which means we may see "less than ideal" = solutions imposed on us._______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR93EgAAoJEGhJURNOOiAt9l0H/iFTSST7jEY1iYQA0X2VVZLy om2ROF17zXbwy/NUwDkAdrOGeQTEgcXgIJkqOhLeqRG4ZvHQVWXO2soF3TwyS4BZ acsF/nPr32WsXUUQgsbezopHasnAjVH6n/0nl0K9h590JKc8pEyxCh8wrc5jeI/b BIXpqLjH/IIdgqrIwZJYzYZP1DJtQcekNp9KwUBMDdryABPsjCWd/RbbPOSaZiA7 dVrdsMDy6Osr/0CeEqUZG/I2qZvrocB86NkYpSjROhEr9Y864tBJEuhJ5zLS8Go3 6mPPSwShNGvnMOmJhr+JRU5cLg4e762ZNGl3br6p+Vns2WV67Ve6nHU5PA8stQU=3D =3DlnmX -----END PGP SIGNATURE----- From Hannes.Tschofenig@gmx.net Tue Jul 30 02:18: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 B722321E810C for ; Tue, 30 Jul 2013 02:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vKQN31ljGfx for ; Tue, 30 Jul 2013 02:18:35 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD0821F86BE for ; Tue, 30 Jul 2013 02:16:11 -0700 (PDT) Received: from dhcp-13ba.meeting.ietf.org ([130.129.19.186]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Mc9U3-1UkdkD2KGd-00JYjj for ; Tue, 30 Jul 2013 11:16:10 +0200 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Jul 2013 11:16:08 +0200 Message-Id: To: stir@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Provags-ID: V03:K0:4vIUV/BeE4JYuIa9nhjbsIfeKA2vuWRzNQfWGC6lpukZ3//RIWs sjXQiyZHasvsu6xRBAML8SwVJk8HMMgvERdpIaaFAmI3DBHGr6/z6zxf5k2FEdBAI0kAG60 dqgGeOyp8wEJkHzjRbknJ5RYtPzC4KFD8Egc4kPEl/sjK8ZU3y9kiZpv5Y5I+9fmVdqbXRf SuQ2U56Xk0w227W9meuFQ== Cc: Hannes Tschofenig Subject: [stir] Emergency Services Specific Threats X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 30 Jul 2013 09:18:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi all,=20 Stephen Kent during the STIR BOF asked about more details about threat = descriptions.=20 In addition to the problem statement document there is also a document = we worked on in ECRIT, which will go into WGLC soon: http://tools.ietf.org/html/draft-ietf-ecrit-trustworthy-location-06 The document not only focuses on caller identity but also on location = aspects, which may also be faked.=20 In any case, the ECRIT WG and the authors would appreciate feedback.=20 Ciao Hannes -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR94RZAAoJEGhJURNOOiAtAOYH/jIT1dgjc87rSYE7r2hWfNcX 3vr8TKVakaQnBOmfHg3yanKhKgr+iEs64T2rT7C5QHg0oux/rOCx9UahWByKjFG3 ZnilLMKGjDOOFYti3WmtpJKDFG6041nFVxN7Ao9fIdp6spzBS65PzR+MMXwVNvl+ SajwzbQ0he0e/z4LP4AQVWxNeSZyk/DE2quv2XhEgA8KpNtg1vzIj4qLfbMpDNAa /Ee91nxak+KIZQOqSHzJePjbgkI+/Tn4+4oeXkGLpXTo7/TbMpbuOasJqUmlOmDg calpbZgqxfaICl+qiZX5B4PQwTsM67zgdCbJEGOqDN3fB7DBn/JRx/RXJ9V9eGY=3D =3D7M9+ -----END PGP SIGNATURE----- From D.Hancock@CableLabs.com Tue Jul 30 07:53: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 79ABF11E81FB for ; Tue, 30 Jul 2013 07:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rSNdAZF6XFw for ; Tue, 30 Jul 2013 07:53:38 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id EDCBE21F9CC8 for ; Tue, 30 Jul 2013 07:53:35 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r6UErYEG024353; Tue, 30 Jul 2013 08:53:34 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 30 Jul 2013 08:53:34 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0146.000; Tue, 30 Jul 2013 08:53:34 -0600 From: David Hancock To: Hadriel Kaplan , IETF STIR Mail List Thread-Topic: [stir] DNS for STIR: draft-kaplan-stir-cider-00.txt Thread-Index: AQHOgbgLxBUOT27mGUu4WhfE7jsXGZl9Za+A Date: Tue, 30 Jul 2013 14:53:33 +0000 Message-ID: In-Reply-To: <26F54E95-70CF-4FC9-BC6C-C4372E906F73@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="us-ascii" Content-ID: <56C3C41293E67B4BAB4F4F64883579D4@cablelabs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [stir] DNS for STIR: draft-kaplan-stir-cider-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 14:53:42 -0000 Hi Hadriel, I read your draft today, oh boy. Generally looks good. I do have one question - how would it support the case where the same caller-ID needs to be signed by multiple service providers? For example, say an enterprise has multiple branch offices across multiple service providers, and it wants calls initiated by all branches to deliver the same 800 number. Would you distribute the private key to all service providers (not particularly private)? Thanks David On 7/15/13 6:04 PM, "Hadriel Kaplan" wrote: > >Howdy, >I've submitted a draft for how a DNS model could work for STIR, named >"CIDER". >It still needs to ferment a bit, but it should provide the general flavor >of a DNS solution. > >Comments/questions/flames welcomed. > >-hadriel > > >Begin forwarded message: > >> A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >>=20 >>=20 >> Title : A proposal for Caller Identity in a DNS-based >>Entrusted Registry (CIDER) >> Author(s) : Hadriel Kaplan >> Filename : draft-kaplan-stir-cider-00.txt >> Pages : 25 >> Date : 2013-07-15 >>=20 >> Abstract: >> This document describes a proposal for providing a database service >> for authentication information for Caller-ID E.164 numbers, >> nationally-specific number codes, and email-style names used in >> communication requests (such as call setup, instant messages). The >> model proposed uses a DNS service as a Registry for cryptographic >> public-keys. The database service solution is called CIDER. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-kaplan-stir-cider >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-kaplan-stir-cider-00 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Tue Jul 30 12:30: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 95FF321F9AB4 for ; Tue, 30 Jul 2013 12:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJ801narKD8d for ; Tue, 30 Jul 2013 12:30:10 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id B06D321E80C1 for ; Tue, 30 Jul 2013 12:30:09 -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 r6UJU4C6031637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Jul 2013 19:30: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 r6UJU0jl005966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jul 2013 19:30:02 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 r6UJU0dw007432; Tue, 30 Jul 2013 19:30:00 GMT Received: from [10.13.52.191] (/217.194.78.58) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 30 Jul 2013 12:30: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, 30 Jul 2013 15:29:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: David Hancock X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: IETF STIR Mail List Subject: Re: [stir] DNS for STIR: draft-kaplan-stir-cider-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 19:30:21 -0000 On Jul 30, 2013, at 10:53 AM, David Hancock = wrote: > Hi Hadriel, >=20 > I read your draft today, oh boy. >=20 > Generally looks good. I do have one question - how would it support = the > case where the same caller-ID needs to be signed by multiple service > providers? For example, say an enterprise has multiple branch offices > across multiple service providers, and it wants calls initiated by all > branches to deliver the same 800 number. Would you distribute the = private > key to all service providers (not particularly private)? Just to be clear, the *private* key isn't distributed in CIDER - the = *public* key is uploaded to the DNS admin, but the private key remains = private; and there can be multiple public keys for the same E.164 phone = number. Even in the case of an Enterprise PBX wanting to sign its own = SIP messages, the PBX generates its own private/public key combo, keeps = its private key to itself, and uploads the public key to the service = provider who then uploads it into the DNS admin for the E.164 - in such = a case there might be two or more public keys in the DNS for the same = E.164 phone number, but under different "key index" names and thus = separate TXT RR entries. So in the case of an Enterprise with multiple branch offices connected = to different service providers: one service provider is the "CIDER = Assignee" for the 1-800 number - likely whichever one is the DID = terminating carrier for it. It's the assigned entity that can upload = public keys into the DNS admin's entry space for that 1-800 number. How = the other entities upload their public keys through the Assignee for the = same number into CIDER is basically an administrative decision and not = constrained by the CIDER solution. The branches could upload their = public keys to the Enterprise HQ, which uploads it to the Assignee = service provider, which uploads them to CIDER; or the other branch's = service providers could upload public keys to the Enterprise, or to the = Assignee service provider, etc. It's not something we have to dictate, = as the service provider can choose for itself (or the national = regulators can, or whatever). Even the physical process of uploading it = isn't actually defined in CIDER draft - you could use email, fax, a = web-portal, or whatever. The CIDER draft does however recommend a new = protocol be created for that purpose, called CAPP, and gives some = requirements for such in Appendix B. -hadriel From housley@vigilsec.com Wed Jul 31 07:25: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 8068421E811D for ; Wed, 31 Jul 2013 07:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.695 X-Spam-Level: X-Spam-Status: No, score=-102.695 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMe7c5-P8y1z for ; Wed, 31 Jul 2013 07:25:23 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 1A98A11E81A6 for ; Wed, 31 Jul 2013 07:25:21 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 93A5BF2408E for ; Wed, 31 Jul 2013 10:25:28 -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 ItVMLXYBV6dw for ; Wed, 31 Jul 2013 10:25:04 -0400 (EDT) Received: from dhcp-540a.meeting.ietf.org (dhcp-540a.meeting.ietf.org [130.129.84.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 8EBE6F24086 for ; Wed, 31 Jul 2013 10:25:22 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Jul 2013 10:25:08 -0400 Message-Id: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> To: IETF STIR Mail List Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 14:25:34 -0000 With the BOF behind us, I think there is one, and only one topic that = this mail list should be discussing. That is the charter text that is = ready for the IESG. The pre-BOF charter text is here: = http://www.ietf.org/charter/charter-ietf-stir-00-00.txt I will hold the pen on changes to the charter text. Some people = suggested changes during the BOF: Preamble - Remove "deployable" or change it to "rapidly deployable" - Add "within call set up time" - Add a discussion of a threat model - Be clear that the "calling party" is identified by their telephone = number Postamble - Can something be said about alignment of incentives? Privacy - We need to do more than punt. Please propose exact text for any of these topics. I prefer one = proposed change per message in a hope to more easily judge consensus. = To this end, I will start a thread on the inclusion of an out-of-band = mechanism. Russ From housley@vigilsec.com Wed Jul 31 08:22: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 DC6B921F9E3A for ; Wed, 31 Jul 2013 08:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.691 X-Spam-Level: X-Spam-Status: No, score=-102.691 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fjv7SHmxGG8o for ; Wed, 31 Jul 2013 08:22:38 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id C477C21F9E6C for ; Wed, 31 Jul 2013 08:22:37 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 3581CF24083 for ; Wed, 31 Jul 2013 11:22:47 -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 Xf1gAwkZopbT for ; Wed, 31 Jul 2013 11:22:26 -0400 (EDT) Received: from dhcp-45a2.meeting.ietf.org (dhcp-45a2.meeting.ietf.org [130.129.69.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 4A15FF24038 for ; Wed, 31 Jul 2013 11:22:45 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> Date: Wed, 31 Jul 2013 11:22:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> To: IETF STIR Mail List X-Mailer: Apple Mail (2.1085) Subject: [stir] Including out-of-band in the Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 15:22:45 -0000 No one spoke against including an in-band mechanism in the charter. So, = it is clearly in the charter. We need to decide whether an out-of-band = mechanism is included as well. Many people spoke for including an out-of-band mechanism in the charter. = And, many people spoke against it. Here is my view of the hums that were taken at the end of the BOF ... First Hum: in-band only, out-of-band only, in-band then out-of-band, = and in-band and out-of-band together - there was no support for out-of-band only - there was roughly equal support for the other three options Second hum: could live with in-band and out-of-band in the charter - significant response Third hum: can't live in-band and out-of-band in the charter - a few people trying to make a lot of noise Since the BOF, I tried to talk to people that spoke against inclusion of = an out-of-band mechanism in the charter. I was not able to find = everyone, but I did find many. The majority of these people can live = with an out-of-band mechanism in the charter.=20 So, I suggest that we leave this aspect of the charter alone. That is, = the proposed WG will deliver an in-band mechanism first, and then = deliver an out-of-band mechanism. Notice that this does not prevent the = WG from working on them at the same time, but ti does speak directly to = the order that they will be sent to the IESG. Thoughts? Russ From kent@bbn.com Wed Jul 31 08:28: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 D679A21F9F9A for ; Wed, 31 Jul 2013 08:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.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 xG6iehEt42o0 for ; Wed, 31 Jul 2013 08:28:11 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 07D5D21F9FF1 for ; Wed, 31 Jul 2013 08:28:01 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:58221 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V4YJC-000IVy-2K for stir@ietf.org; Wed, 31 Jul 2013 11:27:26 -0400 Message-ID: <51F92CDD.4030306@bbn.com> Date: Wed, 31 Jul 2013 11:27:25 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: stir@ietf.org References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> In-Reply-To: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 15:28:26 -0000 Russ, As I mentioned at the mic, I'd like to see both a threat model and a privacy analysis as deliverables early in this process. I also think we need to have a discussion about the size of the population of calling parties who will have credentials, and the size of the verifiers in the system. This seemed to be the source of some disagreement during the BoF, and some proposals that might work well for small values of either (or both) of these parameters might not work well for very large values of these parameters. The texts says: As its first work item, the working group will specify a SIP header-based authorization mechanism to verify the originator of a SIP session is authorized to use the claimed source telephone number, Should the "authorization" be "authentication" above. I agree with the use of "authorized" in the latter part of the sentence. later, the text says: After completing the in-band mechanism, the working group will consider session establishment where there are one or more non-SIP hops, most likely using an out-of-band authorization mechanism. Did you mean authorization or authentication here? Steve From fluffy@cisco.com Wed Jul 31 08:33: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 87BB121F9C78 for ; Wed, 31 Jul 2013 08:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.549 X-Spam-Level: X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 Z7PKo96AM-CE for ; Wed, 31 Jul 2013 08:33:44 -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 969B921F9B18 for ; Wed, 31 Jul 2013 08:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1657; q=dns/txt; s=iport; t=1375284825; x=1376494425; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4hszNZTsB4POgeu6sbqnekBwJ+bhmzLELd6547lYM+8=; b=itHJryVvl8MKo7sS4dSuF+fjtX+bufzAaY0zaUPV3ozihQig17KUpbhX pjp9IIGsXvpCHed45uvYBx5CL30cJcy4TBk8OhtYueNTihFuKmNj8jmtK KAHGQRelKoJkMTV5NCPci58YGinV6M+J72yLvPTkB0T5Y21nsKEer+wPd s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAFEt+VGtJXHB/2dsb2JhbABbgwaBBb4dgRgWdIIkAQEBAwE6PxACAQgiFBAyJQIEDgUIiAIGuQiPVAIxB4MYcwOUCJUkgxSCKg X-IronPort-AV: E=Sophos;i="4.89,788,1367971200"; d="scan'208";a="238810669" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 31 Jul 2013 15:33:44 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6VFXhMC011961 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 15:33:43 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 10:33:43 -0500 From: "Cullen Jennings (fluffy)" To: Russ Housley Thread-Topic: [stir] Including out-of-band in the Charter Thread-Index: AQHOjgHW5Ama/y8+i0aOqZRCUeFoTZl/PnuA Date: Wed, 31 Jul 2013 15:33:43 +0000 Message-ID: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.109.66] Content-Type: text/plain; charset="us-ascii" Content-ID: <8F782FD8A1A8E8409538BCAA2BF7D30B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF STIR Mail List Subject: Re: [stir] Including out-of-band in the Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 15:33:51 -0000 On Jul 31, 2013, at 5:22 PM, Russ Housley wrote: >=20 > No one spoke against including an in-band mechanism in the charter. So, = it is clearly in the charter. We need to decide whether an out-of-band mec= hanism is included as well. >=20 > Many people spoke for including an out-of-band mechanism in the charter. = And, many people spoke against it. >=20 > Here is my view of the hums that were taken at the end of the BOF ... >=20 > First Hum: in-band only, out-of-band only, in-band then out-of-band, and= in-band and out-of-band together > - there was no support for out-of-band only > - there was roughly equal support for the other three options >=20 > Second hum: could live with in-band and out-of-band in the charter > - significant response >=20 > Third hum: can't live in-band and out-of-band in the charter > - a few people trying to make a lot of noise >=20 > Since the BOF, I tried to talk to people that spoke against inclusion of = an out-of-band mechanism in the charter. I was not able to find everyone, = but I did find many. The majority of these people can live with an out-of-= band mechanism in the charter.=20 >=20 > So, I suggest that we leave this aspect of the charter alone. That is, t= he proposed WG will deliver an in-band mechanism first, and then deliver an= out-of-band mechanism. Notice that this does not prevent the WG from work= ing on them at the same time, but ti does speak directly to the order that = they will be sent to the IESG. >=20 > Thoughts? Given the urgency to move forward with this work, I can live with this.=20 Cullen From ekr@rtfm.com Wed Jul 31 08:50:13 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0CD21F9FC8 for ; Wed, 31 Jul 2013 08:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.450, 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 uuLwa0nAfsXe for ; Wed, 31 Jul 2013 08:50:09 -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 E5BC821F9C78 for ; Wed, 31 Jul 2013 08:50:08 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id 9so472330qea.35 for ; Wed, 31 Jul 2013 08:50:06 -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=vaNhgGNc6W+M+kxp+HqyMhMAJwZaX3NXbm8uifYLeAE=; b=U7zx/LKib3tOxsjbamP7ox2ngYlC8qDgJVGELb4c32++PmBDRAHcR1vaPznPHKEa99 N7Ph2DBoBhaHwQMO9CLFj/7Mr5KIn48SE0BGjPEPa4o7FFv7Lcx1ApI7ZnJlqVgbXFMA GQKvPJbCcbyVYuva3vvyX/Bc9fg5E2nIlCmV1hYvDlZ3YI/8rqczzWBuuAVsERIp/35v XZJj+F6TFFcaQiBNNCxYFwd4qe4y/a6hkFdJyYanaK9UV7bT+juur5gilOMlqmNNu0JM jxCH0EqCb+UkELSEoEcfJxIZPLfBJZB/5EnjqqZctGvRsu/+hqhoqU3ShVMSMyAon613 kZ3Q== X-Received: by 10.224.47.5 with SMTP id l5mr12268194qaf.114.1375285804530; Wed, 31 Jul 2013 08:50:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.48.234 with HTTP; Wed, 31 Jul 2013 08:49:24 -0700 (PDT) X-Originating-IP: [2001:df8:0:16:5a55:caff:fef1:5a11] In-Reply-To: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> From: Eric Rescorla Date: Wed, 31 Jul 2013 17:49:24 +0200 Message-ID: To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=001a11c2c984d8103204e2d0adf7 X-Gm-Message-State: ALoCoQnTA/Cvy+oPvRTAxp4cvBIeSjMs6PlfcG1I3giHmRR0KvG5XVKoTRarXyCiE+22i6BQ4Cw7 Cc: IETF STIR Mail List , Russ Housley Subject: Re: [stir] Including out-of-band in the Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 15:50:13 -0000 --001a11c2c984d8103204e2d0adf7 Content-Type: text/plain; charset=ISO-8859-1 This works for me. On Wed, Jul 31, 2013 at 5:33 PM, Cullen Jennings (fluffy) wrote: > > On Jul 31, 2013, at 5:22 PM, Russ Housley > wrote: > > > > > No one spoke against including an in-band mechanism in the charter. So, > it is clearly in the charter. We need to decide whether an out-of-band > mechanism is included as well. > > > > Many people spoke for including an out-of-band mechanism in the charter. > And, many people spoke against it. > > > > Here is my view of the hums that were taken at the end of the BOF ... > > > > First Hum: in-band only, out-of-band only, in-band then out-of-band, > and in-band and out-of-band together > > - there was no support for out-of-band only > > - there was roughly equal support for the other three options > > > > Second hum: could live with in-band and out-of-band in the charter > > - significant response > > > > Third hum: can't live in-band and out-of-band in the charter > > - a few people trying to make a lot of noise > > > > Since the BOF, I tried to talk to people that spoke against inclusion of > an out-of-band mechanism in the charter. I was not able to find everyone, > but I did find many. The majority of these people can live with an > out-of-band mechanism in the charter. > > > > So, I suggest that we leave this aspect of the charter alone. That is, > the proposed WG will deliver an in-band mechanism first, and then deliver > an out-of-band mechanism. Notice that this does not prevent the WG from > working on them at the same time, but ti does speak directly to the order > that they will be sent to the IESG. > > > > Thoughts? > > Given the urgency to move forward with this work, I can live with this. > > Cullen > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --001a11c2c984d8103204e2d0adf7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This works for me.

On Wed, Jul 31, 2013 at 5:33 PM, Cullen Jenning= s (fluffy) <fluffy@cisco.com> wrote:

On Jul 31, 2013, at 5:22 PM, Russ Housley <housley@vigilsec.com>
=A0wrote:

>
> No one spoke against including an in-band mechanism in the charter. = =A0So, it is clearly in the charter. =A0We need to decide whether an out-of= -band mechanism is included as well.
>
> Many people spoke for including an out-of-band mechanism in the charte= r. =A0And, many people spoke against it.
>
> Here is my view of the hums that were taken at the end of the BOF ...<= br> >
> First Hum: in-band only, =A0out-of-band only, in-band then out-of-band= , and in-band and out-of-band together
> =A0- there was no support for out-of-band only
> =A0- there was roughly equal support for the other three options
>
> Second hum: could live with in-band and out-of-band in the charter
> =A0- significant response
>
> Third hum: can't live in-band and out-of-band in the charter
> =A0- a few people trying to make a lot of noise
>
> Since the BOF, I tried to talk to people that spoke against inclusion = of an out-of-band mechanism in the charter. =A0I was not able to find every= one, but I did find many. =A0The majority of these people can live with an = out-of-band mechanism in the charter.
>
> So, I suggest that we leave this aspect of the charter alone. =A0That = is, the proposed WG will deliver an in-band mechanism first, and then deliv= er an out-of-band mechanism. =A0Notice that this does not prevent the WG fr= om working on them at the same time, but ti does speak directly to the orde= r that they will be sent to the IESG.
>
> Thoughts?

Given the urgency to move forward with this work, I can live wi= th this.

Cullen


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

--001a11c2c984d8103204e2d0adf7-- From hadriel.kaplan@oracle.com Wed Jul 31 08:52: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 3E92B21F99ED for ; Wed, 31 Jul 2013 08:52:44 -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.019, 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 yCzTIS98n8T5 for ; Wed, 31 Jul 2013 08:52:37 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id B554A21F9306 for ; Wed, 31 Jul 2013 08:52:37 -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 r6VFqSog030323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 31 Jul 2013 15:52:29 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 r6VFqRBo006412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Jul 2013 15:52:28 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 r6VFqRVB009480; Wed, 31 Jul 2013 15:52:27 GMT Received: from dhcp-1322.meeting.ietf.org (/130.129.19.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 31 Jul 2013 08:52:26 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Wed, 31 Jul 2013 11:52:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1E297978-283B-4ECE-B641-0213A5C65B0B@oracle.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: IETF STIR Mail List Subject: Re: [stir] Including out-of-band in the Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 15:52:44 -0000 On Jul 31, 2013, at 11:33 AM, Cullen Jennings (fluffy) = wrote: >=20 > On Jul 31, 2013, at 5:22 PM, Russ Housley > wrote: >=20 >> Since the BOF, I tried to talk to people that spoke against inclusion = of an out-of-band mechanism in the charter. I was not able to find = everyone, but I did find many. The majority of these people can live = with an out-of-band mechanism in the charter.=20 >>=20 >> So, I suggest that we leave this aspect of the charter alone. That = is, the proposed WG will deliver an in-band mechanism first, and then = deliver an out-of-band mechanism. Notice that this does not prevent the = WG from working on them at the same time, but ti does speak directly to = the order that they will be sent to the IESG. >>=20 >> Thoughts? >=20 > Given the urgency to move forward with this work, I can live with = this.=20 >=20 > Cullen Same here. -hadriel From michael.hammer@yaanatech.com Wed Jul 31 09:26: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 B346E21F866E for ; Wed, 31 Jul 2013 09:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 qSaD63csqvSw for ; Wed, 31 Jul 2013 09:26:05 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 344FE21F9FFF for ; Wed, 31 Jul 2013 09:26:03 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Wed, 31 Jul 2013 09:26:01 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" , "housley@vigilsec.com" Thread-Topic: [stir] Including out-of-band in the Charter Thread-Index: AQHOjgHUZxSTLVos9Uy1evxdi70FmZl/YAKAgAAFOAD//5PwsA== Date: Wed, 31 Jul 2013 16:26:01 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC206E1@EX2K10MB1.corp.yaanatech.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <1E297978-283B-4ECE-B641-0213A5C65B0B@oracle.com> In-Reply-To: <1E297978-283B-4ECE-B641-0213A5C65B0B@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.144] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00BE_01CE8DE9.1D6381C0" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Including out-of-band in the Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 16:26:17 -0000 ------=_NextPart_000_00BE_01CE8DE9.1D6381C0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Looks good enough. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Wednesday, July 31, 2013 11:52 AM To: Russ Housley Cc: IETF STIR Mail List Subject: Re: [stir] Including out-of-band in the Charter On Jul 31, 2013, at 11:33 AM, Cullen Jennings (fluffy) wrote: > > On Jul 31, 2013, at 5:22 PM, Russ Housley > wrote: > >> Since the BOF, I tried to talk to people that spoke against inclusion of an out-of-band mechanism in the charter. I was not able to find everyone, but I did find many. The majority of these people can live with an out-of-band mechanism in the charter. >> >> So, I suggest that we leave this aspect of the charter alone. That is, the proposed WG will deliver an in-band mechanism first, and then deliver an out-of-band mechanism. Notice that this does not prevent the WG from working on them at the same time, but ti does speak directly to the order that they will be sent to the IESG. >> >> Thoughts? > > Given the urgency to move forward with this work, I can live with this. > > Cullen Same here. -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_00BE_01CE8DE9.1D6381C0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcz MTE2MjYwMFowIwYJKoZIhvcNAQkEMRYEFLB4HNNCAh0uSylFz9AkuKRR0TxvMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAePkgeeHlu94xsVNJc6DNe6YsMuf11FX9lsn1HBX5 g2W01DFT7Ugvaftoj2SHdAWSPH2Fu4N7r5XllKLtzqFZVF0LQO0G3JLxwpc3ffXQrnAqDW1VD3i1 JtNvTyk3MVFBV6oZtVbpIb2sK35tDMCrmckX2ijUlk8YuXCEoYZiNeHVAfiOeLQxaOoyrq8PFTSV OH3qrVv+BKLFjQj8UWQD9cPxvG8P9RX0EirpgALxJEKnLxIqtY87H9tJXJIq/WLEXR6QqGtpb7aP b1My4JS0Q4yuWqcoy665PddW/qeL9Dzt+XGIpE1zw5fag9qhK+9UluK35uVwifOODE/AWcp+zgAA AAAAAA== ------=_NextPart_000_00BE_01CE8DE9.1D6381C0-- From dhc@dcrocker.net Wed Jul 31 09:31: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 F12DA21F8E8E for ; Wed, 31 Jul 2013 09:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.368 X-Spam-Level: X-Spam-Status: No, score=-6.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: 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+9EWNjro+lm for ; Wed, 31 Jul 2013 09:31:24 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9F25321F85D1 for ; Wed, 31 Jul 2013 09:31:02 -0700 (PDT) Received: from [130.129.84.47] (dhcp-542f.meeting.ietf.org [130.129.84.47]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r6VGUlaw019061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Jul 2013 09:30:52 -0700 Message-ID: <51F93BB3.6090706@dcrocker.net> Date: Wed, 31 Jul 2013 18:30:43 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Stephen Kent References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> In-Reply-To: <51F92CDD.4030306@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 31 Jul 2013 09:30:53 -0700 (PDT) Cc: stir@ietf.org Subject: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 16:31:29 -0000 On 7/31/2013 5:27 PM, Stephen Kent wrote: > As I mentioned at the mic, I'd like to see both a threat model and a > privacy analysis as deliverables early in this process. +1 The only caveat I'll raise is based on a 'scoping' problem that happened for the threats exercise when the DKIM wg was being formed. What we were initially asked for was a rather basic consideration of threats, to formulate some summary, pragmatic statements. Within a few days, a few IETF security folk -- I don't recall Herr Kent's position on this -- attempted to turn this into a detailed exercise at a level of detail I was told would have been appropriate to a military security system. Calling that onerous would entirely miss how unrealistic it would have been to attempt. I thought the original request quite appropriate, since it would get everyone on the same page about some essential motivations and goals for the effort. The result was a 25-page RFC.[1] I've never been clear whether it was more work than reasonable, too little, or just right. So I suggest some care in formulating these requirements, to keep it useful, quick and short. > I also think we need to have a discussion about the size of the > population of calling parties who will have credentials, and the size > of the verifiers in the system. +1 d/ [1] http://www.ietf.org/rfc/rfc4686.txt -- Dave Crocker Brandenburg InternetWorking bbiw.net From richard@shockey.us Wed Jul 31 09: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 98F5821F9F20 for ; Wed, 31 Jul 2013 09:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r40mSFwCvkrr for ; Wed, 31 Jul 2013 09:38:58 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 7002421F9EB2 for ; Wed, 31 Jul 2013 09:38:49 -0700 (PDT) Received: (qmail 12567 invoked by uid 0); 31 Jul 2013 16:38:28 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy9.bluehost.com with SMTP; 31 Jul 2013 16:38: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:In-Reply-To:References:To:From; bh=JhFSEtR/HBnYVYUCozbVtKEBKXVBjOMR177pjWmXt3o=; b=MZP4IKsYyQh7J6HM8kR5OsXi4CZI3jbgWitYtwYqg+K3VhIqTrCvzrXYdjP1c3mOfx6ny58dxrqlL1vjCIEh5yan6ZF31lpPW0sv/xLvUcgquagH/Rw9A6nrNDEhSukM; Received: from [46.189.28.45] (port=63984 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V4ZPu-0005ZX-Vc; Wed, 31 Jul 2013 10:38:27 -0600 From: "Richard Shockey" To: "'Stephen Kent'" , "'IETF STIR Mail List'" References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> In-Reply-To: <51F92CDD.4030306@bbn.com> Date: Wed, 31 Jul 2013 12:38:23 -0400 Message-ID: <00c101ce8e0c$612f88e0$238e9aa0$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQI7OgwXD7YJmY41/R0VdP2INABppQGCFD6zmJmRJfA= X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 46.189.28.45 authed with richard@shockey.us} Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 16:39:03 -0000 I agree though as Lucy Lynch pointed out in calling out attention to the privacy problem there may be an interesting dimension to this. When does the right to privacy trump the right to be anonymous? We are confronted with a situation where a genuine perceived need for anonymous communications identity for some has become a shield for criminal behavior. The other issue maybe ISOC can help us with this problem is we still don't have an idea of the scope of the problem beyond North America. Other jurisdictions handle this differently and this is a perfect opportunity to encourage national regulators to engage with the IETF/ISOC in investigating these problems. I would argue that what we are seeing in North America is the "Canary in the Coal Mine". -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Wednesday, July 31, 2013 11:27 AM To: stir@ietf.org Subject: Re: [stir] Moving from BOF to Charter Russ, As I mentioned at the mic, I'd like to see both a threat model and a privacy analysis as deliverables early in this process. I also think we need to have a discussion about the size of the population of calling parties who will have credentials, and the size of the verifiers in the system. This seemed to be the source of some disagreement during the BoF, and some proposals that might work well for small values of either (or both) of these parameters might not work well for very large values of these parameters. The texts says: As its first work item, the working group will specify a SIP header-based authorization mechanism to verify the originator of a SIP session is authorized to use the claimed source telephone number, Should the "authorization" be "authentication" above. I agree with the use of "authorized" in the latter part of the sentence. later, the text says: After completing the in-band mechanism, the working group will consider session establishment where there are one or more non-SIP hops, most likely using an out-of-band authorization mechanism. Did you mean authorization or authentication here? Steve _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From richard@shockey.us Wed Jul 31 09:39: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 5788C21F9EED for ; Wed, 31 Jul 2013 09:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 Ii9bc9IvLagn for ; Wed, 31 Jul 2013 09:39:30 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by ietfa.amsl.com (Postfix) with SMTP id 414C421F9D53 for ; Wed, 31 Jul 2013 09:39:30 -0700 (PDT) Received: (qmail 31708 invoked by uid 0); 31 Jul 2013 16:39:08 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com with SMTP; 31 Jul 2013 16:39:08 -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=fpSUwAYZPY/l4Vk0lgm1djyAaY52kuPl43cTnD+VQxA=; b=eswLAYH28bVTw5HCxQlE/GruwVAAE3yqEKzUvIiWbYzeZEB48ysbwsoKiy98t4xcNV2sc0XU4YFY2Q5CqHU8JFuqF8TByAKEl0sSTFesZKToZHxaqi29TSFYHAfHmQHV; Received: from [46.189.28.45] (port=61646 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V4ZQa-00069V-C3; Wed, 31 Jul 2013 10:39:08 -0600 From: "Richard Shockey" To: "'Hadriel Kaplan'" , "'Russ Housley'" References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <1E297978-283B-4ECE-B641-0213A5C65B0B@oracle.com> In-Reply-To: <1E297978-283B-4ECE-B641-0213A5C65B0B@oracle.com> Date: Wed, 31 Jul 2013 12:39:04 -0400 Message-ID: <00c201ce8e0c$79db25c0$6d917140$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQI7OgwXD7YJmY41/R0VdP2INABppQGit/x8AQXyeN8BgrZiY5iESalQ X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 46.189.28.45 authed with richard@shockey.us} Cc: 'IETF STIR Mail List' Subject: Re: [stir] Including out-of-band in the Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 16:39:35 -0000 +1 in band first then ... -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Wednesday, July 31, 2013 11:52 AM To: Russ Housley Cc: IETF STIR Mail List Subject: Re: [stir] Including out-of-band in the Charter On Jul 31, 2013, at 11:33 AM, Cullen Jennings (fluffy) wrote: > > On Jul 31, 2013, at 5:22 PM, Russ Housley > wrote: > >> Since the BOF, I tried to talk to people that spoke against inclusion of an out-of-band mechanism in the charter. I was not able to find everyone, but I did find many. The majority of these people can live with an out-of-band mechanism in the charter. >> >> So, I suggest that we leave this aspect of the charter alone. That is, the proposed WG will deliver an in-band mechanism first, and then deliver an out-of-band mechanism. Notice that this does not prevent the WG from working on them at the same time, but ti does speak directly to the order that they will be sent to the IESG. >> >> Thoughts? > > Given the urgency to move forward with this work, I can live with this. > > Cullen Same here. -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From michael.hammer@yaanatech.com Wed Jul 31 09:57: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 008DC21F99BF for ; Wed, 31 Jul 2013 09:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 x7CGPHB6uxGi for ; Wed, 31 Jul 2013 09:57:24 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id C85BD21F9E5E for ; Wed, 31 Jul 2013 09:56:49 -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, 31 Jul 2013 09:56:49 -0700 From: Michael Hammer To: "richard@shockey.us" , "kent@bbn.com" , "stir@ietf.org" Thread-Topic: [stir] Moving from BOF to Charter Thread-Index: AQHOjfnsWvtGWyhvPke71SQYAe9TS5l/Xk+AgAAT1ID//4vX4A== Date: Wed, 31 Jul 2013 16:56:48 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC207BA@EX2K10MB1.corp.yaanatech.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <00c101ce8e0c$612f88e0$238e9aa0$@shockey.us> In-Reply-To: <00c101ce8e0c$612f88e0$238e9aa0$@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.144] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00EB_01CE8DED.6AC47AB0" MIME-Version: 1.0 Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 16:57:31 -0000 ------=_NextPart_000_00EB_01CE8DED.6AC47AB0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit All, For security, an assessment of the degree to which a called party can reasonably rely on the caller ID validation is in order. But, it should probably contain the warning to users to still not provide any sensitive information when they are not the calling party, to be safe. While privacy is important, I believe that it could be secondary, because, if this is designed as an optional feature (user chooses what to assert and whether to sign or not) such considerations are in the realm of the supplementary features like CLIP and CLIR. The default may be to show and sign for the 99% with an opt-in to suppress for the corner cases that need it. Privacy could also be modeled as an over-ride feature that allows a party or carrier to substitute an anonymous signature. Bottom line, privacy is a derivative of the caller ID function. Clearly there needs to be balance between the calling and called parties. Called parties are going to have to learn to automatically or manually block calls. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Wednesday, July 31, 2013 12:38 PM To: 'Stephen Kent'; 'IETF STIR Mail List' Subject: Re: [stir] Moving from BOF to Charter I agree though as Lucy Lynch pointed out in calling out attention to the privacy problem there may be an interesting dimension to this. When does the right to privacy trump the right to be anonymous? We are confronted with a situation where a genuine perceived need for anonymous communications identity for some has become a shield for criminal behavior. The other issue maybe ISOC can help us with this problem is we still don't have an idea of the scope of the problem beyond North America. Other jurisdictions handle this differently and this is a perfect opportunity to encourage national regulators to engage with the IETF/ISOC in investigating these problems. I would argue that what we are seeing in North America is the "Canary in the Coal Mine". -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Wednesday, July 31, 2013 11:27 AM To: stir@ietf.org Subject: Re: [stir] Moving from BOF to Charter Russ, As I mentioned at the mic, I'd like to see both a threat model and a privacy analysis as deliverables early in this process. I also think we need to have a discussion about the size of the population of calling parties who will have credentials, and the size of the verifiers in the system. This seemed to be the source of some disagreement during the BoF, and some proposals that might work well for small values of either (or both) of these parameters might not work well for very large values of these parameters. The texts says: As its first work item, the working group will specify a SIP header-based authorization mechanism to verify the originator of a SIP session is authorized to use the claimed source telephone number, Should the "authorization" be "authentication" above. I agree with the use of "authorized" in the latter part of the sentence. later, the text says: After completing the in-band mechanism, the working group will consider session establishment where there are one or more non-SIP hops, most likely using an out-of-band authorization mechanism. Did you mean authorization or authentication here? Steve _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_00EB_01CE8DED.6AC47AB0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcz MTE2NTY0N1owIwYJKoZIhvcNAQkEMRYEFPM7JNL1RqRgGWPVKvsaU/UqcYQRMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAJN8+Wp4UGs21PVVGgPRkmgl3IrFvKIsAKaJ0qAU5 I9rpeqvOK+pUYwvMn78cIGMF2HdtHc2UKR0hbLP9JJafAHcjA9u+Q5HFqUQHVQ8yDz6eVeLII76K rgOMdcC4mCqUmNatViFjkXVIBGDQcDuwDxhf8cIOdD2H2p2Qz5EL+rY5JsYSzW4OT8spXyxLt4zV 09B6+SKohQnabs5NzWCvt4746Mw3VhpkkQ5gkr00KdP85SmN68AFmffU78OJf21dDTiQznGMUQ5u LKZ90ODyaPfF4+EwJA9/jNHx7/r4JUo/P3iatRAthKgV8qHug9sQcmQwiR9z7q+2NlchKm+q+wAA AAAAAA== ------=_NextPart_000_00EB_01CE8DED.6AC47AB0-- From md3135@att.com Wed Jul 31 11:07: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 1496611E80A2 for ; Wed, 31 Jul 2013 11:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.266 X-Spam-Level: X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aG4pUAd5f7j for ; Wed, 31 Jul 2013 11:07:49 -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 AFC5011E819C for ; Wed, 31 Jul 2013 11:07:47 -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 37259f15.0.6456258.00-152.17839255.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 31 Jul 2013 18:07:48 +0000 (UTC) X-MXL-Hash: 51f9527413570e04-4b33bd31d266f049034d44c7a8cc82832efdd54b 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 r6VI7kOL019930; Wed, 31 Jul 2013 14:07:47 -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 r6VI7fID019844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Jul 2013 14:07:45 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 31 Jul 2013 18:07:28 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; Wed, 31 Jul 2013 14:07:26 -0400 From: "DOLLY, MARTIN C" To: Richard Shockey , "'Hadriel Kaplan'" , "'Russ Housley'" Thread-Topic: [stir] Including out-of-band in the Charter Thread-Index: AQHOjgHaIf9pO0TW2UGzL3AJe1O8VZl/LbeAgAAFOQCAAA0JAP//1SEg Date: Wed, 31 Jul 2013 18:07:25 +0000 Message-ID: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <1E297978-283B-4ECE-B641-0213A5C65B0B@oracle.com> <00c201ce8e0c$79db25c0$6d917140$@shockey.us> In-Reply-To: <00c201ce8e0c$79db25c0$6d917140$@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.81.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=Sa5AgItu c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=UrXGROb4Sj4A:10 a=fAMK-m9FHcUA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=ypAo7WP30rwA:10 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8] X-AnalysisOut: [ a=tGX7uwomAAAA:8 a=La4c-98B3eNZVqRM8h8A:9 a=CjuIK1q_8ugA:] X-AnalysisOut: [10 a=lZB815dzVvQA:10 a=JfD0Fch1gWkA:10 a=nY38QUQankMA:10 a] X-AnalysisOut: [=2yBe9JuNQujK5ap1:21 a=RU4qHC3UvpU-ffP9:21] Cc: 'IETF STIR Mail List' Subject: Re: [stir] Including out-of-band in the Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 18:07:55 -0000 Ok for as long as the in band is first....and please explain within the rul= es how that will be enforced? -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Ric= hard Shockey Sent: Wednesday, July 31, 2013 12:39 PM To: 'Hadriel Kaplan'; 'Russ Housley' Cc: 'IETF STIR Mail List' Subject: Re: [stir] Including out-of-band in the Charter +1 in band first then ... -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Wednesday, July 31, 2013 11:52 AM To: Russ Housley Cc: IETF STIR Mail List Subject: Re: [stir] Including out-of-band in the Charter On Jul 31, 2013, at 11:33 AM, Cullen Jennings (fluffy) wrote: >=20 > On Jul 31, 2013, at 5:22 PM, Russ Housley > wrote: >=20 >> Since the BOF, I tried to talk to people that spoke against inclusion of an out-of-band mechanism in the charter. I was not able to find everyone, but I did find many. The majority of these people can live with an out-of-band mechanism in the charter.=20 >>=20 >> So, I suggest that we leave this aspect of the charter alone. That is, the proposed WG will deliver an in-band mechanism first, and then deliver a= n out-of-band mechanism. Notice that this does not prevent the WG from working on them at the same time, but ti does speak directly to the order that they will be sent to the IESG. >>=20 >> Thoughts? >=20 > Given the urgency to move forward with this work, I can live with this.=20 >=20 > Cullen Same here. -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 housley@vigilsec.com Wed Jul 31 11:22: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 B129421E8050 for ; Wed, 31 Jul 2013 11:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.685 X-Spam-Level: X-Spam-Status: No, score=-102.685 tagged_above=-999 required=5 tests=[AWL=-0.086, 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 UeGKDbRtybSq for ; Wed, 31 Jul 2013 11:22:48 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4A111E819F for ; Wed, 31 Jul 2013 11:22:45 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 1BC3BF24038; Wed, 31 Jul 2013 14:22:52 -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 ObwFV07LpAYj; Wed, 31 Jul 2013 14:22:35 -0400 (EDT) Received: from dhcp-160f.meeting.ietf.org (dhcp-160f.meeting.ietf.org [130.129.22.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 60570F2401B; Wed, 31 Jul 2013 14:22:49 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Wed, 31 Jul 2013 14:22:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <96969EC7-2D7D-441E-BD4C-D17E4C2B7A88@vigilsec.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <1E297978-283B-4ECE-B641-0213A5C65B0B@oracle.com> <00c201ce8e0c$79db25c0$6d917140$@shockey.us> To: "DOLLY, MARTIN C" X-Mailer: Apple Mail (2.1085) Cc: IETF STIR Mail List Subject: Re: [stir] Including out-of-band in the Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 18:22:58 -0000 If the charter says that in-band must be done first, then the AD will = not accept a publication request for out-of-banf until that criteria is = met. Russ On Jul 31, 2013, at 2:07 PM, DOLLY, MARTIN C wrote: > Ok for as long as the in band is first....and please explain within = the rules how that will be enforced? >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Richard Shockey > Sent: Wednesday, July 31, 2013 12:39 PM > To: 'Hadriel Kaplan'; 'Russ Housley' > Cc: 'IETF STIR Mail List' > Subject: Re: [stir] Including out-of-band in the Charter >=20 > +1 in band first then ... >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of > Hadriel Kaplan > Sent: Wednesday, July 31, 2013 11:52 AM > To: Russ Housley > Cc: IETF STIR Mail List > Subject: Re: [stir] Including out-of-band in the Charter >=20 >=20 > On Jul 31, 2013, at 11:33 AM, Cullen Jennings (fluffy) = > wrote: >=20 >>=20 >> On Jul 31, 2013, at 5:22 PM, Russ Housley >> wrote: >>=20 >>> Since the BOF, I tried to talk to people that spoke against = inclusion of > an out-of-band mechanism in the charter. I was not able to find = everyone, > but I did find many. The majority of these people can live with an > out-of-band mechanism in the charter.=20 >>>=20 >>> So, I suggest that we leave this aspect of the charter alone. That = is, > the proposed WG will deliver an in-band mechanism first, and then = deliver an > out-of-band mechanism. Notice that this does not prevent the WG from > working on them at the same time, but ti does speak directly to the = order > that they will be sent to the IESG. >>>=20 >>> Thoughts? >>=20 >> Given the urgency to move forward with this work, I can live with = this.=20 >>=20 >> Cullen >=20 > Same here. >=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 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From md3135@att.com Wed Jul 31 11:25: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 A1DAF11E819F for ; Wed, 31 Jul 2013 11:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.313 X-Spam-Level: X-Spam-Status: No, score=-6.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esnMQq+HEFwe for ; Wed, 31 Jul 2013 11:25:13 -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 5DDE211E810A for ; Wed, 31 Jul 2013 11:25:13 -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 88659f15.0.6468571.00-468.17874091.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 31 Jul 2013 18:25:13 +0000 (UTC) X-MXL-Hash: 51f956897b47ab72-c279ea87c1b4cceee8a3cbaf22cff595a609c8c3 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 r6VIPBBL006372; Wed, 31 Jul 2013 14:25:12 -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 r6VIP6Ye006269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Jul 2013 14:25:08 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 31 Jul 2013 18:24:50 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; Wed, 31 Jul 2013 14:24:50 -0400 From: "DOLLY, MARTIN C" To: Russ Housley Thread-Topic: [stir] Including out-of-band in the Charter Thread-Index: AQHOjgHaIf9pO0TW2UGzL3AJe1O8VZl/LbeAgAAFOQCAAA0JAP//1SEggABHzwD//70n4A== Date: Wed, 31 Jul 2013 18:24:48 +0000 Message-ID: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <1E297978-283B-4ECE-B641-0213A5C65B0B@oracle.com> <00c201ce8e0c$79db25c0$6d917140$@shockey.us> <96969EC7-2D7D-441E-BD4C-D17E4C2B7A88@vigilsec.com> In-Reply-To: <96969EC7-2D7D-441E-BD4C-D17E4C2B7A88@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.81.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=Sa5AgItu c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=UrXGROb4Sj4A:10 a=fAMK-m9FHcUA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=ypAo7WP30rwA:10 a=tGX7uwomAAAA:8 a=48vgC7mUAAAA:8] X-AnalysisOut: [ a=AUd_NHdVAAAA:8 a=SoDjzUmlOKPKWABsLd8A:9 a=CjuIK1q_8ugA:] X-AnalysisOut: [10 a=nY38QUQankMA:10 a=lZB815dzVvQA:10 a=JfD0Fch1gWkA:10 a] X-AnalysisOut: [=mmT4MT22yIVB--D1:21 a=S0MII-fLOqtdQkQo:21] Cc: IETF STIR Mail List Subject: Re: [stir] Including out-of-band in the Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 18:25:19 -0000 Sorry in advance for being a pain, but "done first" as published RFC, or in= to IESG? If the latter, then first has little meaning... -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com]=20 Sent: Wednesday, July 31, 2013 2:23 PM To: DOLLY, MARTIN C Cc: IETF STIR Mail List Subject: Re: [stir] Including out-of-band in the Charter If the charter says that in-band must be done first, then the AD will not a= ccept a publication request for out-of-banf until that criteria is met. Russ On Jul 31, 2013, at 2:07 PM, DOLLY, MARTIN C wrote: > Ok for as long as the in band is first....and please explain within the r= ules how that will be enforced? >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of R= ichard Shockey > Sent: Wednesday, July 31, 2013 12:39 PM > To: 'Hadriel Kaplan'; 'Russ Housley' > Cc: 'IETF STIR Mail List' > Subject: Re: [stir] Including out-of-band in the Charter >=20 > +1 in band first then ... >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Hadriel Kaplan > Sent: Wednesday, July 31, 2013 11:52 AM > To: Russ Housley > Cc: IETF STIR Mail List > Subject: Re: [stir] Including out-of-band in the Charter >=20 >=20 > On Jul 31, 2013, at 11:33 AM, Cullen Jennings (fluffy) > wrote: >=20 >>=20 >> On Jul 31, 2013, at 5:22 PM, Russ Housley >> wrote: >>=20 >>> Since the BOF, I tried to talk to people that spoke against inclusion o= f > an out-of-band mechanism in the charter. I was not able to find everyone= , > but I did find many. The majority of these people can live with an > out-of-band mechanism in the charter.=20 >>>=20 >>> So, I suggest that we leave this aspect of the charter alone. That is, > the proposed WG will deliver an in-band mechanism first, and then deliver= an > out-of-band mechanism. Notice that this does not prevent the WG from > working on them at the same time, but ti does speak directly to the order > that they will be sent to the IESG. >>>=20 >>> Thoughts? >>=20 >> Given the urgency to move forward with this work, I can live with this.= =20 >>=20 >> Cullen >=20 > Same here. >=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 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From br@brianrosen.net Wed Jul 31 13:28: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 0852721F9B03 for ; Wed, 31 Jul 2013 13:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dn20byvIpME5 for ; Wed, 31 Jul 2013 13:28:31 -0700 (PDT) Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) by ietfa.amsl.com (Postfix) with ESMTP id 36FDE21F9B81 for ; Wed, 31 Jul 2013 13:28:31 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id x10so1174054pdj.29 for ; Wed, 31 Jul 2013 13:28:30 -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=Rs1aZfYzWyr1BxEPgj2ynqWvWNc+absdOGYlcpKJWjg=; b=UhVejcKCq7erSecz32UdIILuXaSvMtrojrabL1T3RGhN5lnlaO9zlWgVGQCNUbe1K7 5giuGHjB+8wP3Py3m/wToEgwsjsooGMLZIn3g0q/zbKbt+f8VRvDEtXqAtbUX/i60o7U akhhghoQ0jvU8Juymu3erD4WjIHqSGTIdBBYLijmbTPXiX08xTkMZ1113mdkSzwnw8CK zwx3ux/dU35KzAzY9rPNlKrEbfVcWUSJHn7R1bNN2RFJpt+VTvY74DMTk/mQSLo380hX 11O1D+F8KwBRLlOL5+B/GzEiff4peIMeZIyTK5aG9DnTMlhSKhBHbcCvPJSeZVHtHVK8 N1ug== MIME-Version: 1.0 X-Received: by 10.66.26.112 with SMTP id k16mr111783pag.65.1375302510562; Wed, 31 Jul 2013 13:28:30 -0700 (PDT) Received: by 10.70.23.225 with HTTP; Wed, 31 Jul 2013 13:28:30 -0700 (PDT) X-Originating-IP: [46.189.28.124] In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC207BA@EX2K10MB1.corp.yaanatech.com> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <00c101ce8e0c$612f88e0$238e9aa0$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBC207BA@EX2K10MB1.corp.yaanatech.com> Date: Wed, 31 Jul 2013 16:28:30 -0400 Message-ID: From: Brian Rosen To: Michael Hammer Content-Type: multipart/alternative; boundary=bcaec52998b599eab304e2d491ad X-Gm-Message-State: ALoCoQn4M2Mt6Fq9bQ2Hr+jTXpFqUFos+PZtydGVQiB792bZ7LGpEuBsg5oX4Tdd9kCKcAPlygiT Cc: "stir@ietf.org" , "kent@bbn.com" , "richard@shockey.us" Subject: Re: [stir] Moving from BOF to Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 20:28:36 -0000 --bcaec52998b599eab304e2d491ad Content-Type: text/plain; charset=ISO-8859-1 With respect to privacy, I think there are two principles we ought to explicitly agree to 1) Anonymous calls, as already defined in SIP standards will still work, which means they will not have a valid identiy 2) the mechanisms we design will not reveal any more information than a call without the mechanism would. The former is just some explici text that says the mechanism must not be applied to calls to with the anonymous From uri. The latter may constrain the mechanisms some, but that is a good thing. Brian On Wednesday, July 31, 2013, Michael Hammer wrote: > All, > > For security, an assessment of the degree to which a called party can > reasonably rely on the caller ID validation is in order. > But, it should probably contain the warning to users to still not provide > any sensitive information when they are not the calling party, to be safe. > > While privacy is important, I believe that it could be secondary, because, > if this is designed as an optional feature (user chooses what to assert and > whether to sign or not) > such considerations are in the realm of the supplementary features like > CLIP > and CLIR. > The default may be to show and sign for the 99% with an opt-in to suppress > for the corner cases that need it. > Privacy could also be modeled as an over-ride feature that allows a party > or > carrier to substitute an anonymous signature. > > Bottom line, privacy is a derivative of the caller ID function. > > Clearly there needs to be balance between the calling and called parties. > Called parties are going to have to learn to automatically or manually > block > calls. > > Mike > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] > On Behalf Of > Richard Shockey > Sent: Wednesday, July 31, 2013 12:38 PM > To: 'Stephen Kent'; 'IETF STIR Mail List' > Subject: Re: [stir] Moving from BOF to Charter > > > I agree though as Lucy Lynch pointed out in calling out attention to the > privacy problem there may be an interesting dimension to this. When does > the > right to privacy trump the right to be anonymous? We are confronted with a > situation where a genuine perceived need for anonymous communications > identity for some has become a shield for criminal behavior. > > The other issue maybe ISOC can help us with this problem is we still don't > have an idea of the scope of the problem beyond North America. Other > jurisdictions handle this differently and this is a perfect opportunity to > encourage national regulators to engage with the IETF/ISOC in investigating > these problems. > > I would argue that what we are seeing in North America is the "Canary in > the > Coal Mine". > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] > On Behalf Of > Stephen Kent > Sent: Wednesday, July 31, 2013 11:27 AM > To: stir@ietf.org > Subject: Re: [stir] Moving from BOF to Charter > > Russ, > > As I mentioned at the mic, I'd like to see both a threat model and a > privacy > analysis as deliverables early in this process. > > I also think we need to have a discussion about the size of the population > of calling parties who will have credentials, and the size of the verifiers > in the system. This seemed to be the source of some disagreement during the > BoF, and some proposals that might work well for small values of either (or > both) of these parameters might not work well for very large values of > these > parameters. > > The texts says: > > As its first work item, the working group will specify a SIP header-based > authorization mechanism to verify the originator of a SIP session is > authorized to use the claimed source telephone number, > > Should the "authorization" be "authentication" above. I agree with the use > of "authorized" in the latter part of the sentence. > > later, the text says: > > After completing the in-band mechanism, the working group will consider > session establishment where there are one or more non-SIP hops, most likely > using an out-of-band authorization mechanism. > > Did you mean authorization or authentication here? > > Steve > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --bcaec52998b599eab304e2d491ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable With respect to privacy, I think there are two principles=A0we ought to exp= licitly agree to
1) Anonymous calls, as already defined in SIP standard= s will still work, which means they will not have a valid identiy
2) the mechanisms we design will not reveal any more information than a cal= l without the mechanism would.

The former is just some explic= i text that says the mechanism must not be applied to calls to with the ano= nymous From uri. =A0The latter may constrain the mechanisms some, but that = is a good thing.

Brian

On Wednesda= y, July 31, 2013, Michael Hammer wrote:
All,

For security, an assessment of the degree to which a called party can
reasonably rely on the caller ID validation is in order.
But, it should probably contain the warning to users to still not provide any sensitive information when they are not the calling party, to be safe.<= br>
While privacy is important, I believe that it could be secondary, because,<= br> if this is designed as an optional feature (user chooses what to assert and=
whether to sign or not)
such considerations are in the realm of the supplementary features like CLI= P
and CLIR.
The default may be to show and sign for the 99% with an opt-in to suppress<= br> for the corner cases that need it.
Privacy could also be modeled as an over-ride feature that allows a party o= r
carrier to substitute an anonymous signature.

Bottom line, privacy is a derivative of the caller ID function.

Clearly there needs to be balance between the calling and called parties. Called parties are going to have to learn to automatically or manually bloc= k
calls.

Mike


-----Original Message-----
From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of
Richard Shockey
Sent: Wednesday, July 31, 2013 12:38 PM
To: 'Stephen Kent'; 'IETF STIR Mail List'
Subject: Re: [stir] Moving from BOF to Charter


I agree though as Lucy Lynch pointed out in calling out attention to the privacy problem there may be an interesting dimension to this. When does th= e
right to privacy trump the right to be anonymous? =A0We are confronted with= a
situation where a genuine perceived need for anonymous communications
identity for some has become a shield for criminal behavior.

The other issue maybe ISOC can help us with this problem is we still don= 9;t
have an idea of the scope of the problem beyond North America. =A0Other
jurisdictions handle this differently and this is a perfect opportunity to<= br> encourage national regulators to engage with the IETF/ISOC in investigating=
these problems.

I would argue that what we are seeing in North America is the "Canary = in the
Coal Mine".

-----Original Message-----
From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of
Stephen Kent
Sent: Wednesday, July 31, 2013 11:27 AM
To: stir@ietf.org
Subject: Re: [stir] Moving from BOF to Charter

Russ,

As I mentioned at the mic, I'd like to see both a threat model and a pr= ivacy
analysis as deliverables early in this process.

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

The texts says:

As its first work item, the working group will specify a SIP header-based authorization mechanism to verify the originator of a SIP session is
authorized to use the claimed source telephone number,

Should the "authorization" be "authentication" above. I= agree with the use
of "authorized" in the latter part of the sentence.

later, the text says:

After completing the in-band mechanism, the working group will consider
session establishment where there are one or more non-SIP hops, most likely=
using an out-of-band authorization mechanism.

Did you mean authorization or authentication here?

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

_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir
--bcaec52998b599eab304e2d491ad-- From philippe.fouquart@orange.com Wed Jul 31 13:45: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 966E721E80B1 for ; Wed, 31 Jul 2013 13:45: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=[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 TK-ptBWE8Bzz for ; Wed, 31 Jul 2013 13:45:46 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id D346611E8117 for ; Wed, 31 Jul 2013 13:45:44 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 1BC2F22CF32; Wed, 31 Jul 2013 22:45:41 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 022D7238067; Wed, 31 Jul 2013 22:45: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, 31 Jul 2013 22:45:40 +0200 From: To: Russ Housley , IETF STIR Mail List Thread-Topic: [stir] Moving from BOF to Charter (calling party identification) Thread-Index: AQHOji7qwjnpsorsjUeiOdzULNOmTg== Date: Wed, 31 Jul 2013 20:45:39 +0000 Message-ID: <29790_1375303541_51F97775_29790_15494_1_B5939C6860701C49AA39C5DA5189448B0B6F8B@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> In-Reply-To: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.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.7.31.190025 Subject: Re: [stir] Moving from BOF to Charter (calling party identification) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 31 Jul 2013 20:45:50 -0000 > - Be clear that the "calling party" is identified by their telephone nu= mber It's only used once in the preamble, and although I'm not enthralled with t= he use of authorization in that sentence, I can live with the current phras= ing personally.=20 This working group will define a deployable mechanism that verifies the authorization of the calling party to use a particular telephone number. Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Rus= s Housley Sent: Wednesday, July 31, 2013 4:25 PM To: IETF STIR Mail List Subject: [stir] Moving from BOF to Charter With the BOF behind us, I think there is one, and only one topic that this = mail list should be discussing. That is the charter text that is ready for= the IESG. The pre-BOF charter text is here: http://www.ietf.org/charter/charter-ietf-= stir-00-00.txt I will hold the pen on changes to the charter text. Some people suggested = changes during the BOF: Preamble - Remove "deployable" or change it to "rapidly deployable" - Add "within call set up time" - Add a discussion of a threat model - Be clear that the "calling party" is identified by their telephone num= ber Postamble - Can something be said about alignment of incentives? Privacy - We need to do more than punt. Please propose exact text for any of these topics. I prefer one proposed c= hange per message in a hope to more easily judge consensus. To this end, I= will start a thread on the inclusion of an out-of-band mechanism. Russ _______________________________________________ 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 philippe.fouquart@orange.com Wed Jul 31 13:47: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 6D06E21F9D0F for ; Wed, 31 Jul 2013 13:47:56 -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 kaKWt-4jDRRw for ; Wed, 31 Jul 2013 13:47:52 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 067A321F9CFB for ; Wed, 31 Jul 2013 13:47:52 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id ED5463243BB for ; Wed, 31 Jul 2013 22:47:50 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id D61D14C070 for ; Wed, 31 Jul 2013 22:47:50 +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, 31 Jul 2013 22:47:50 +0200 From: To: IETF STIR Mail List Thread-Topic: RE [stir] Moving from BOF to Charter ("deployable") Thread-Index: AQHOji84KcuSh8m5Tkasi5Ddie6EVA== Date: Wed, 31 Jul 2013 20:47:49 +0000 Message-ID: <5095_1375303670_51F977F6_5095_13950_1_B5939C6860701C49AA39C5DA5189448B0B6FA0@PEXCVZYM12.corporate.adroot.infra.ftgroup> 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.7.31.190025 Subject: [stir] RE Moving from BOF to Charter ("deployable") X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 31 Jul 2013 20:47:56 -0000 I would support removing "deployable", for the same reasons given during th= e session ("should go without saying" IMO). Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Rus= s Housley Sent: Wednesday, July 31, 2013 4:25 PM To: IETF STIR Mail List Subject: [stir] Moving from BOF to Charter With the BOF behind us, I think there is one, and only one topic that this = mail list should be discussing. That is the charter text that is ready for= the IESG. The pre-BOF charter text is here: http://www.ietf.org/charter/charter-ietf-= stir-00-00.txt I will hold the pen on changes to the charter text. Some people suggested = changes during the BOF: Preamble - Remove "deployable" or change it to "rapidly deployable" - Add "within call set up time" - Add a discussion of a threat model - Be clear that the "calling party" is identified by their telephone num= ber Postamble - Can something be said about alignment of incentives? Privacy - We need to do more than punt. Please propose exact text for any of these topics. I prefer one proposed c= hange per message in a hope to more easily judge consensus. To this end, I= will start a thread on the inclusion of an out-of-band mechanism. Russ _______________________________________________ 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 rlb@ipv.sx Wed Jul 31 15:25: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 C351211E8127 for ; Wed, 31 Jul 2013 15:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vrC0AlvQ1ul for ; Wed, 31 Jul 2013 15:25:01 -0700 (PDT) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by ietfa.amsl.com (Postfix) with ESMTP id DE51611E811F for ; Wed, 31 Jul 2013 15:25:00 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id eh20so2544988obb.29 for ; Wed, 31 Jul 2013 15:25:00 -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=xOGf6UO+DdOidR+JkaF43H8tSkngBse8Q5LoJ5Ddj5I=; b=nhHX6yMbIvE773DG/bZQtv5AK4TatGskE1VvDAlzhBtUSin2LtUO41TvNNN8XQUjqZ 5plsAj6TG8z4TNdicpL+BDB4D3RUPc4lwPDXwQKMRMECoFzpldsIMEln/S3cDCMTFVlt MOUP4SZl3OxtOUOm7kPe5IswmuzKK8i77K3Zcvf5z8ixlxqyPc41F/pZKcdGO963w+br FTYJqq7rkDiMgY9VL7KM6j/x6WzLJn5yA78InnUNiWCRGr4z2TmEQXh/FdEuSffpCq/B K2YejnOHhbc0sUBbMPXFYVdD8LIC92dmTnZukea3jvbr5Wfc/Hh6zzyZXktMqRADyuAn Xedw== MIME-Version: 1.0 X-Received: by 10.182.142.104 with SMTP id rv8mr62822494obb.3.1375309500157; Wed, 31 Jul 2013 15:25:00 -0700 (PDT) Received: by 10.60.26.135 with HTTP; Wed, 31 Jul 2013 15:25:00 -0700 (PDT) X-Originating-IP: [130.129.66.175] In-Reply-To: References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <1E297978-283B-4ECE-B641-0213A5C65B0B@oracle.com> <00c201ce8e0c$79db25c0$6d917140$@shockey.us> <96969EC7-2D7D-441E-BD4C-D17E4C2B7A88@vigilsec.com> Date: Thu, 1 Aug 2013 00:25:00 +0200 Message-ID: From: Richard Barnes To: "DOLLY, MARTIN C" Content-Type: multipart/alternative; boundary=001a11c2eaae36a07804e2d6325f X-Gm-Message-State: ALoCoQlrUQXxyCgNrfr+qJKCkg8xbvR2Hbm/FtiVNk18/kGxk1LBtSsT+c7Jqp3YR9dPG0Q1+ZnX Cc: IETF STIR Mail List , Russ Housley Subject: Re: [stir] Including out-of-band in the Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 22:25:05 -0000 --001a11c2eaae36a07804e2d6325f Content-Type: text/plain; charset=ISO-8859-1 As Russ suggested, the hard gate is submission to the IESG. That's the step that is most directly under the control of the WG, though they can obviously speed up IESG processing by ensuring that the document(s) are well-reviewed before they're submitted. After the documents have been submitted to the IESG, it will be my job to keep them in the right order. That said, it's not like publication request timing is the only tool we have. If consensus continues to build around In-then-Out, I would read the charter text to mean that the energy of the WG should be focused on the in-band solution until that solution is approaching completion, after which point out-of-band work can start up. The chairs can manage this by setting the timing of calls to adopt documents for the various solutions, timings of WGLCs, etc. We could also consider arranging the milestones so that they specify the sequencing in some more detail. (In any event, I would encourage WG participants to keep in mind that there will likely substantial overlap between the two solutions. They both require a credential infrastructure and some sort of authenticated object that attests to the validity of a call. They might only really differ in how the authenticated object is delivered from originator to verifier. So we might find that some of the first things that are delivered are common to both solutions.) Once we come to agreement on sequencing, we should take a look at the milestones to ensure that they reflect the sequencing we agree on. Hope that helps, --Richard On Wed, Jul 31, 2013 at 8:24 PM, DOLLY, MARTIN C wrote: > Sorry in advance for being a pain, but "done first" as published RFC, or > into IESG? If the latter, then first has little meaning... > > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Wednesday, July 31, 2013 2:23 PM > To: DOLLY, MARTIN C > Cc: IETF STIR Mail List > Subject: Re: [stir] Including out-of-band in the Charter > > If the charter says that in-band must be done first, then the AD will not > accept a publication request for out-of-banf until that criteria is met. > > Russ > > > On Jul 31, 2013, at 2:07 PM, DOLLY, MARTIN C wrote: > > > Ok for as long as the in band is first....and please explain within the > rules how that will be enforced? > > > > -----Original Message----- > > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Richard Shockey > > Sent: Wednesday, July 31, 2013 12:39 PM > > To: 'Hadriel Kaplan'; 'Russ Housley' > > Cc: 'IETF STIR Mail List' > > Subject: Re: [stir] Including out-of-band in the Charter > > > > +1 in band first then ... > > > > -----Original Message----- > > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > > Hadriel Kaplan > > Sent: Wednesday, July 31, 2013 11:52 AM > > To: Russ Housley > > Cc: IETF STIR Mail List > > Subject: Re: [stir] Including out-of-band in the Charter > > > > > > On Jul 31, 2013, at 11:33 AM, Cullen Jennings (fluffy) > > > wrote: > > > >> > >> On Jul 31, 2013, at 5:22 PM, Russ Housley > >> wrote: > >> > >>> Since the BOF, I tried to talk to people that spoke against inclusion > of > > an out-of-band mechanism in the charter. I was not able to find > everyone, > > but I did find many. The majority of these people can live with an > > out-of-band mechanism in the charter. > >>> > >>> So, I suggest that we leave this aspect of the charter alone. That is, > > the proposed WG will deliver an in-band mechanism first, and then > deliver an > > out-of-band mechanism. Notice that this does not prevent the WG from > > working on them at the same time, but ti does speak directly to the order > > that they will be sent to the IESG. > >>> > >>> Thoughts? > >> > >> Given the urgency to move forward with this work, I can live with this. > >> > >> Cullen > > > > Same here. > > > > -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 > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --001a11c2eaae36a07804e2d6325f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As Russ suggested, the hard gate is submission to the IESG= . =A0That's the step that is most directly under the control of the WG,= though they can obviously speed up IESG processing by ensuring that the do= cument(s) are well-reviewed before they're submitted. =A0After the docu= ments have been submitted to the IESG, it will be my job to keep them in th= e right order. =A0

That said, it's not like publication request timing is t= he only tool we have. =A0If consensus continues to build around In-then-Out= , I would read the charter text to mean that the energy of the WG should be= focused on the in-band solution until that solution is approaching complet= ion, after which point out-of-band work can start up. =A0The chairs can man= age this by setting the timing of calls to adopt documents for the various = solutions, timings of WGLCs, etc. =A0We could also consider arranging the m= ilestones so that they specify the sequencing in some more detail.

(In any event, I would encourage WG participants to kee= p in mind that there will likely substantial overlap between the two soluti= ons. =A0They both require a credential infrastructure and some sort of auth= enticated object that attests to the validity of a call. =A0They might only= really differ in how the authenticated object is delivered from originator= to verifier. =A0So we might find that some of the first things that are de= livered are common to both solutions.)

Once we come to agreement on sequencing, we should take= a look at the milestones to ensure that they reflect the sequencing we agr= ee on.

Hope that helps,
--Richard



On Wed, Jul 31, 2013 at 8:24 PM, DOLLY, MARTIN C = <md3135@att.com&= gt; wrote:
Sorry in advance for being a pain, but "= ;done first" as published RFC, or into IESG? If the latter, then first= has little meaning...

-----Original Message-----
From: Russ Housley [mailto:housley@= vigilsec.com]
Sent: Wednesday, July 31, 2013 2:23 PM
To: DOLLY, MARTIN C
Cc: IETF STIR Mail List
Subject: Re: [stir] Including out-of-band in the Charter

If the charter says that in-band must be done first, then the AD will not a= ccept a publication request for out-of-banf until that criteria is met.

Russ


On Jul 31, 2013, at 2:07 PM, DOLLY, MARTIN C wrote:

> Ok for as long as the in band is first....and please explain within th= e rules how that will be enforced?
>
> -----Original Message-----
> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Richard Shockey
> Sent: Wednesday, July 31, 2013 12:39 PM
> To: 'Hadriel Kaplan'; 'Russ Housley'
> Cc: 'IETF STIR Mail List'
> Subject: Re: [stir] Including out-of-band in the Charter
>
> +1 =A0 in band first then ...
>
> -----Original Message-----
> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of
> Hadriel Kaplan
> Sent: Wednesday, July 31, 2013 11:52 AM
> To: Russ Housley
> Cc: IETF STIR Mail List
> Subject: Re: [stir] Including out-of-band in the Charter
>
>
> On Jul 31, 2013, at 11:33 AM, Cullen Jennings (fluffy) <fluffy@cisco.com>
> wrote:
>
>>
>> On Jul 31, 2013, at 5:22 PM, Russ Housley <housley@vigilsec.com>
>> wrote:
>>
>>> Since the BOF, I tried to talk to people that spoke against in= clusion of
> an out-of-band mechanism in the charter. =A0I was not able to find eve= ryone,
> but I did find many. =A0The majority of these people can live with an<= br> > out-of-band mechanism in the charter.
>>>
>>> So, I suggest that we leave this aspect of the charter alone. = =A0That is,
> the proposed WG will deliver an in-band mechanism first, and then deli= ver an
> out-of-band mechanism. =A0Notice that this does not prevent the WG fro= m
> working on them at the same time, but ti does speak directly to the or= der
> that they will be sent to the IESG.
>>>
>>> Thoughts?
>>
>> Given the urgency to move forward with this work, I can live with = this.
>>
>> Cullen
>
> Same here.
>
> -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

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

--001a11c2eaae36a07804e2d6325f-- From dhc@dcrocker.net Wed Jul 31 22:22: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 76D3621F9B90 for ; Wed, 31 Jul 2013 22:22: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 iIZ7EprAkPZw for ; Wed, 31 Jul 2013 22:22:53 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id DAD4F21F9CA8 for ; Wed, 31 Jul 2013 22:22:38 -0700 (PDT) Received: from [192.168.1.203] (e178125099.adsl.alicedsl.de [85.178.125.99]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r715MPOE030507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Jul 2013 22:22:32 -0700 Message-ID: <51F9F08C.3050700@dcrocker.net> Date: Thu, 01 Aug 2013 07:22:20 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Richard Barnes References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <1E297978-283B-4ECE-B641-0213A5C65B0B@oracle.com> <00c201ce8e0c$79db25c0$6d917140$@shockey.us> <96969EC7-2D7D-441E-BD4C-D17E4C2B7A88@vigilsec.com> 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, 31 Jul 2013 22:22:38 -0700 (PDT) Cc: IETF STIR Mail List , Russ Housley Subject: Re: [stir] Including out-of-band in the Charter X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 05:22:58 -0000 On 8/1/2013 12:25 AM, Richard Barnes wrote: > (In any event, I would encourage WG participants to keep in mind that > there will likely substantial overlap between the two solutions. > They both require a credential infrastructure and some sort of > authenticated object that attests to the validity of a call. They > might only really differ in how the authenticated object is delivered > from originator to verifier. So we might find that some of the first > things that are delivered are common to both solutions.) Richard, The above text is, of course, an entirely reasonable line of thinking. It might even be correct, and for some approaches most certainly is. For others it isn't at all correct. The project management problem with what you've put forward is that any meaningful version of "keeping out-of-band in mind" while working on in-band effectively requires working on in-band and out-of-band simultaneously. That's fundamentally different from working with complete focus on in-band and only afterwards moving towards out-of-band. At every turn in considering choices for in-band, the implication of your statement is that people will be raising concerns for application to out-of-band. That essentially requires working out the details of out-of-band simultaneously with in-band. This is quite contrary to what is usually meant in a charter about working on one thing and /then/ on another. A charter is supposed to help reconcile these sorts of potential sources of focus-confusion, rather than make them fuzzier. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From kent@bbn.com Wed Jul 31 23:59: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 E5C7221F9C8C for ; Wed, 31 Jul 2013 23:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.349 X-Spam-Level: X-Spam-Status: No, score=-106.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 S8SH3nM5J2JM for ; Wed, 31 Jul 2013 23:59:46 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC4A21F9CAF for ; Wed, 31 Jul 2013 23:59:46 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:55557 helo=dhcp-13ac.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V4mrL-0006BF-7l; Thu, 01 Aug 2013 02:59:39 -0400 Message-ID: <51FA0753.6020600@bbn.com> Date: Thu, 01 Aug 2013 02:59:31 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <51F92CDD.4030306@bbn.com> <51F93BB3.6090706@dcrocker.net> In-Reply-To: <51F93BB3.6090706@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stir@ietf.org, Dave Crocker Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 06:59:52 -0000 Dave, I refer you to the BGPSEC threat doc (draft-ietf-sidr-bgpsec-threats-05), which is now in the hands of the RTG ADs, as an example of what I have in mind. It addresses a fairly complex, global system, so I would not expect an analogous doc for STIR to be any longer. Steve