Re: [VIPR] VIPR privacy issue

[Marc Petit-Huguenin <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 01/26/2012 08:40 AM, Richard L. Barnes wrote:
>> 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.
> 
> True.  Although in principle anyone could announce the anycast prefixes
> used by the root nodes (in the absence of SIDR deployment), which would get
> you lots of interesting traffic.
> 
> At the very least, however, your queries get forwarded to the DNS root and
> intermediate name servers, which has been a problem before: 
> <https://lists.dns-oarc.net/pipermail/dns-operations/2010-March/005266.html>
>
>  Like I said, the mitigation here is the same as any situation where you
> want to hide your IP address: Send packets from a different network.

Yes, and (I am not sure you saw the second part of my response below), this
would not be a concern if we could fix RELOAD to do exactly that.

> 
> --Richard
> 
> 
> 
>>> 
>>> 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
>>> 



- -- 
Marc Petit-Huguenin
Personal email: [e-mail]
Professional email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJPIYPOAAoJECnERZXWan7Er+QP/iqC1BvcJkFilL5tJaQpXEMp
Nc6eWH6cEKUpL4Q6gBRhYk7CD0k3CFmNTGEblhjKhZAsLILicdUIUeAsXN8JFFdD
Bxf2D99R2t24qrMwBzmOhRUNoV3JryNDOH0S5qFbCZ564WKPdfLrrPRdYfedTBXo
H7sm7THDrSNuNLUDejLtRmpLG4CENjSOJe4RMnUkgMb2ikG3OfpRPp3VexKE9prN
HO6sJ0IBWtdGt/p0K8CE4xsG2Kg3CYz4v65A7YefQ/6YKy4nk4rfW6fBEchEqApL
xRRsoxvSOzNXDHRZqOZiQbrP1qxupAIU43ladvf7Hx4Y9c22uxkw5818o4EJJ0pZ
XD03Aml4gCVzl5Mg/X8/4D9oR9GFieeKjXvKO/Y/5LHSC7l/hCVkz/f+2jiSqvtd
BfOz9xfxBqIhU3l0x29euur6nO2k0LMYIaulDgp4Rmd1UAY6JqtFoloCjAJrFGFf
0fYjzoI4Lxa+Qknh7Rt3it2JUKooUO3qjygF6CuQ23aB8x2pRZGbZeUp0pvPbb8O
AoxeIAF5Bk9JwOb0WfA//g7oKBwZCh0dTRXhL1YycxIlk63LTpMbOdO8VHxSB8GA
hbDmMina7oqPBJV/lgJIuolWt3MyYv6EZTaCNXiAJm02HBY+5328P9Lm15KOwlZT
7MnhkdbhrQYOjijmKJZb
=Kp7M
-----END PGP SIGNATURE-----