Re: [VIPR] VIPR privacy issue

["Richard L. Barnes" <[e-mail]>]

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

Doesn't really seem like a RELOAD issue.  Rather, something for higher/lower layers.  Pay someone to do RELOAD on your behalf, or use a VPN to somewhere else.  Agree with a group of friends that you'll all make the same queries at the same times, so that your individual patterns are indistinguishable.  OPSEC, not COMSEC.

--Richard




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