Re: [VIPR] VIPR privacy issue
Marc Petit-Huguenin <petithug@acm.org> Thu, 26 January 2012 16:18 UTC
Return-Path: <petithug@acm.org>
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 B64A521F8690 for <vipr@ietfa.amsl.com>; Thu, 26 Jan 2012 08:18:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.174
X-Spam-Level:
X-Spam-Status: No, score=-102.174 tagged_above=-999 required=5 tests=[AWL=0.426, 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 IfU-bEuc55iy for <vipr@ietfa.amsl.com>; Thu, 26 Jan 2012 08:18:21 -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 7350B21F868C for <vipr@ietf.org>; Thu, 26 Jan 2012 08:18:21 -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 CC52B202D2; Thu, 26 Jan 2012 16:04:01 +0000 (UTC)
Message-ID: <4F217CC9.4080802@acm.org>
Date: Thu, 26 Jan 2012 08:18:17 -0800
From: Marc Petit-Huguenin <petithug@acm.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0
MIME-Version: 1.0
To: "Richard L. Barnes" <rbarnes@bbn.com>
References: <4F1F1A42.1030201@acm.org> <9734F726-C0A8-42D6-87A4-65535D5F3E80@bbn.com>
In-Reply-To: <9734F726-C0A8-42D6-87A4-65535D5F3E80@bbn.com>
X-Enigmail-Version: 1.3.4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "vipr@ietf.org" <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 <vipr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vipr>, <mailto:vipr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vipr>
List-Post: <mailto:vipr@ietf.org>
List-Help: <mailto:vipr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vipr>, <mailto:vipr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jan 2012 16:18:22 -0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/26/2012 08:01 AM, Richard L. Barnes wrote: > Let's not get hysterical here. These issues are inherent to any system > for resolving identifiers. My local DNS resolver has a very good idea of > things like what websites I'm visiting (A google.com) and what services I'm > using (SRV _xmpp-server._tcp.jabber.org). Yes, but this is not the problem here. AFAIK, it is not possible for anybody to add its own DNS server as nameserver of google.com and receive all the requests sent to this domain and collect the source IP addresses. *That* would be the DNS equivalent of the privacy leak of VIPR. > > Analogous mitigations apply, e.g.: > > * For masking sources of requests, use indirection. In the DNS context, > authoritative servers don't see my IP address because I go through a local > resolver. In the VIPR context, you could have an outsourced RELOAD agent > acquire tickets on behalf of clients who trust it to handle call > information. > > * For masking destinations of requests, use multiple requests. In the DNS > context, request names/RRtypes other than the one you're looking for. In > the VIPR context, look for numbers you didn't dial, or look for numbers > when you haven't dialled anyone. > > Note that in both cases, the mitigations are about how you use the > protocol, not the protocol itself. So while it might be worthwhile to > write up a privacy considerations document, it doesn't seem like we need to > change the protocol documents to deal with these threats. The concern is not how to fix the problem, but that half of the problem comes from a protocol (RELOAD) that is not under our control, and so will take years to bring to a point where we can fix this problem. > > --Richard > > > On Jan 24, 2012, at 3:53 PM, Marc Petit-Huguenin wrote: > > Michael Procter explained on the last VIPR design team weekly conference > call a privacy attack that I think is devastating. The end result is > simple to explain: VIPR turns the Internet into a "trap and trace > device"[1], allowing anybody to record the phone numbers called by any > entities using VIPR, and this for a relatively low cost. > > Let's say that VIPR is well deployed in US enterprises and that a spying > group is willing to spend the money to know about the phone calls made by > these enterprises. This spying group just have to add enough VIPR servers > to the RELOAD overlay to register all the phone numbers in the USA. > Because all registrations are considered equally untrusted, they will all > be verified by establishing a TCP connection between the VIPR server of the > source of the call and the VIPR server that stored the registration for a > particular phone number. There is multiple pieces of information that are > leaked but it is easy for example to find the enterprise that is > originating the TCP connection by looking at the source address and to > enter it in whois. > > As Michael pointed out, you have to be on VIPR to protect your privacy, i.e > destination numbers that are *not* using VIPR are especially at risk. If > the destination number is using VIPR, the TCP connection used to verify > the first call from any enterprise has a lower probability to be directed > to the spying group, because the real owner of the number may be tried > first and prevent other registrations to be tried if successful. And as > soon the real owner sends a SIP route and ticket back, the spying group > will no longer receive any information about the calls between this > enterprise and this destination number, excepted for the periodic renewal > of the ticket. > > Note that the information leaked go deeper than just the verification > connection. Here's the various places where privacy information leakage > happens with this attack: > > - If the spying group uses a different VServiceId for each registered phone > number, the called number is always leaked. - The called number is also > leaked for methods A and B. - For method "A", the Caller-ID is leaked (the > bcrypt hash is hard to crack, but it is not impossible). - For method "B", > a random time in the middle of the call is leaked. - For method "C", the > rounded start and stop time of the call are leaked. - The source IP > address of the TCP connection for the PVP transaction is always leaked. - > The addr_port in the AppAttachReq RELOAD message that was used to establish > the TCP connection is leaked. - The certificate of the signer of the > AppAttachReq RELOAD message is leaked. Even if the certificate does not > contain information about the sender (subject, subjectAltName), it always > contains the Node-ID, which can always be resolved to an IP address by > using an Attach request. - The Node-ID is leaked a second time in the > via_list of the AppAttachReq message, unless an intermediary RELOAD peer > replaced it with a compressed ID. > > There is probably ways to fix all of these leakages, and I found solutions > for most of them, but they make RELOAD and VIPR much, much more complex, > to the point that I am starting to think that RELOAD itself is not up to > the task. Using TURN to anonymize, as I proposed, does not work because of > the multiple places where data is leaked and fixing RELOAD itself, which > will require among other things adding something like onion routing, will > probably take years[2]. > > At a minimum, we will need to add a strong requirement about required > anonymization in -overview, but it is clear to me that the standardization > of VIPR will take a much longer time than expected. > > > [1] http://en.wikipedia.org/wiki/Trap_and_trace_device [2] > http://www.ietf.org/mail-archive/web/p2psip/current/msg06166.html > >> _______________________________________________ VIPR mailing list >> VIPR@ietf.org https://www.ietf.org/mailman/listinfo/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) iQIcBAEBCAAGBQJPIXzHAAoJECnERZXWan7EiA0QAOKtZJVXEwoGO9Jb0ZO7xVoO 1jbFj5DsMU2ECPO6kgApZYE90LMAlLdqOV7E5ke+ovLy5GUuLSQwfOiMOCnbTJWP 9nGbHgv0n1ro5FpBLvHKhyBGBFTYcnxFz5fdDVEjMBnJxHIzMfE7GU53G5195SP5 mx0SstXRD5Ha3ckp/9sMpSrIhZ2OYOghH/XGvjrjqgDOIuB7ws4WqR9UewDrgTzI PGDFpliRY1URnFln/a+0jQwOPqm9ggLqQASnJuLdVA4IsuYsQYfxe7IdXFjj+6fZ ylEkekJNOqSYMgs0nprwUk94y7zCrzdBZOTRVSPWX872Wv5SKbA6hRA1lc8J0VFK VxY7xsIgm60W31u2deLvsBBpamvARC+6Y6wf9L+jcyvzoAr1klfqoh3Al0DxJkEa HFJmQbf8r28cWinXx/OhWr6ZdXTqAKcgv+9/M1AROacnH/cwd4Tqg08sI219D02d 1rRkj857OkEQN7iZcVWZI9B87s3K0zow72TCuXS/KXO5F0GZq8XuzVhGNzCvwPnB PghyKlbTzj2f3Xvpgq+T7lOh3gK93qd225zB0wqIeDR62f2ZXpODFdm+POMBoFME AYtHFiXH8Qim/dR5YJSGS9WJZgjljJX67z0K3i0vDqS/FxwCuPZCWOosZ/FgmpZk uZR/vHy1V1J/49djBaKc =jNuY -----END PGP SIGNATURE-----
- Re: [VIPR] VIPR privacy issue Marc Petit-Huguenin
- [VIPR] VIPR privacy issue Marc Petit-Huguenin
- Re: [VIPR] VIPR privacy issue Kevin P. Fleming
- Re: [VIPR] VIPR privacy issue Kurt Bergsbaken
- Re: [VIPR] VIPR privacy issue Richard L. Barnes
- Re: [VIPR] VIPR privacy issue Marc Petit-Huguenin
- Re: [VIPR] VIPR privacy issue Richard L. Barnes
- Re: [VIPR] VIPR privacy issue Marc Petit-Huguenin
- Re: [VIPR] VIPR privacy issue Richard L. Barnes
- Re: [VIPR] VIPR privacy issue Marc Petit-Huguenin
- Re: [VIPR] VIPR privacy issue Dean Willis
- Re: [VIPR] VIPR privacy issue Marc Petit-Huguenin
- Re: [VIPR] VIPR privacy issue Richard L. Barnes
- Re: [VIPR] VIPR privacy issue Mary Barnes
- Re: [VIPR] VIPR privacy issue Kurt Bergsbaken
- Re: [VIPR] VIPR privacy issue Cullen Jennings
- Re: [VIPR] VIPR privacy issue Cullen Jennings
- Re: [VIPR] VIPR privacy issue Cullen Jennings
- Re: [VIPR] VIPR privacy issue Marc Petit-Huguenin
- Re: [VIPR] VIPR privacy issue Cullen Jennings
- Re: [VIPR] VIPR privacy issue Richard L. Barnes
- Re: [VIPR] VIPR privacy issue Marc Petit-Huguenin
- Re: [VIPR] VIPR privacy issue Kevin P. Fleming
- Re: [VIPR] VIPR privacy issue Dean Willis
- Re: [VIPR] VIPR privacy issue Marc Petit-Huguenin
- Re: [VIPR] VIPR privacy issue Cullen Jennings
- Re: [VIPR] VIPR privacy issue Marc Petit-Huguenin
- Re: [VIPR] VIPR privacy issue Marc Petit-Huguenin