Re: [VIPR] VIPR privacy issue

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

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

On 01/26/2012 08:52 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.
> 
> 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.
> 

Yes, and my original proposal was to use the TURN servers that are already
present in the RELOAD overlay to hide the source of the PVP connections.

But after last Friday's call I worked on establishing an exhaustive list of
the places where data is leaked.  Some information are leaked by the SRP-TLS
protocol, but we already worked on that in the WG and are making progress.  No
concern here.  The source IP address of the PVP connection can be hidden by
TURN or any of the other solutions you proposed.  Here also, no concern.

Then I started to dig deeper in RELOAD itself, which is used to pass the
information to establish the TCP connection used for the SRP-TLS exchange.  If
we use TURN or a similar mechanism, then the source IP is also hidden.  But
the message used for this (an AppAttachReq RELOAD message) also leaks data.
The RELOAD messages are authenticated end-to-end, so it is really easy to
extract the certificate of the sender, then the Node-ID of the sender and use
an Attach (a transaction that is part of the basic set of transactions
required for RELOAD) to find the IP address of the sender.  The same data is
leaked a second time in the via_list.  So that's two additional layers that
require some work to be made anonymous.  And this is where I have concerns. I
(and others) have seen our RELOAD extension proposals delayed for the last two
years in P2PSIP, so even there is no doubt that we can fix the privacy issues,
the problem is more in the time required to fix them.  Cullen's email in
P2PSIP was unambiguous in saying that doing this will push VIPR to 2015/2020.

Let's see a concrete example.  I want to know all the calls made by VIPR users
to all the phone numbers (VIPR or not) in the USA.  For each of these numbers,
I register my VIPR server with a different VService-ID:

Rogue                                RELOAD
  | Store([phone]=rogue-Node-ID)  |
  |----------------------------------->|
  |                                    |

Someone with a VIPR enabled phone make a call to *any* of the US phone
numbers.  In this case, because [phone] is not VIPR enabled, the caller
cannot already have a SIP route, so the RELOAD distributed database is queried:

Rogue                                RELOAD                        VIPR Phone
  |                                    |    Fetch([phone])=Node-ID |
  |                                    |<-------------------------------|
  |                                    |

The next step is for the VIPR phone to execute an AppAttach transaction:

Rogue                                RELOAD                        VIPR Phone
  |                                    |                                |
  |                                    |   AppAttach(phone-IP)=rogue-IP |
  |<--------------------------------------------------------------------|
  |                                    |                                |

The AppAttach request contains the IP address of the PVP client - that's the
first leak.  The AppAttach request is signed by the certificate of VIPR phone.
 That's the second leak.  The AppAttach request also contains the Node-ID of
the VIPR phone in the via_list, so RELOAD can route back the response.  That
the third leak.

Then the VIPR phone starts a TCP connection to the PVP server, using the IP
address returned in the AppAttach response:

Rogue                                RELOAD                        VIPR Phone
  |                                    |                                |
  |                                    |              TCP establishment |
  |<--------------------------------------------------------------------|
  |                                    |                                |

That's the fourth leak.  Next step is to establish the SRP-TLS session:

Rogue                                RELOAD                        VIPR Phone
  |                                    |                                |
  | Client Hello                       |                                |
  |-------------------------------------------------------------------->|
  |                       ServerHello/ServerKeyExchange/ServerHelloDone |
  |<--------------------------------------------------------------------|
  | Alert                              |                                |
  |-------------------------------------------------------------------->|

We know that the 3 PVP methods leaks some data but first as the rogue VIPR
server used different VServiceID for each registered phone number, and as the
VServiceId is sent in clear in the SRP-TLS exchange, the rogue server knows
the called number.  Then for method A the hash of the Caller-ID is also sent
in clear.  For method B a random time chosen in the middle of the call is sent
in clear.  For method C the start/end time of the call are sent in clear.

Again, we can fix all of these.  The problem is that we cannot fix the RELOAD
issues in a timely manner.

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

iQIcBAEBCAAGBQJPIaEfAAoJECnERZXWan7EHjYQALwGDeCdRFLOzinFviR8WTfw
z86vZFWhL2+Bzxnc50cFZY8uav9CBgN9xpLBRIklXvlhwyWxwossUAASE/b7BCQr
SaspiMW3oijv3jjPdPyqUuFNMYJFxf+mS+MOwwd+TnUUVLMQZBi7vI9lsbOegWLm
30jaY1NfBscgqzJPDY3hgbp56R31cGTYl7scE4WndudNA0wr7QeratzvQa3rm9OI
XzGXJGaFtuXEG9KTC/cDJiXM23CtDCq9rFmA+6P5FkaVIsG/YDQi4gPYIiUT7vvv
YXdHhVaOa7GZVUbOYjoi73J898iRtzyBoZtEvE50CbHs91PYw7PuXaqF0KYF6zfU
82pXh+Wvlw+O5l+X/6EfWj3cjTMY5bBueP2VBtIsmz+iqEKY63PCNGWUaOiyOCbv
5lRjFVLlqjxvL/jJoCOf7Hrvw67NpOcx/ZZyXfF883enb+E2z1f+qvK26VKkOLG4
2gSThVi+SypDyw5MId0tNGp4DXVD4x9oepc5kqYooiNAjFkY4Q3HBAqCHmcbgYvn
qa/lUEelPryQ3ojbhgXfww8H8axHsmh0o0np/8JlpDQmQJ5CBBavMY00gZdgyF1z
syesITpMgkpIhj5qQjsMd6gSRGu8RLPClg1fK/BPDLHwBUF2tMkJmCvAHwQK9etv
1eYCUlXRb9AUBhshZMrY
=XNF7
-----END PGP SIGNATURE-----