From petithug@acm.org Thu Feb 2 08:59:57 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A0E21F85F0 for ; Thu, 2 Feb 2012 08:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.283 X-Spam-Level: X-Spam-Status: No, score=-102.283 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IVukyUwr8Rn for ; Thu, 2 Feb 2012 08:59:56 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 4F76C21F85EC for ; Thu, 2 Feb 2012 08:59:56 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 693A220414 for ; Thu, 2 Feb 2012 16:45:09 +0000 (UTC) Message-ID: <4F2AC107.8090607@acm.org> Date: Thu, 02 Feb 2012 08:59:51 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [VIPR] No conference call for 2012/02/03 X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 16:59:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 There was no new discussion on the mailing-list, and my list of issues is currently empty, so I propose to cancel the conference call for tomorrow. If there is subjects that you want to see on the agenda for the next call, please start the discussion on the mailing-list. Thanks. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPKsEFAAoJECnERZXWan7E2dUQANMy2vMihurKOPMNR9Ov0YXC KezKP1qu7QchlIUx/1QmhvnchVUJD1Yom10bBqrR6nN8FqOWgyduiVhkSunOJVqv DPUCxhuQcwFAWtsAscZVMAFtfM7tleEBaxRr2dl4XpbBvmgtM1xJ431ql4fb0Qyu 3DMLDn5rVapEAbGqfJXut7Trm0qrRZfBUii7t70ipJ5Ixwd/owD6+A/Fwjyiloyr pBvpPtsiXBmsVTXjARXUP0Gzwb7WdG5luXasEeJVUchAsikOGR8cirIQz5+cvAz2 xofKWyW9sIBxkBBSLnj6tOf+ycmeWvNr428zZ+RuZtHm/kn/x2l5HMLCXZ0JNf7R 4TOVliTB68m1qT1oMUCo6Q50nHaIiRJmOkiwxieQ/PQ4d9bUWim8YhWeMyNvGqCQ 4zMTyf/AmJrbFXCL7tXGyZJkLO/HT8S4ysjDsaY7OtI6vIRT/qcsPCm2CqCN/i+B pwNcjg0y6iJ+EAR+c2d0pR9FnLdcTyqoenHt3SpCno1Dc2Tz0EC7tVPT5rbIC8a8 /cfUuc041l60QIdcL84ns9cJGVySDogjoXUl6ZOBZJ3Td2eD6T/m3oolWv+kXbQt tlGmyKZk8qRfoIaLz/dBnyeZSbLRsB/5ryzV0CvVEBYnsVK3UtLv3wOkHJZajo22 xRuO1QzJ5DByPvP5W9Th =PHWT -----END PGP SIGNATURE----- From dean.willis@softarmor.com Fri Feb 3 09:07:44 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A4221F84CF for ; Fri, 3 Feb 2012 09:07:44 -0800 (PST) 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 IrL-dG15rPrb for ; Fri, 3 Feb 2012 09:07:44 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E3CBB21F84CD for ; Fri, 3 Feb 2012 09:07:43 -0800 (PST) Received: by obbwd15 with SMTP id wd15so5477915obb.31 for ; Fri, 03 Feb 2012 09:07:43 -0800 (PST) Received: by 10.182.41.36 with SMTP id c4mr7359825obl.21.1328288863569; Fri, 03 Feb 2012 09:07:43 -0800 (PST) Received: from [192.168.2.116] (cpe-66-25-15-110.tx.res.rr.com. [66.25.15.110]) by mx.google.com with ESMTPS id q9sm7745846obk.4.2012.02.03.09.07.41 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Feb 2012 09:07:42 -0800 (PST) References: <4F1F1A42.1030201@acm.org> <9734F726-C0A8-42D6-87A4-65535D5F3E80@bbn.com> <4F217CC9.4080802@acm.org> <50D0BC87-EC6C-401E-A2F9-A05AC60D5EF0@bbn.com> <4F2183D0.3070809@acm.org> <373FB643-AE7A-473C-A7AB-09F9A9E7093B@bbn.com> <4F21A121.10403@acm.org> <5466D9E6-3859-41A7-9A54-D23DC6D775C6@iii.ca> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: <00A1AC3E-167F-4243-9F1B-345AC99D2409@softarmor.com> Content-Transfer-Encoding: quoted-printable From: Dean Willis Date: Fri, 3 Feb 2012 11:07:40 -0600 To: Richard L. Barnes X-Mailer: Apple Mail (2.1084) Cc: "vipr@ietf.org" , Cullen Jennings Subject: Re: [VIPR] VIPR privacy issue X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 17:07:44 -0000 On Jan 27, 2012, at 9:08 AM, Richard L. Barnes wrote: > >=20 > Could we please distinguish between "location privacy" and "IP address = privacy"? They are related, but distinct concepts. >=20 Yep. Mobile IP can give us location privacy without IP address privacy. Hmm ... a separate RELOAD usage for MobileIP, then bootstrap VIPR on = top of that. Might work. What ever happened to HIP, anyhow? We're just dancing around the = locator-separator problem here. -- Dean From petithug@acm.org Fri Feb 3 09:16:53 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E318B21F8505 for ; Fri, 3 Feb 2012 09:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.306 X-Spam-Level: X-Spam-Status: No, score=-102.306 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYgZf-FewOXp for ; Fri, 3 Feb 2012 09:16:53 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 43F7D21F84FF for ; Fri, 3 Feb 2012 09:16:53 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id EDB6420143; Fri, 3 Feb 2012 17:02:02 +0000 (UTC) Message-ID: <4F2C1682.40802@acm.org> Date: Fri, 03 Feb 2012 09:16:50 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: Dean Willis References: <4F1F1A42.1030201@acm.org> <9734F726-C0A8-42D6-87A4-65535D5F3E80@bbn.com> <4F217CC9.4080802@acm.org> <50D0BC87-EC6C-401E-A2F9-A05AC60D5EF0@bbn.com> <4F2183D0.3070809@acm.org> <373FB643-AE7A-473C-A7AB-09F9A9E7093B@bbn.com> <4F21A121.10403@acm.org> <5466D9E6-3859-41A7-9A54-D23DC6D775C6@iii.ca> <00A1AC3E-167F-4243-9F1B-345AC99D2409@softarmor.com> In-Reply-To: <00A1AC3E-167F-4243-9F1B-345AC99D2409@softarmor.com> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "vipr@ietf.org" , Cullen Jennings Subject: Re: [VIPR] VIPR privacy issue X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 17:16:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/03/2012 09:07 AM, Dean Willis wrote: > > On Jan 27, 2012, at 9:08 AM, Richard L. Barnes wrote: > >> >> >> Could we please distinguish between "location privacy" and "IP address >> privacy"? They are related, but distinct concepts. >> > > Yep. Mobile IP can give us location privacy without IP address privacy. > > Hmm ... a separate RELOAD usage for MobileIP, then bootstrap VIPR on top > of that. Might work. > > What ever happened to HIP, anyhow? We're just dancing around the > locator-separator problem here. > There is already a draft explaining how to use RELOAD on top of HIP (draft-ietf-hip-reload-instance). I do not know which of the privacy leaks HIP would fix, but that is worth studying. I would have no problem making HIP mandatory (and as we are at it, IPv6) for VIPR. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPLBZ+AAoJECnERZXWan7EOo0P/jpuUdG6mcyRE2SAWI9tQczb MY7AXvLht9jKor/rp4UPgHg97L6v/tXBBfSIyt6yKoU+6IDf7tdHyUDAfyc0oZsM pr67dHuPr4BWkWSuijqhmDQb0IEyZSV5SHYtgeUW3vdJH4/EgQfBACvkpFbq3FeT nJxaaTsIXnnyzhpYd7F46xMRs0iS8SpwFLPjSVJG+GatazAQPyARkpBXR6T9twL5 2oCpVop5QLi7us4WXSLuEQnsjAsCfI9hB9I9kh3l9hV2UzBiK8EDJA6ykt+KnxVd HFo4036fqU9Jb6ESympxRfuqqOWleQGyPFjJGWkxXzFCQP75r6lvS8F3Ca+9cc23 +Swnm5EnwrbwNKgzoiwGYRXC+OEGaLSf9n1/4Qx8BWsGqWkZkOgTxAP4EO14d8/e xixv+7E3JujkgkUEEHQ4zu9EdFQ6odr2Ul/cgSVftq9FTC33M5Wwl7BrOzyVCABR p1ZlLzMzEcF7IuHUfGWJMK9n42nZTkG1evw0gJNxlDjAoCySuO1ihAygW4qJWkOL tZOXlGGDrzIlVmYLpH5lrBiyO910UUt7wb7hXnik4saYE2oRVBaA9oM2uvGLWXNu HE2fr8C+7/0WPp1VhW0M6H34W/fD6EiCDut/zUe4Tw8tjW/znPFD59JQrPxjoiIV j74IGD4HBy9bFFJ37x1r =aBp/ -----END PGP SIGNATURE----- From fluffy@fluffy.im Sun Feb 5 20:57:41 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991FB21F848F for ; Sun, 5 Feb 2012 20:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.477 X-Spam-Level: X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 f3sO5jw5Mjes for ; Sun, 5 Feb 2012 20:57:41 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1805D21F845E for ; Sun, 5 Feb 2012 20:57:41 -0800 (PST) Received: by iagf6 with SMTP id f6so9520432iag.31 for ; Sun, 05 Feb 2012 20:57:40 -0800 (PST) Received: by 10.50.42.199 with SMTP id q7mr19279044igl.9.1328504260661; Sun, 05 Feb 2012 20:57:40 -0800 (PST) Received: from [192.168.4.100] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id ub10sm13909663igb.7.2012.02.05.20.57.38 (version=SSLv3 cipher=OTHER); Sun, 05 Feb 2012 20:57:39 -0800 (PST) Sender: Cullen Jennings Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <00A1AC3E-167F-4243-9F1B-345AC99D2409@softarmor.com> Date: Sun, 5 Feb 2012 21:57:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F1F1A42.1030201@acm.org> <9734F726-C0A8-42D6-87A4-65535D5F3E80@bbn.com> <4F217CC9.4080802@acm.org> <50D0BC87-EC6C-401E-A2F9-A05AC60D5EF0@bbn.com> <4F2183D0.3070809@acm.org> <373FB643-AE7A-473C-A7AB-09F9A9E7093B@bbn.com> <4F21A121.10403@acm.org> <5466D9E6-3859-41A7-9A54-D23DC6D775C6@iii.ca> <00A1AC3E-167F-4243-9F1B-345AC99D2409@softarmor.com> To: Dean Willis X-Mailer: Apple Mail (2.1084) Cc: "vipr@ietf.org" Subject: Re: [VIPR] VIPR privacy issue X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 04:57:41 -0000 Just as an idle question that I have not thought about much ... how does = this attack change if you assume the VIPR server and SIP edge element = for a domain are running on an Amazon EC2 node? On Feb 3, 2012, at 10:07 AM, Dean Willis wrote: >=20 > On Jan 27, 2012, at 9:08 AM, Richard L. Barnes wrote: >=20 >> >>=20 >> Could we please distinguish between "location privacy" and "IP = address privacy"? They are related, but distinct concepts. >>=20 >=20 > Yep. Mobile IP can give us location privacy without IP address = privacy. >=20 > Hmm ... a separate RELOAD usage for MobileIP, then bootstrap VIPR on = top of that. Might work. >=20 > What ever happened to HIP, anyhow? We're just dancing around the = locator-separator problem here. >=20 > -- > Dean >=20 From petithug@acm.org Mon Feb 6 06:51:24 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B2921F85F0 for ; Mon, 6 Feb 2012 06:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.313 X-Spam-Level: X-Spam-Status: No, score=-102.313 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CsmNLOI-uYv for ; Mon, 6 Feb 2012 06:51:09 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 2114421F85DD for ; Mon, 6 Feb 2012 06:51:09 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 6C06920142; Mon, 6 Feb 2012 14:36:07 +0000 (UTC) Message-ID: <4F2FE8D8.7000804@acm.org> Date: Mon, 06 Feb 2012 06:51:04 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: Cullen Jennings References: <4F1F1A42.1030201@acm.org> <9734F726-C0A8-42D6-87A4-65535D5F3E80@bbn.com> <4F217CC9.4080802@acm.org> <50D0BC87-EC6C-401E-A2F9-A05AC60D5EF0@bbn.com> <4F2183D0.3070809@acm.org> <373FB643-AE7A-473C-A7AB-09F9A9E7093B@bbn.com> <4F21A121.10403@acm.org> <5466D9E6-3859-41A7-9A54-D23DC6D775C6@iii.ca> <00A1AC3E-167F-4243-9F1B-345AC99D2409@softarmor.com> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "vipr@ietf.org" , Dean Willis Subject: Re: [VIPR] VIPR privacy issue X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 14:51:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/05/2012 08:57 PM, Cullen Jennings wrote: > > Just as an idle question that I have not thought about much ... how does > this attack change if you assume the VIPR server and SIP edge element for a > domain are running on an Amazon EC2 node? It does not matter for the SIP edge element, as SIP is used only after a successful PVP transaction, which is not the case we are concerned with here. For the VIPR server (i.e. RELOAD and PVP), running it on an EC2 node effectively anonymizes the source IP address, as if a TURN server was used. Note that even in this case, the certificate of the signer of the AppAttachReq RELOAD message is leaked, which may contain sensible information in the Subject or subjectAltName. But my main concern is that protecting privacy using this method requires a action from the VIPR domain to make sure that the IP address used cannot be resolved back to them. A small number of domains will care, but the vast majority will not. I think that privacy has a better chance if the mechanism does not depends on the actions of individual domains, like always using a TURN server or adding onion routing in RELOAD. This still does not fix the certificate leak but one way to fix it could be to use a Traceable Anonymous Certificate (RFC 5636), which would provide the right amount of privacy while still permitting to blacklist a domain that abused its anonymity. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPL+jWAAoJECnERZXWan7EswYQAL9VPeCEEqUFfKWRbuVvi0XP pkRL+rhiC62FKf1Y6CqlSYKJczUchCPniTsl1a8/m0XbAtXE0CR+s7BhuZLsy3ZB IrJYWqIgWu3SY47W2r/kGcvo0hYiZ40CPBdTwPtwJPYeCvoCK/rMpHDWTdQRv1Mv YG+mO3jVKhSeAWYLHs4piA9JhMRhI546m4GJ6qaL5lqu1CaG0DEVIrcUKr4OL7R0 9vHSL1wsxmdFz9rVgGC7Booq68JCgHXGTtZ+mN3fBUhQEeawkd9UXNmgVeAURNoI BdcBL7QQx6nGmMJke37Dll0Mz/Zvy2rjmtcC31y8YlwSYvS9g+aoBZUYqU7UJMaR Brt3fg01qdECuOa6ekS2nS/xgogxh/yKGFI6u2Kvx8y+YuNLZGfu+EB2rNm+M5kb vAUQ9ZSK4SlR51V1f7lwGQb2T/5Ou/lazyJ9FWte9ToU5HYQsUlxQrN715/QmkUN fJ7EA3Ywyg+sBgWDKuJKY1pD0Shn7C3Wr5xKZXqOUZos/VGFR8eYMwpLS0jCPFie bFFgO96WCxsxcKlf9at3Keei/3OO7DGZNrUWjIv8bnrJ7/lEbiw9X98fcUslJxHl U151sAETS6wvNg8yff4oK4tQx4tZVcOjW7DKqqj9ymJ7yvAsb28A/rLXDtiNWUX0 rs5oOJP0O9fAMxqnGRUS =vnpL -----END PGP SIGNATURE----- From petithug@acm.org Mon Feb 6 09:36:02 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FE321F8621 for ; Mon, 6 Feb 2012 09:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.32 X-Spam-Level: X-Spam-Status: No, score=-102.32 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJVsE24wYo23 for ; Mon, 6 Feb 2012 09:36:02 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 126EE21F85E7 for ; Mon, 6 Feb 2012 09:36:02 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 6117B20142; Mon, 6 Feb 2012 17:21:00 +0000 (UTC) Message-ID: <4F300F7D.5030705@acm.org> Date: Mon, 06 Feb 2012 09:35:57 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: Cullen Jennings References: <4F1F1A42.1030201@acm.org> <9734F726-C0A8-42D6-87A4-65535D5F3E80@bbn.com> <4F217CC9.4080802@acm.org> <50D0BC87-EC6C-401E-A2F9-A05AC60D5EF0@bbn.com> <4F2183D0.3070809@acm.org> <373FB643-AE7A-473C-A7AB-09F9A9E7093B@bbn.com> <4F21A121.10403@acm.org> <5466D9E6-3859-41A7-9A54-D23DC6D775C6@iii.ca> <00A1AC3E-167F-4243-9F1B-345AC99D2409@softarmor.com> <4F2FE8D8.7000804@acm.org> In-Reply-To: <4F2FE8D8.7000804@acm.org> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "vipr@ietf.org" , Dean Willis Subject: Re: [VIPR] VIPR privacy issue X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 17:36:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/06/2012 06:51 AM, Marc Petit-Huguenin wrote: > On 02/05/2012 08:57 PM, Cullen Jennings wrote: > >> Just as an idle question that I have not thought about much ... how does >> this attack change if you assume the VIPR server and SIP edge element for >> a domain are running on an Amazon EC2 node? > > It does not matter for the SIP edge element, as SIP is used only after a > successful PVP transaction, which is not the case we are concerned with > here. > > For the VIPR server (i.e. RELOAD and PVP), running it on an EC2 node > effectively anonymizes the source IP address, as if a TURN server was > used. > > Note that even in this case, the certificate of the signer of the > AppAttachReq RELOAD message is leaked, which may contain sensible > information in the s/sensible/confidential/ (false friends) > Subject or subjectAltName. > > But my main concern is that protecting privacy using this method requires > a action from the VIPR domain to make sure that the IP address used cannot > be resolved back to them. A small number of domains will care, but the > vast majority will not. I think that privacy has a better chance if the > mechanism does not depends on the actions of individual domains, like > always using a TURN server or adding onion routing in RELOAD. > > This still does not fix the certificate leak but one way to fix it could be > to use a Traceable Anonymous Certificate (RFC 5636), which would provide > the right amount of privacy while still permitting to blacklist a domain > that abused its anonymity. > - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPMA97AAoJECnERZXWan7EXmUP/1+jv0r+WSlVHgyRh2IMatFN twQo1VPmPFX2rjtuUSPNgH6wzUQGM5Ps0mWknvRcO4iq6WnbLmvkRsnR5jG8RW1K yBIz02/6qLHqioJaivl0qnAVqaQ6Ebz8Jgtp1QgfrDrHPfbuvYa0MhujVpZtsX9Z L24Y0v5V7m+P7/SYmTP/YZkQ0ktOmC3qmtLlVeTQjhH0tO2bXIXhF+mPt14pu2zd a+iTf6df71y02hgD5ZHlVZvPFetkJwZqbQrXLKrl4jjDF/KarpBCTPsB1Fmd7+vy vrw62ixcY98vL2AHlBzHo5NVJF9Tr0Cmo7B5LlTLsPwgdkdMjv8kYpf37v4NGPAz v3/NiXP9csgMz5CFxqOOHYxLKRBc+IWWS4/thhYpx5veffGpGzPP30VaNz+8q+oG xeL4M0gvrvaYcjptmsd3480Vazmb1MGIH+o8otE8Gfops3y4hJXjeUnAp+FqtV+R BPFIFek51u71iuw/LIuuR1AttfGW9NdqUN2jEfkdvpZcUOW0+TUmkw2HBWxkfsxX QVYL0NqXvB0tS3z3DMJcgwYqKZNJ0Pyk7tSX7a8NUgKCeuk5au2CymPQumvw9itj Mg9iXI99KSeSb3yihWwRs0nH7I04oWdVRN6dutienorVQobDyu9NO91rDqs4s9WT BXBiFHB22lyF325DXKsp =Q6OX -----END PGP SIGNATURE----- From petithug@acm.org Tue Feb 7 09:09:05 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0304E21F85F1 for ; Tue, 7 Feb 2012 09:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.326 X-Spam-Level: X-Spam-Status: No, score=-102.326 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qY4G9mHw0Cy1 for ; Tue, 7 Feb 2012 09:09:04 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id F04CE21F885F for ; Tue, 7 Feb 2012 09:09:03 -0800 (PST) Received: from [IPv6:2406:a000:f007:6f00:213:d4ff:fe04:3e08] (unknown [IPv6:2406:a000:f007:6f00:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 9A0FB2043C for ; Tue, 7 Feb 2012 16:53:53 +0000 (UTC) Message-ID: <4F315AA1.9030703@acm.org> Date: Tue, 07 Feb 2012 09:08:49 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [VIPR] Identity certificate segregation for VIPR X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 17:09:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The current version of RELOAD requires that the certificates used contain one or more Node-IDs and one username. This username plays no role in VIPR, so it is not only useless, but can also be a source of privacy leak. A proposal was made in the p2psip WG some time ago for Identity certificate segregation[1] (see also [2]), but the author is waiting for the final version of RELOAD to publish a draft about this. My proposal is to say in the RELOAD usage document that VIPR must not use certificates with username, and to put a placeholder for the reference to the upcoming draft about Identity certificate segregation. Opinions? Thanks. [1] http://www.ietf.org/mail-archive/web/p2psip/current/msg06005.html [2] http://ieeexplore.ieee.org/iel5/4105970/5783356/05783372.pdf?arnumber=5783372 - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPMVqgAAoJECnERZXWan7Efz8QALZRQRYyDYwHjMd8IIShYEsd IoaZXZLR/F367dTKwQuVxCufD1Bh9DEtPJeRxUr7JLlSOariEUgUH9IIa4JKSOzi +fQxdMEm3KdRagIx+fqqBNlA9E1WuaViy8Q/sprJHo8KFGNWya2POL8ffg3wIU58 Xhw6M28XV3Db7MbLfl/Oy2DTtHhs32OHMAoSXd/sCKPF8o51QVl/nCGnxUsqLKgq u1VD99fWmTKCe/dw7BLqtdn2HQGEpYtlrUaJSLDK1ot1LmlNYJnNfFvaa28omKmQ YY9T137gkqUQc552FxGpoSWK/7dY0+NFvMGpxAwpTMEkuKFZvAXydrMNbulTV+qT jP7PBjYWBa2uD1r8IiEY2sUO1y0wbuK5QmHPlADuoSyISacclYSUgLlAm3ei7Hg/ SLHq/gzd6+4PQfKoFfIk5/7Rk8Be+rnlk/PjVHE3Kyy9WsfXmd2pTBW87f5U8tFK PYfrVXbjkyyReOokupq6IgyocjnnCSu6lmMQJMnLVzfw8jumuDLDsNZVchGz9dZe Ql0E215ZDRfTs90EGmNRfa2QzcDTx+f3IIeyTYNUx1yjmNMRaWZwEa86mKx6d5mJ Nrn53TLbQQ59JmGkn1EA396IqSOd4otz0aevAz1FxWoVMoXZNpbP2DPWgCTwbVxj BfFRQqyLkM6R/2zF234C =w/9F -----END PGP SIGNATURE----- From ekr@rtfm.com Tue Feb 7 09:51:50 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407FF21F8895 for ; Tue, 7 Feb 2012 09:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.909 X-Spam-Level: X-Spam-Status: No, score=-102.909 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 rXJ-ic2HyOEE for ; Tue, 7 Feb 2012 09:51:49 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 13AD821F8894 for ; Tue, 7 Feb 2012 09:51:48 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so5300896vcb.31 for ; Tue, 07 Feb 2012 09:51:48 -0800 (PST) Received: by 10.52.38.10 with SMTP id c10mr11060029vdk.58.1328637108296; Tue, 07 Feb 2012 09:51:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.71.19 with HTTP; Tue, 7 Feb 2012 09:51:08 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <4F315AA1.9030703@acm.org> References: <4F315AA1.9030703@acm.org> From: Eric Rescorla Date: Tue, 7 Feb 2012 09:51:08 -0800 Message-ID: To: Marc Petit-Huguenin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "vipr@ietf.org" Subject: Re: [VIPR] Identity certificate segregation for VIPR X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 17:51:50 -0000 On Tue, Feb 7, 2012 at 9:08 AM, Marc Petit-Huguenin wrot= e: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > The current version of RELOAD requires that the certificates used contain= one > or more Node-IDs and one username. =A0This username plays no role in VIPR= , so it > is not only useless, but can also be a source of privacy leak. > > A proposal was made in the p2psip WG some time ago for Identity certifica= te > segregation[1] (see also [2]), but the author is waiting for the final ve= rsion > of RELOAD to publish a draft about this. > > My proposal is to say in the RELOAD usage document that VIPR must not use > certificates with username, and to put a placeholder for the reference to= the > upcoming draft about Identity certificate segregation. Or, you could just use a dummy (random) username, e.g., a hash of the node-= id. -Ekr From petithug@acm.org Tue Feb 7 10:20:40 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1C421F887F for ; Tue, 7 Feb 2012 10:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.333 X-Spam-Level: X-Spam-Status: No, score=-102.333 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvOo2g-+XnBj for ; Tue, 7 Feb 2012 10:20:39 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id B104221F887C for ; Tue, 7 Feb 2012 10:20:39 -0800 (PST) Received: from [IPv6:2406:a000:f007:6f00:213:d4ff:fe04:3e08] (unknown [IPv6:2406:a000:f007:6f00:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 6071F20D2A; Tue, 7 Feb 2012 18:05:32 +0000 (UTC) Message-ID: <4F316B6F.7020308@acm.org> Date: Tue, 07 Feb 2012 10:20:31 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: Eric Rescorla References: <4F315AA1.9030703@acm.org> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "vipr@ietf.org" Subject: Re: [VIPR] Identity certificate segregation for VIPR X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 18:20:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/07/2012 09:51 AM, Eric Rescorla wrote: > On Tue, Feb 7, 2012 at 9:08 AM, Marc Petit-Huguenin > wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> The current version of RELOAD requires that the certificates used contain >> one or more Node-IDs and one username. This username plays no role in >> VIPR, so it is not only useless, but can also be a source of privacy >> leak. >> >> A proposal was made in the p2psip WG some time ago for Identity >> certificate segregation[1] (see also [2]), but the author is waiting for >> the final version of RELOAD to publish a draft about this. >> >> My proposal is to say in the RELOAD usage document that VIPR must not >> use certificates with username, and to put a placeholder for the >> reference to the upcoming draft about Identity certificate segregation. > > Or, you could just use a dummy (random) username, e.g., a hash of the > node-id. > Yes, although that would still require an enrollment server that slightly deviates from what is described in section 10.3 of RELOAD... ...or more precisely from what I understand from section 10.3, which is that the user name stored in the certificate returned is the concatenation of 1) the username passed as parameter of the HTTP POST, 2) the '@' character and 3) the overlay name (there is at least one implementation I know of that assumes that the username parameter is already in RCF822 form, thus permitting a domain name different from the overlay name). - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPMWtuAAoJECnERZXWan7E5iMP/i8USAqHFD8yhxAE8w2PKgyl CqWALShBV36pfMWojjQnNXDrLRPj0hnBoz9mQmBne03GQPof9x/uqDNdbc0BGm5+ xmEWpQr4ZHqPm1L0pZRmg2o/7X3M+61Byc1x+WjOda0weZX8qg6xEgOyRgpFPlsa GowkfMgFj69xk5bvH+wXI27a1cWBeR5ocrICkWwHCwrVmmysQzixD4bGmb8+wmLX QZ9CiL77cGxRzvGSULl0smqIyGR2WkrIzErpdVoqvFIXAV12AMEKZAGjMjReCX2B OOsxtfpz2xLKpqgHdLCcV65Gvd4dEM8jChZAIRPG1WhanpM/rYlrUt0gF9SFX5cC DRcM5II8vKqgwPQ2yb42tNekYpWicxcK09T5U7ghMsJttMbfEpK3vb8lAmAfpt6h /n/VmgxqocMgRSIYHWPOFiJ69fbMml4Hn31DKUc9IrVYN5IlTT/zg4ILEww0sLdI KqDDboDS9FZB1pBrEiAeCDcGIz0rKKheGH95iedAdkcp0lFP6p3SrzaFzIKtjq/r ME+PBUjMjXPROz5m/w/BL8TAtwGfbbv3GDlkIXtM0aSybHCjhZSEtK8ng457sd3u 6Lv/WV8i2hlMj5guYV8rI1J+S3r7mm+31O4NxyVXVBpy1DDRnMNyfV8xJJt6dqfM h7UHwT2A5OoNOtdZgsn7 =XWUE -----END PGP SIGNATURE----- From ekr@rtfm.com Tue Feb 7 10:34:13 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7ED21F88DA for ; Tue, 7 Feb 2012 10:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.911 X-Spam-Level: X-Spam-Status: No, score=-102.911 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 pDX7szMTkCdm for ; Tue, 7 Feb 2012 10:34:12 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAD821F88D6 for ; Tue, 7 Feb 2012 10:34:12 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so5333649vcb.31 for ; Tue, 07 Feb 2012 10:34:12 -0800 (PST) Received: by 10.220.153.201 with SMTP id l9mr13129668vcw.1.1328639651890; Tue, 07 Feb 2012 10:34:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.71.19 with HTTP; Tue, 7 Feb 2012 10:33:31 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <4F316B6F.7020308@acm.org> References: <4F315AA1.9030703@acm.org> <4F316B6F.7020308@acm.org> From: Eric Rescorla Date: Tue, 7 Feb 2012 10:33:31 -0800 Message-ID: To: Marc Petit-Huguenin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "vipr@ietf.org" Subject: Re: [VIPR] Identity certificate segregation for VIPR X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 18:34:13 -0000 On Tue, Feb 7, 2012 at 10:20 AM, Marc Petit-Huguenin wro= te: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 02/07/2012 09:51 AM, Eric Rescorla wrote: >> On Tue, Feb 7, 2012 at 9:08 AM, Marc Petit-Huguenin >> wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>> >>> The current version of RELOAD requires that the certificates used conta= in >>> one or more Node-IDs and one username. =A0This username plays no role i= n >>> VIPR, so it is not only useless, but can also be a source of privacy >>> leak. >>> >>> A proposal was made in the p2psip WG some time ago for Identity >>> certificate segregation[1] (see also [2]), but the author is waiting fo= r >>> the final version of RELOAD to publish a draft about this. >>> >>> My proposal is to say in the RELOAD usage document that VIPR must not >>> use certificates with username, and to put a placeholder for the >>> reference to the upcoming draft about Identity certificate segregation. >> >> Or, you could just use a dummy (random) username, e.g., a hash of the >> node-id. >> > > Yes, although that would still require an enrollment server that slightly > deviates from what is described in section 10.3 of RELOAD... > > ...or more precisely from what I understand from section 10.3, which is t= hat > the user name stored in the certificate returned is the concatenation of = 1) > the username passed as parameter of the HTTP POST, 2) the '@' character a= nd 3) > the overlay name (there is at least one implementation I know of that ass= umes > that the username parameter is already in RCF822 form, thus permitting a > domain name different from the overlay name). I don't read 10.3 as restricting the user name to be what is in the POST. T= he requirement is: o A single name this user is allowed to use in the overlay, using type rfc822Name. Enrollment servers SHOULD take care to only allow legal characters in the name (e.g., no embedded NULs), rather than simply accepting any name provided by the user. As authentication may not be required at all, I don't see how there can be a requirement that these two usernames be the same. o If authentication is required, there is an form parameter of "password" and "username" containing the user's name and password in the clear (hence the need for HTTPS) -Ekr > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iQIcBAEBCAAGBQJPMWtuAAoJECnERZXWan7E5iMP/i8USAqHFD8yhxAE8w2PKgyl > CqWALShBV36pfMWojjQnNXDrLRPj0hnBoz9mQmBne03GQPof9x/uqDNdbc0BGm5+ > xmEWpQr4ZHqPm1L0pZRmg2o/7X3M+61Byc1x+WjOda0weZX8qg6xEgOyRgpFPlsa > GowkfMgFj69xk5bvH+wXI27a1cWBeR5ocrICkWwHCwrVmmysQzixD4bGmb8+wmLX > QZ9CiL77cGxRzvGSULl0smqIyGR2WkrIzErpdVoqvFIXAV12AMEKZAGjMjReCX2B > OOsxtfpz2xLKpqgHdLCcV65Gvd4dEM8jChZAIRPG1WhanpM/rYlrUt0gF9SFX5cC > DRcM5II8vKqgwPQ2yb42tNekYpWicxcK09T5U7ghMsJttMbfEpK3vb8lAmAfpt6h > /n/VmgxqocMgRSIYHWPOFiJ69fbMml4Hn31DKUc9IrVYN5IlTT/zg4ILEww0sLdI > KqDDboDS9FZB1pBrEiAeCDcGIz0rKKheGH95iedAdkcp0lFP6p3SrzaFzIKtjq/r > ME+PBUjMjXPROz5m/w/BL8TAtwGfbbv3GDlkIXtM0aSybHCjhZSEtK8ng457sd3u > 6Lv/WV8i2hlMj5guYV8rI1J+S3r7mm+31O4NxyVXVBpy1DDRnMNyfV8xJJt6dqfM > h7UHwT2A5OoNOtdZgsn7 > =3DXWUE > -----END PGP SIGNATURE----- From petithug@acm.org Tue Feb 7 10:45:51 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE4C11E80AF for ; Tue, 7 Feb 2012 10:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.338 X-Spam-Level: X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tsl3gBXKb57J for ; Tue, 7 Feb 2012 10:45:50 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 88B0811E80AD for ; Tue, 7 Feb 2012 10:45:50 -0800 (PST) Received: from [IPv6:2406:a000:f007:6f00:213:d4ff:fe04:3e08] (unknown [IPv6:2406:a000:f007:6f00:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 4B9A42043C; Tue, 7 Feb 2012 18:30:43 +0000 (UTC) Message-ID: <4F317157.9040303@acm.org> Date: Tue, 07 Feb 2012 10:45:43 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: Eric Rescorla References: <4F315AA1.9030703@acm.org> <4F316B6F.7020308@acm.org> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "vipr@ietf.org" Subject: Re: [VIPR] Identity certificate segregation for VIPR X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 18:45:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/07/2012 10:33 AM, Eric Rescorla wrote: > On Tue, Feb 7, 2012 at 10:20 AM, Marc Petit-Huguenin > wrote: On 02/07/2012 09:51 AM, Eric Rescorla wrote: >>>> On Tue, Feb 7, 2012 at 9:08 AM, Marc Petit-Huguenin >>>> wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>>>> >>>>> The current version of RELOAD requires that the certificates used >>>>> contain one or more Node-IDs and one username. This username plays >>>>> no role in VIPR, so it is not only useless, but can also be a >>>>> source of privacy leak. >>>>> >>>>> A proposal was made in the p2psip WG some time ago for Identity >>>>> certificate segregation[1] (see also [2]), but the author is >>>>> waiting for the final version of RELOAD to publish a draft about >>>>> this. >>>>> >>>>> My proposal is to say in the RELOAD usage document that VIPR must >>>>> not use certificates with username, and to put a placeholder for >>>>> the reference to the upcoming draft about Identity certificate >>>>> segregation. >>>> >>>> Or, you could just use a dummy (random) username, e.g., a hash of >>>> the node-id. >>>> > > Yes, although that would still require an enrollment server that slightly > deviates from what is described in section 10.3 of RELOAD... > > ...or more precisely from what I understand from section 10.3, which is > that the user name stored in the certificate returned is the concatenation > of 1) the username passed as parameter of the HTTP POST, 2) the '@' > character and 3) the overlay name (there is at least one implementation I > know of that assumes that the username parameter is already in RCF822 form, > thus permitting a domain name different from the overlay name). > >> I don't read 10.3 as restricting the user name to be what is in the POST. >> The requirement is: > >> o A single name this user is allowed to use in the overlay, using type >> rfc822Name. Enrollment servers SHOULD take care to only allow legal >> characters in the name (e.g., no embedded NULs), rather than simply >> accepting any name provided by the user. > >> As authentication may not be required at all, I don't see how there can >> be a requirement that these two usernames be the same. > >> o If authentication is required, there is an form parameter of >> "password" and "username" containing the user's name and password in the >> clear (hence the need for HTTPS) > Hmmm. So I guess that this means that the following is in fact a conditional MUST: "The enrollment server MUST authenticate the request using the provided user name and password." Anyway, in the same paragraph we have this: "If the authentication succeeds and the requested user name is acceptable, the server generates..." I understand "requested user name" as the one that must be used as rfc822Name in the returned certificate. At best it is ambiguous. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPMXFWAAoJECnERZXWan7E5GYP/1kIwCVuzCBGVsAOpnkzcYD9 9ypZnQAe/9JolbQfNqMcU80DrvW8oTaax7ncoPunRVxXTAZWgnFuCYa49NUGd55d zyYmWgk+tN+szu7GZnpbfFP+jTY93A/KRwHacMDfm3BjukWU8lfk+IexG3+TO2GH BZ7pCWVsnou4ANVjGhY3RkhB8d4m7TC2aCzjVtj3hQP8f36JPRzFprMNUs0hWmMz tdRd/2k9ni/Li+fe7MCUL6k4QqaGmci4boUmsaChftlALh3dUj3rGRpU8qfnZT3u /kbkJEjbyaerBLwKssFe0EnHXpew72tK4Ub30k9uWTVe7mkIhUdTM8tqauiR2Gaq xyKrLn/rWPnd/ek0ZJAh4gyI2uSfDFEMtQPDFU4bmh/KCW3A9/xRa7ZyCtHotpQH spBnE8Zf26na+06o3qgVxBgH7xvvcW7SJ0YuI7TPOB2WYV6hN9LiurvFEVrY8/EU LbKVeJM5MBCwCNQDOe96RixDoSEQOyFP6zxzaDIseQq11E0m5izi86VaQH6fF+YR sMRd1S7AzmoTPfFNe1GwhcMivaLzY6xY7g2e1I1T9SdgfBwBlbUO5pIcfdYhS+v7 LroQhPIhUSyYpi9FBezmOOPqLgH8FUcRT6scYWfcx8LfhFY82G/N+uVLbUheu5SE TTftVuZJzhNuawAYXeT8 =QfH4 -----END PGP SIGNATURE----- From ekr@rtfm.com Tue Feb 7 10:53:56 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8F021F8880 for ; Tue, 7 Feb 2012 10:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.913 X-Spam-Level: X-Spam-Status: No, score=-102.913 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 aaaHyDtxIu3f for ; Tue, 7 Feb 2012 10:53:54 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A59BA21F86CB for ; Tue, 7 Feb 2012 10:53:51 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so5347920vcb.31 for ; Tue, 07 Feb 2012 10:53:51 -0800 (PST) Received: by 10.220.153.201 with SMTP id l9mr13157456vcw.1.1328640831190; Tue, 07 Feb 2012 10:53:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.71.19 with HTTP; Tue, 7 Feb 2012 10:53:11 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <4F317157.9040303@acm.org> References: <4F315AA1.9030703@acm.org> <4F316B6F.7020308@acm.org> <4F317157.9040303@acm.org> From: Eric Rescorla Date: Tue, 7 Feb 2012 10:53:11 -0800 Message-ID: To: Marc Petit-Huguenin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "vipr@ietf.org" Subject: Re: [VIPR] Identity certificate segregation for VIPR X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 18:53:56 -0000 On Tue, Feb 7, 2012 at 10:45 AM, Marc Petit-Huguenin wro= te: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 02/07/2012 10:33 AM, Eric Rescorla wrote: >> On Tue, Feb 7, 2012 at 10:20 AM, Marc Petit-Huguenin >> wrote: On 02/07/2012 09:51 AM, Eric Rescorla wrote: >>>>> On Tue, Feb 7, 2012 at 9:08 AM, Marc Petit-Huguenin >>>>> wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>>>>> >>>>>> The current version of RELOAD requires that the certificates used >>>>>> contain one or more Node-IDs and one username. =A0This username play= s >>>>>> no role in VIPR, so it is not only useless, but can also be a >>>>>> source of privacy leak. >>>>>> >>>>>> A proposal was made in the p2psip WG some time ago for Identity >>>>>> certificate segregation[1] (see also [2]), but the author is >>>>>> waiting for the final version of RELOAD to publish a draft about >>>>>> this. >>>>>> >>>>>> My proposal is to say in the RELOAD usage document that VIPR must >>>>>> not use certificates with username, and to put a placeholder for >>>>>> the reference to the upcoming draft about Identity certificate >>>>>> segregation. >>>>> >>>>> Or, you could just use a dummy (random) username, e.g., a hash of >>>>> the node-id. >>>>> >> >> Yes, although that would still require an enrollment server that slightl= y >> deviates from what is described in section 10.3 of RELOAD... >> >> ...or more precisely from what I understand from section 10.3, which is >> that the user name stored in the certificate returned is the concatenati= on >> of 1) the username passed as parameter of the HTTP POST, 2) the '@' >> character and 3) the overlay name (there is at least one implementation = I >> know of that assumes that the username parameter is already in RCF822 fo= rm, >> thus permitting a domain name different from the overlay name). >> >>> I don't read 10.3 as restricting the user name to be what is in the POS= T. >>> The requirement is: >> >>> o =A0A single name this user is allowed to use in the overlay, using ty= pe >>> rfc822Name. =A0Enrollment servers SHOULD take care to only allow legal >>> characters in the name (e.g., no embedded NULs), rather than simply >>> accepting any name provided by the user. >> >>> As authentication may not be required at all, I don't see how there can >>> be a requirement that these two usernames be the same. >> >>> o =A0If authentication is required, there is an form parameter of >>> "password" and "username" containing the user's name and password in th= e >>> clear (hence the need for HTTPS) >> > > Hmmm. =A0So I guess that this means that the following is in fact a condi= tional > MUST: > > "The enrollment server MUST authenticate the request using the > =A0provided user name and password." > > Anyway, in the same paragraph we have this: > > "If the authentication succeeds and the requested > =A0user name is acceptable, the server generates..." > > I understand "requested user name" as the one that must be used as rfc822= Name > in the returned certificate. =A0At best it is ambiguous. Regardless, I don't see a problem from the VIPR perspective. The VIPR clien= t can simply request a username that doesn't leak private information. -Ekr From petithug@acm.org Tue Feb 7 11:38:13 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80EC521F88E5 for ; Tue, 7 Feb 2012 11:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.344 X-Spam-Level: X-Spam-Status: No, score=-102.344 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bX6od+B-kvpz for ; Tue, 7 Feb 2012 11:38:12 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 6369B21F88DC for ; Tue, 7 Feb 2012 11:38:12 -0800 (PST) Received: from [IPv6:2406:a000:f007:6f00:213:d4ff:fe04:3e08] (unknown [IPv6:2406:a000:f007:6f00:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 863B120D52; Tue, 7 Feb 2012 19:23:05 +0000 (UTC) Message-ID: <4F317D9D.3020903@acm.org> Date: Tue, 07 Feb 2012 11:38:05 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: Eric Rescorla References: <4F315AA1.9030703@acm.org> <4F316B6F.7020308@acm.org> <4F317157.9040303@acm.org> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "vipr@ietf.org" Subject: Re: [VIPR] Identity certificate segregation for VIPR X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 19:38:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/07/2012 10:53 AM, Eric Rescorla wrote: > On Tue, Feb 7, 2012 at 10:45 AM, Marc Petit-Huguenin > wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> On 02/07/2012 10:33 AM, Eric Rescorla wrote: >>> On Tue, Feb 7, 2012 at 10:20 AM, Marc Petit-Huguenin >>> wrote: On 02/07/2012 09:51 AM, Eric Rescorla wrote: >>>>>> On Tue, Feb 7, 2012 at 9:08 AM, Marc Petit-Huguenin >>>>>> wrote: >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>>>>>> >>>>>>> The current version of RELOAD requires that the certificates >>>>>>> used contain one or more Node-IDs and one username. This >>>>>>> username plays no role in VIPR, so it is not only useless, but >>>>>>> can also be a source of privacy leak. >>>>>>> >>>>>>> A proposal was made in the p2psip WG some time ago for >>>>>>> Identity certificate segregation[1] (see also [2]), but the >>>>>>> author is waiting for the final version of RELOAD to publish a >>>>>>> draft about this. >>>>>>> >>>>>>> My proposal is to say in the RELOAD usage document that VIPR >>>>>>> must not use certificates with username, and to put a >>>>>>> placeholder for the reference to the upcoming draft about >>>>>>> Identity certificate segregation. >>>>>> >>>>>> Or, you could just use a dummy (random) username, e.g., a hash >>>>>> of the node-id. >>>>>> >>> >>> Yes, although that would still require an enrollment server that >>> slightly deviates from what is described in section 10.3 of RELOAD... >>> >>> ...or more precisely from what I understand from section 10.3, which >>> is that the user name stored in the certificate returned is the >>> concatenation of 1) the username passed as parameter of the HTTP POST, >>> 2) the '@' character and 3) the overlay name (there is at least one >>> implementation I know of that assumes that the username parameter is >>> already in RCF822 form, thus permitting a domain name different from >>> the overlay name). >>> >>>> I don't read 10.3 as restricting the user name to be what is in the >>>> POST. The requirement is: >>> >>>> o A single name this user is allowed to use in the overlay, using >>>> type rfc822Name. Enrollment servers SHOULD take care to only allow >>>> legal characters in the name (e.g., no embedded NULs), rather than >>>> simply accepting any name provided by the user. >>> >>>> As authentication may not be required at all, I don't see how there >>>> can be a requirement that these two usernames be the same. >>> >>>> o If authentication is required, there is an form parameter of >>>> "password" and "username" containing the user's name and password in >>>> the clear (hence the need for HTTPS) >>> >> >> Hmmm. So I guess that this means that the following is in fact a >> conditional MUST: >> >> "The enrollment server MUST authenticate the request using the provided >> user name and password." >> >> Anyway, in the same paragraph we have this: >> >> "If the authentication succeeds and the requested user name is >> acceptable, the server generates..." >> >> I understand "requested user name" as the one that must be used as >> rfc822Name in the returned certificate. At best it is ambiguous. > > Regardless, I don't see a problem from the VIPR perspective. The VIPR > client can simply request a username that doesn't leak private > information. > OK. Thanks. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPMX2bAAoJECnERZXWan7EHUgP/1RHhtOOV/MGRYILdD+0x3Hw bdsZs+G8WNLlvrZ8HtE4aF76wluSH91q5r5w46agG/262nkjLQXqHvD3hsrPsHUE ULKAR0SGj4CZJSTNdT7nVEchI8uAD3TzkyIvdn8aRkrQHbsiB6PDZtFA01440IYT i28o6fBsKWSJ02ze848HL25hle/K4QWiui6lqN6/gLA2F6qdPDe9raI1f/pBliD0 tXIcUmMIYqfR5i8dFsGYd04noLWEXdsVWCqrAgvXkAS0UP9nqu3UtKE7r1sDWnWw n9gyJK+Gwo8Ooja6tBR5KM3VsB7BO/x4LVtGUesmzq2qMQxIlt1Px1ag9Ei5hIJr c9aEHdpBImS8qVb4qxNEfChIBRzbTnN/pK/klOZ/uIV4o9xMRicmzoq6GOR460AL 43tQ0KvWGuCGZbSPhEqBouscll0GI6HruooB4SU0eyM6ZWWNgP7yQDyr6FQbQ0Cd 4Up0KLNP7Q4j8r8rc/RViqoj57U1xWwWvJoPRzJEUd7flZDnYjsXRU9QLv12XCrV kz5JLVn/oanwnWlsH0ruwXNAEwB8zuUlJd31kpXj8+qadtxnHb/0dJEPqfWRiATo gLilC4BR5NjEtjzloHbKAeXceLiYTLiQzsPMT0S7xrazwdkeztB9P8vIw3ivKnme /pSc5XpkL4z8QR/EVla4 =Fk4v -----END PGP SIGNATURE----- From petithug@acm.org Thu Feb 9 07:32:38 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C9721F84EF for ; Thu, 9 Feb 2012 07:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.349 X-Spam-Level: X-Spam-Status: No, score=-102.349 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-9lClUFXnPx for ; Thu, 9 Feb 2012 07:32:33 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id B2CED21F84F2 for ; Thu, 9 Feb 2012 07:32:32 -0800 (PST) Received: from [IPv6:2406:a000:f007:6f00:213:d4ff:fe04:3e08] (unknown [IPv6:2406:a000:f007:6f00:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id E452B20414 for ; Thu, 9 Feb 2012 15:17:18 +0000 (UTC) Message-ID: <4F33E708.1010200@acm.org> Date: Thu, 09 Feb 2012 07:32:24 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [VIPR] No conference call for 2012/02/10 X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 15:32:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 There was no unresolved issues discussed on the mailing-list, and as I am working on updating the current VIPR drafts, I still did not get the time to work on SIP intermediaries, troubleshooting and the VIPR infrastructure, so I propose to cancel the conference call for tomorrow. If there is subjects that you want to see on the agenda for the next call, please start the discussion on the mailing-list. Thanks. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPM+cEAAoJECnERZXWan7EVCgQAJu4gz5qTGUMiUl5zMaprdnz TGSv9HtOJP78rjaryYMX4UgsJALMlAvNa0j5tNaT8LD3yimwyTCy+ecCVNTOhAMa 8zAWT4zcMgU1v2LwxvS3pAve48J6+E9zT1Y4NpNR+GDGRLmC9e8aVL/w5Dx9xJiy H5OZK2xoBClAGz/gMhKWVmnGtEuD/wfyedUC2kA8Ip2JQ49bRj2+S+ZsZlRNB0B/ GsfSIx0mABuQ0YlslR+pOK3JnMfrKD6Qq6WpUO48mgQgR74JvwnhzAFAM0qvvpVq q7yM3QgVQBgXfflExaERODng/Coc0FG+jHNCANHYaB39U077BlGON/OPT0VeQD/x nyJ190EKyVYKH8HCGvurTsp7D1NFtjPmXcm/l2phmtfXM82B5rBd3+7KF8aDQeEn kutmyW+6pYB2ykTrQTKWtyxukUUSwD7SJDZQ6KX4zdfo6pmMcs79Vy+/innD6n7n Oh07TvdKnotEXSSISUdvAmBb3oSrE20RJRYz7HYiRdGExPtal9cMZ1iyAhQxAWEx ZGIQwEffd+JKOptD+PSPTmSMv5VG162YYWjW9fMmFOtq308wT6TICmSjRz49dCzD gfrd81u3aoIUKywybIJVOCKes6V/abdxzviVC4lLcEh/QzfxwXqZwJ3WMzmb3ro6 md+0woj2bhkhvM4xRbcd =VLIE -----END PGP SIGNATURE----- From petithug@acm.org Mon Feb 13 11:46:14 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6A521F865E for ; Mon, 13 Feb 2012 11:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.359 X-Spam-Level: X-Spam-Status: No, score=-102.359 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGhBqwHziohE for ; Mon, 13 Feb 2012 11:46:13 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 8618821F85DD for ; Mon, 13 Feb 2012 11:46:13 -0800 (PST) Received: from [IPv6:2406:a000:f007:6f00:213:d4ff:fe04:3e08] (unknown [IPv6:2406:a000:f007:6f00:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id F0F5C20142 for ; Mon, 13 Feb 2012 19:30:43 +0000 (UTC) Message-ID: <4F39687B.1090102@acm.org> Date: Mon, 13 Feb 2012 11:46:03 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: "vipr@ietf.org" References: <20120213193014.13407.27019.idtracker@ietfa.amsl.com> In-Reply-To: <20120213193014.13407.27019.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.3.4 X-Forwarded-Message-Id: <20120213193014.13407.27019.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [VIPR] Fwd: I-D Action: draft-petithuguenin-vipr-pvp-03.txt X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 19:46:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Instead of trying to fix everything at the same time, I decided to release incremental modifications of the VIPR specs. This new version of -vipr-pvp adds some text establishing the IANA registry for PVP methods, as was agreed (section 11). Some details I added since the last time we talked about this: - - Private methods start with "p-" and cannot be used between domains[1]. - - Experimental methods start with "x-" and the reversed domain. Experimental methods may be registered by IANA. - - The algorithm to assign priority is to use the median between the next method and the previous method to try. This means that method "a" has a priority of 0, method "b" has a priority of -16384 ((-32768 + 0) / 2), and method "c" will have a priority of 16383 ((0 + 32767) / 2) if we decide that it should be tried before method "a" or -8192 ((-16384 + 0) / 2) if we decide to try it after method "a". - - Multiple methods can have the same priority (I think that we talked about this in Taipei). Comments, questions, suggestions welcome. Thanks. [1] The reversed domain name is mandatory for private method, which does not make sense. This will be fixed in the next version. - -------- Original Message -------- Subject: I-D Action: draft-petithuguenin-vipr-pvp-03.txt Date: Mon, 13 Feb 2012 11:30:14 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Public Switched Telephone Network (PSTN) Validation Protocol (PVP) Author(s) : Marc Petit-Huguenin Jonathan Rosenberg Cullen Jennings Filename : draft-petithuguenin-vipr-pvp-03.txt Pages : 31 Date : 2012-02-13 One of the main challenges in inter-domain federation of Session Initiation Protocol (SIP) calls is that many domains continue to utilize phone numbers, and not email-style SIP URI. Consequently, a mechanism is needed that enables secure mappings from phone numbers to domains. The main technical challenge in doing this securely is to verify that the domain in question truly is the "owner" of the phone number. This specification defines the PSTN Validation Protocol (PVP), which can be used by a domain to verify this ownership by means of a forward routability check in the PSTN. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-petithuguenin-vipr-pvp-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-petithuguenin-vipr-pvp-03.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPOWh6AAoJECnERZXWan7E9KMP/16vNLepmHpgqWX//eUuU/Ov RCSIkUEeol3udn1o6d3NIOQpO5PYYV80BXO/R2ZjHXZFq2ByZ1C/oVTHsiMaSSQx 2/c33qT3nTvVpS/TBvptVUTP1Nf9GU9/VnP+hIL+Cr5Jw2Atr5t/GnGs+DODH8Xj jBLnEwBB5pzQ5Wm/G1WD088fvqJ38CH/GXnzeYflLT4WCzcc/uL3z4SVFiYAw6Zs 8aEpzfYAtk9sSaYFvtMaF19RfoT5BK/s3GW64ahQKDWw8yZrhJmIeGGtuahhqVS7 F4x+QqUkFC3ao2dr2/aPh164qKghJJz8PVXFp4X5jwlx/Y3KzlGx3wToe3NvSLiT ALp9dL/lcRKwc76MiiRKu+ZKrFqUBwmeJ8W8HtxH+cNh/f1geDsgdIDobJ9wVZas eQUx68swUhK8BAVIRMG6UiVbC2Gy/KmgjIzvtPBOmsPebm7J1Ir1fAVzCa7timk7 kMUwgeC0sJ1fXAtI/zPQvqSB9ibRjTRZQGP7xzgkgbhgMgPJIxFFuDnnd8vVUaUK IAPXJso9DTNyQQhq/KexROWUx1JSQh6rj7pqSGOweENknKccBnmB9LWf4pSdCDlV /BRSXbMAm0nb1uSprID5Ovc5+Ag1mLEAmhSoEJCZvsJTSAVzti4kHmkj9sSEe39B mci38Zi7O9T0FWrEv4Ug =Ox5X -----END PGP SIGNATURE----- From petithug@acm.org Thu Feb 16 09:03:21 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8807021F8841 for ; Thu, 16 Feb 2012 09:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.364 X-Spam-Level: X-Spam-Status: No, score=-102.364 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbZa2eOBhcvz for ; Thu, 16 Feb 2012 09:03:16 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 24F4521F885C for ; Thu, 16 Feb 2012 09:03:16 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 4C47120414 for ; Thu, 16 Feb 2012 16:47:36 +0000 (UTC) Message-ID: <4F3D36CF.7040805@acm.org> Date: Thu, 16 Feb 2012 09:03:11 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [VIPR] No conference call for 2012/02/17 X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 17:03:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 There was no unresolved issues discussed on the mailing-list, so I propose to cancel the conference call for tomorrow. If there is subjects that you want to see on the agenda for the next call, please start the discussion on the mailing-list. Thanks. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPPTbOAAoJECnERZXWan7EYiAP/jKDTl+Y/51XgVeWx45DSjTc zkV58bzaQLAyJDUSnojglDcmcqCzZt0ef//3KNVWvWabWtu/6ULyPQs5VLjakX7z HX5SHjWiLbxwzqZNuBmp6l9CN2iKpe85RYYumxedIHVgtTnrlkvOqMpkE9AEM6GT PepdN1qZDYDQ5bQbw4YqBtunZysnP0FoBYqJeO8C6Q7jgZmQnxjcSciM5LhtECoj UMJDaEhH496Gdi7sR+WQtXNzdV4PA2lxgcWQncFuCs8fYfN8whuc+ZOo9TEB3pCr uFTB+GZtK7DC1sAnIYzG5xfnmDCGedcnMPlVz8KS93dQYtUL7qi1swilXIKgBPXb NzT41qsOxkY7QGfuZUQ+OWr27FsUhVq7wIxplVAqm1MXACsNmKqZz+u4WYvu1aAV iYY54mdUzyzGUMsaGqXu6P1vdJo6sPRIoJe6XgQozocu3TcYTm1wC8goK75fu/2o 0A3c0DdIkQWNAtdLVtuZF3hm4oGE7kjr3MegvXFEViUWivWyQMw1N0YViWotkDEj i1qq+CGvYTNmxhZeaWMRCGCs7iudui+NKTaorFA0SR1/MemGi/DNoI29YaPPd05S 7v3bIpQPdBkiln0WUsupG/Np8Os8IMy83OYl/ZSzQBbI+GNKvd6HP3sw8N4TsD3I 76rXX3Eh/wv0Vvry2SPm =/WM6 -----END PGP SIGNATURE----- From fluffy@iii.ca Wed Feb 22 15:58:36 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A0311E807F for ; Wed, 22 Feb 2012 15:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.819 X-Spam-Level: X-Spam-Status: No, score=-2.819 tagged_above=-999 required=5 tests=[AWL=-0.220, 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 bfUohrmsQ82b for ; Wed, 22 Feb 2012 15:58:35 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 105CB11E8080 for ; Wed, 22 Feb 2012 15:58:35 -0800 (PST) Received: from [192.168.4.100] (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 F2A5422E259; Wed, 22 Feb 2012 18:58:23 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4F39687B.1090102@acm.org> Date: Wed, 22 Feb 2012 16:58:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <29D6EC8A-BD2E-47AB-AA6F-FE1AE46F5A3B@iii.ca> References: <20120213193014.13407.27019.idtracker@ietfa.amsl.com> <4F39687B.1090102@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1084) Cc: "vipr@ietf.org" Subject: Re: [VIPR] Fwd: I-D Action: draft-petithuguenin-vipr-pvp-03.txt X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 23:58:36 -0000 If an x- method turns out to be a great thing, how does it migrate to = being a non x- ? On Feb 13, 2012, at 12:46 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > Instead of trying to fix everything at the same time, I decided to = release > incremental modifications of the VIPR specs. >=20 > This new version of -vipr-pvp adds some text establishing the IANA = registry > for PVP methods, as was agreed (section 11). Some details I added = since the > last time we talked about this: >=20 > - - Private methods start with "p-" and cannot be used between = domains[1]. > - - Experimental methods start with "x-" and the reversed domain. = Experimental > methods may be registered by IANA. > - - The algorithm to assign priority is to use the median between the = next > method and the previous method to try. This means that method "a" has = a > priority of 0, method "b" has a priority of -16384 ((-32768 + 0) / 2), = and > method "c" will have a priority of 16383 ((0 + 32767) / 2) if we = decide that > it should be tried before method "a" or -8192 ((-16384 + 0) / 2) if we = decide > to try it after method "a". > - - Multiple methods can have the same priority (I think that we = talked about > this in Taipei). >=20 > Comments, questions, suggestions welcome. >=20 > Thanks. >=20 >=20 > [1] The reversed domain name is mandatory for private method, which = does not > make sense. This will be fixed in the next version. >=20 > - -------- Original Message -------- > Subject: I-D Action: draft-petithuguenin-vipr-pvp-03.txt > Date: Mon, 13 Feb 2012 11:30:14 -0800 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : The Public Switched Telephone Network (PSTN) = Validation > Protocol (PVP) > Author(s) : Marc Petit-Huguenin > Jonathan Rosenberg > Cullen Jennings > Filename : draft-petithuguenin-vipr-pvp-03.txt > Pages : 31 > Date : 2012-02-13 >=20 > One of the main challenges in inter-domain federation of Session > Initiation Protocol (SIP) calls is that many domains continue to > utilize phone numbers, and not email-style SIP URI. Consequently, a > mechanism is needed that enables secure mappings from phone numbers > to domains. The main technical challenge in doing this securely is > to verify that the domain in question truly is the "owner" of the > phone number. This specification defines the PSTN Validation > Protocol (PVP), which can be used by a domain to verify this > ownership by means of a forward routability check in the PSTN. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-petithuguenin-vipr-pvp-03.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-petithuguenin-vipr-pvp-03.txt >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) >=20 > iQIcBAEBCAAGBQJPOWh6AAoJECnERZXWan7E9KMP/16vNLepmHpgqWX//eUuU/Ov > RCSIkUEeol3udn1o6d3NIOQpO5PYYV80BXO/R2ZjHXZFq2ByZ1C/oVTHsiMaSSQx > 2/c33qT3nTvVpS/TBvptVUTP1Nf9GU9/VnP+hIL+Cr5Jw2Atr5t/GnGs+DODH8Xj > jBLnEwBB5pzQ5Wm/G1WD088fvqJ38CH/GXnzeYflLT4WCzcc/uL3z4SVFiYAw6Zs > 8aEpzfYAtk9sSaYFvtMaF19RfoT5BK/s3GW64ahQKDWw8yZrhJmIeGGtuahhqVS7 > F4x+QqUkFC3ao2dr2/aPh164qKghJJz8PVXFp4X5jwlx/Y3KzlGx3wToe3NvSLiT > ALp9dL/lcRKwc76MiiRKu+ZKrFqUBwmeJ8W8HtxH+cNh/f1geDsgdIDobJ9wVZas > eQUx68swUhK8BAVIRMG6UiVbC2Gy/KmgjIzvtPBOmsPebm7J1Ir1fAVzCa7timk7 > kMUwgeC0sJ1fXAtI/zPQvqSB9ibRjTRZQGP7xzgkgbhgMgPJIxFFuDnnd8vVUaUK > IAPXJso9DTNyQQhq/KexROWUx1JSQh6rj7pqSGOweENknKccBnmB9LWf4pSdCDlV > /BRSXbMAm0nb1uSprID5Ovc5+Ag1mLEAmhSoEJCZvsJTSAVzti4kHmkj9sSEe39B > mci38Zi7O9T0FWrEv4Ug > =3DOx5X > -----END PGP SIGNATURE----- > _______________________________________________ > VIPR mailing list > VIPR@ietf.org > https://www.ietf.org/mailman/listinfo/vipr From petithug@acm.org Thu Feb 23 07:26:17 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2790E21F841C for ; Thu, 23 Feb 2012 07:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.381 X-Spam-Level: X-Spam-Status: No, score=-102.381 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIu5V4ROQOuq for ; Thu, 23 Feb 2012 07:26:15 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 26DF121F85C4 for ; Thu, 23 Feb 2012 07:26:15 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 0358520414; Thu, 23 Feb 2012 15:10:08 +0000 (UTC) Message-ID: <4F465A93.1000208@acm.org> Date: Thu, 23 Feb 2012 07:26:11 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120216 Icedove/8.0 MIME-Version: 1.0 To: Cullen Jennings References: <20120213193014.13407.27019.idtracker@ietfa.amsl.com> <4F39687B.1090102@acm.org> <29D6EC8A-BD2E-47AB-AA6F-FE1AE46F5A3B@iii.ca> In-Reply-To: <29D6EC8A-BD2E-47AB-AA6F-FE1AE46F5A3B@iii.ca> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "vipr@ietf.org" Subject: Re: [VIPR] Fwd: I-D Action: draft-petithuguenin-vipr-pvp-03.txt X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 15:26:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/22/2012 03:58 PM, Cullen Jennings wrote: > > If an x- method turns out to be a great thing, how does it migrate to being > a non x- ? Simply define the new method in an RFC, and start adding the method in ViprRegistration. The only minor inconvenience is that during the transition period the PVP client will, in the worst case, try both the experimental and the standard method. This can be prevented if the PVP client explicitly knows that a specific standard method replaces a specific experimental method. The simplest would be to add this in the list of data that the RFC defining a new method must provide. Then we just need some text in -pvp that says that a PVP client must only try the standard method if such relationship exist and if the ViprRegistration record contains the two methods. So lets say that domain A developed a new experimental method x-z and is testing it with domain B, so they both publish all their phone numbers with {x-z,a,b}. Later A decides to publish an RFC that assigns z to the same method. Domain A updates all its phone numbers with {x,x-z,a,b}. Domain B still had not updated so it does not use x. Domain C updates with {x,a,b} and start using z with domain A. Later domain B updates with {x,x-z,a,b} and now when verifying with A has the choice between x and x-z. Because the implementation of x knows that it is a replacement for x-z, it simply skips x-z if both are present. Now the last missing piece is to know when domain A and domain B should stop publish ViprRegistration records with x-z. I propose to also ask the authors of the RFC defining the new method to put a date limit in the spec. That would look something like this: 'The method name defined by this document, "z", is a replacement for the experimental method "x-z". Implementers MUST stop adding method name "x-z" in published ViprRegistration records two years after the publication of this document as RFC.' > > On Feb 13, 2012, at 12:46 PM, Marc Petit-Huguenin wrote: > > Instead of trying to fix everything at the same time, I decided to release > incremental modifications of the VIPR specs. > > This new version of -vipr-pvp adds some text establishing the IANA > registry for PVP methods, as was agreed (section 11). Some details I added > since the last time we talked about this: > > - Private methods start with "p-" and cannot be used between domains[1]. - > Experimental methods start with "x-" and the reversed domain. > Experimental methods may be registered by IANA. - The algorithm to assign > priority is to use the median between the next method and the previous > method to try. This means that method "a" has a priority of 0, method "b" > has a priority of -16384 ((-32768 + 0) / 2), and method "c" will have a > priority of 16383 ((0 + 32767) / 2) if we decide that it should be tried > before method "a" or -8192 ((-16384 + 0) / 2) if we decide to try it after > method "a". - Multiple methods can have the same priority (I think that we > talked about this in Taipei). > > Comments, questions, suggestions welcome. > > Thanks. > > > [1] The reversed domain name is mandatory for private method, which does > not make sense. This will be fixed in the next version. > > -------- Original Message -------- Subject: I-D Action: > draft-petithuguenin-vipr-pvp-03.txt Date: Mon, 13 Feb 2012 11:30:14 -0800 > From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: > i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : The Public Switched Telephone Network (PSTN) Validation > Protocol (PVP) Author(s) : Marc Petit-Huguenin Jonathan Rosenberg > Cullen Jennings Filename : draft-petithuguenin-vipr-pvp-03.txt Pages > : 31 Date : 2012-02-13 > > One of the main challenges in inter-domain federation of Session Initiation > Protocol (SIP) calls is that many domains continue to utilize phone > numbers, and not email-style SIP URI. Consequently, a mechanism is needed > that enables secure mappings from phone numbers to domains. The main > technical challenge in doing this securely is to verify that the domain in > question truly is the "owner" of the phone number. This specification > defines the PSTN Validation Protocol (PVP), which can be used by a domain > to verify this ownership by means of a forward routability check in the > PSTN. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-petithuguenin-vipr-pvp-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-petithuguenin-vipr-pvp-03.txt > - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPRlqRAAoJECnERZXWan7EMtgQAOJT+jHC0F8YCcGSzquMvIsr Ur0KXK6usTv8VZmojXBUOmqNLQMB/31Q3rsVV4bAY1o9HQt+xrfBUORzMKi3Sbfw JmEbanLVB+lJXsZd5I7J70hMy5CxYzZgFJZoZ/c7RNYgkwKeMsZm2cNpiVR1GRSn JefSmEC3cnLLT+vzUDhIFgkWyK/vTHmfNLAxqNBWUw2qLUHlR6B5QPJNt0W8vjtz N+BSPjRPgZ61vINP76ZhMtQImiw1wYQ9I1r/lbXONE8TrcrVU0ZB9QnqjvzFTMtz QMvMWRPgzCX7wzwqtC+QfRYoWPVoElW0vThZ5056x2XoirCo2JT1cPx77RxPtKdS /qgprrImY3Db4RPZIdUVE110k+PB6aQhqaOLFTTtMttLCngFwxayQLKBmaojmyZZ 7skGE5xfIEkW/s5WTZztpDXTYGoK3aL1zdyRP4Mvq0COXF5Y1A7RWDYTE/cAhk4h 7audiQ5916gaRm09BaCNiyf4mtgiB43VXa2YLidu2TbF9z4fS5waJ4fNlel35P// qgTJiAxumAtUviMKQK6bW/zHi1XZiH/N1WsjZ2vGqfmt+LUABKdn408jrsfEaxir 9JMtnzBwTCr4LDP4rgxXUWpAcj1y27zo6fmpqcIVRC4WmA4NapVul+7R2iocGb+X alo8FeeN8+NcKg8ot7+F =m3b/ -----END PGP SIGNATURE----- From petithug@acm.org Thu Feb 23 07:50:46 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFC821F8729 for ; Thu, 23 Feb 2012 07:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.385 X-Spam-Level: X-Spam-Status: No, score=-102.385 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ImYNTY62P4i for ; Thu, 23 Feb 2012 07:50:40 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 7101821F8692 for ; Thu, 23 Feb 2012 07:50:40 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 7D69320414 for ; Thu, 23 Feb 2012 15:34:35 +0000 (UTC) Message-ID: <4F46604D.4070302@acm.org> Date: Thu, 23 Feb 2012 07:50:37 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120216 Icedove/8.0 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [VIPR] Weekly conference call X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 15:50:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 There is only 3 weeks before the cut-off for publishing new versions of the VIPR drafts, and this week we are still without topics to discuss in the conference call. It is also very likely that no new I-Ds in the topics of troubleshooting, infrastructure and SIP intermediaries will be published before the meeting in Paris (but help is welcome). So I propose to stop scheduling the Friday conference calls for now. Thanks. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPRmBIAAoJECnERZXWan7Eq1UP/1gFzxZkKE9ZPLzeBFCOi9UX MZOSTtDBI2ClTFss3AmzCtjMRdjJqkYM5NOTnVgOoskJJ+hdRn7EbRMTRoRpn78Q jOZ1XRQ6g4QetiSBJeILB4om85VxXdMc5+YzGWuVXU+YFvCjGNThxXHF+kMczbhH fKajdWOzq6sEGiO5OdrWUv/DAr46wiAemxsX58/IYEYMTWK4jnf5unkbE7TIi+K+ sdHIkytSDe0dHJG1MOZB10TXPioTCvsjcfbvv59+2z2+ZM9HahncMOMIf3gtzlSf 24b3Xnw3rX8uRIRiyQbVD4iJDwOou/hoSbfe1PxBwgq0MkffW6ll+WyhStTAO5kh UhZdAzJA65BB8fi1fnUz8lK6f7jnckIPwWjOiOnBBEx6QE5qBKMswr46/BJkwYpl Y+3BRIp4BJ8xFzMvi4xZQ9BGPdFwohTQ6LbKLhxO6lvm07vdK4fv9t6N4l/QXrDt AnNFZ5calzaSqhfDLWI3cUiX0h9gIFod6IeiW1B7PjCZUfwqS1UyIQ4yHHYRvmW5 9AEP4muGmg2KcHW2mh8DAorZynPOa39blxhN76cbSB2oIfCYaZJ29E4g7SXfiTaR zO3ak134ReMAL9IMLoXnfUDLCFqdVr2xUdifaAbnjxTgIwjbSChiYBv9aDyclQBk Dwn979osB3jEuGjbcNPl =L9MK -----END PGP SIGNATURE-----