Subject: [VIPR] VIPR privacy issue

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 24 Jan 2012 12:53:22 -0800

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: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 24 Jan 2012 16:20:17 -0600

On 01/24/2012 02:53 PM, Marc Petit-Huguenin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>

A very similar point was raised during the last in-person VIPR meeting 
that I attended (two IETFs ago, I think). I commented that we had 
personal experience with this problem in the Asterisk world, years ago 
when we had a public DUNDi cloud for routing E.164-numbered traffic. It 
is one of the primary reasons that many of us (I was not with Digium at 
the time) stopped using that cloud.

I'm certain that as you say, these problems are not intractable, but 
providing solutions for them may very well make VIPR (and similar 
mechanisms) so complex to implement and deploy that nobody will choose 
to do so.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [email-masked] | SIP: [email-masked] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 25 Jan 2012 09:54:39 -0800

On 01/24/2012 02:20 PM, Kevin P. Fleming wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>> 
>> 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.
>> 
>> - - 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].
>> 
>> anonymization in -overview, but it is clear to me that the
>> standardization of VIPR will take a much longer time than expected.
> 
> A very similar point was raised during the last in-person VIPR meeting that
> I attended (two IETFs ago, I think). I commented that we had personal
> experience with this problem in the Asterisk world, years ago when we had a
> public DUNDi cloud for routing E.164-numbered traffic. It is one of the
> primary reasons that many of us (I was not with Digium at the time) stopped
> using that cloud.
> 
> mechanisms) so complex to implement and deploy that nobody will choose to
> do so.
> 

Perhaps, but my current concern is not complexity.  VIPR is highly dependent
on RELOAD, and half of the leakages come from RELOAD itself.  We have a good
design team in VIPR and we - slowly but steadily - find consensus on a lot of
of the issues that are pure VIPR.  But on the RELOAD side, no amount of energy
spent seems to help accelerate things.  I even considered forking the RELOAD
spec to have at least a decent subset that VIPR can use and adapt to its
needs, but it's probably not legal, and anyway prevent reusing standard
implementations of RELOAD for VIPR.

So our options as I see them:

- - Stop the work on VIPR until RELOAD reaches a point it is usable.
- - Forget RELOAD and replace it with another mechanism.
- - Close VIPR.

We will probably spend the whole of our conference call next Friday on this
subject (everybody is welcome to join, just send an email to the chairs and I,
and I will send back an invitation).

Thanks.

- -- 
Marc Petit-Huguenin

---

From: Kurt Bergsbaken <[email-masked]>
Date: Wed, 25 Jan 2012 23:07:38 -0500

I. would appreciate an invite to  this design call,  if possible.    Thanks.

Kurt Bergsbaken | Architect -SIP Voice Services | Univision Communications Inc. | 8550 NW 33rd Street, Miami, FL 33122
Direct: (305) 463-5745 | Fax: (786) 515-9229 | [email-masked] | www.univision.com

----- Original Message -----
From: Marc Petit-Huguenin [mailto:[email-masked]]
Sent: Wednesday, January 25, 2012 12:54 PM
To: Kevin P. Fleming <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [VIPR] VIPR privacy issue

Thanks.

- --
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
_______________________________________________
VIPR mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vipr

The information contained in this e-mail and any attached 
documents may be privileged, confidential and protected from 
disclosure.  If you are not the intended recipient you may not 
read, copy, distribute or use this information.  If you have 
received this communication in error, please notify the sender 
immediately by replying to this message and then delete it 
from your system.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 26 Jan 2012 11:01:28 -0500

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

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.

--Richard

On Jan 24, 2012, at 3:53 PM, Marc Petit-Huguenin wrote:

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iQIcBAEBCAAGBQJPHxo6AAoJECnERZXWan7EV0kQALf+0G+bdOj4t3GiNSk1rjKC
> 7Zbnz4cqiJrmmJl3PjISQy8t+yXEngEO2vmM9ewkb9i4tZV0fV+UNv4Wpxfs2XF1
> p/VRZ8gKAGiNfSgY2aGXDtErEaV33Rkuh+iQUVd+FsYTc2lSUDPnRFXD9dfO4GuK
> FIJKnf3Wm9yK37zN8X+kS9ynrEzTXDKD1V1kfW8JgEne6KkL7wwhH/NWAXKbT3F+
> o0RsWbM2Kft9aCmzRtBSgzNRiVb1G6asD8LaETXImEPhP0ScySnul7sqeXg4un5o
> ipVwjiAuKy6sPsOJoXD26fePzMbymrtKL6R3Lv/YM9W9ae3cQo3JrjShEwYhVETY
> c0leYotFBSDELu3jv2sqfF1ij9I+XXD9gUT8eOd/XV/xBKvvEr06xQ9tc7E72e1C
> hEpINusiMYNW1nWvL7WvJNbQU4KaojyF6I2uGLQss8UKBYvYBU4+oIkg6F0bF3GA
> c5yxdEVOg1Tkn88yiUI4O3pOS1yuscsUBlduOKQsNvKZQWd6Y1eikODU44Ea2hRr
> JlsQz5Azh7PY07a6dD7VmdS36wA0N+JbPpL6pvgf0r5tfxoWAcfoyZ2gtgEsFf6Y
> CLaySla7kUaVVzjhe9tsccG3FmdpnDS8wQjJ/47FI/hnCUfv02FOAHWzALRNZgfF
> nTxixgP8OeOKecgd8ll8
> =LV2v
> -----END PGP SIGNATURE-----

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 26 Jan 2012 08:18:17 -0800

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.

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

> 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.
> 
>  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
> - 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].
> 
> 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 
>> [email-masked] https://www.ietf.org/mailman/listinfo/vipr
> 

- -- 
Marc Petit-Huguenin

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 26 Jan 2012 11:40:18 -0500

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

--Richard

> 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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 26 Jan 2012 08:48:16 -0800

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

>>> * 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.
>>> 
>>> 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
>>> 
>>> 
>>> 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
>>> 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.
>>> 
>>> 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.
>>> (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
>>> 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].
>>> 

- -- 
Marc Petit-Huguenin

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 26 Jan 2012 11:52:31 -0500

> 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

> 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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 26 Jan 2012 10:53:21 -0800

On 01/26/2012 08:52 AM, Richard L. Barnes wrote:
>>>>>  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.
>>> 
>>>  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: 
>> 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(+14085550001=rogue-Node-ID)  |
  |----------------------------------->|
  |                                    |

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

Rogue                                RELOAD                        VIPR Phone
  |                                    |    Fetch(+14085550001)=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

---

From: Dean Willis <[email-masked]>
Date: Thu, 26 Jan 2012 15:28:31 -0600

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

So we should run a great big VPN in order to run RELOAD in order to run ViPR?

Great! Now all we need is a peer-to-peer VPN capable of obscuring the IP addresses being used.

I'm trying to imagine just how badly the universe would break if one tried to run RELOAD over TOR. I don't think I have that good an imagination, because scenes from the movie "2012" pale by comparison, and I'm sure the real situation would be far worse than what I imagine.

But this does all come back to why I haven't been able to convince myself of the real-world utility of ViPR. We're layering vast complexity onto what is basically a distributed  trust-anchor problem, where the easiest thing to do in the real-world is to have a centralized anchor (which might itself refer to the PSTN basis anchor).

How about an alt-root DDNS/ENUM server that itself uses PSTN reachability to verify registrations submitted via DDNS?

--
Dean

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 26 Jan 2012 13:38:52 -0800

On 01/26/2012 01:28 PM, Dean Willis wrote:
> I'm trying to imagine just how badly the universe would break if one tried
> to run RELOAD over TOR. I don't think I have that good an imagination,
> because scenes from the movie "2012" pale by comparison, and I'm sure the
> real situation would be far worse than what I imagine.
> 
> But this does all come back to why I haven't been able to convince myself
> of the real-world utility of ViPR. We're layering vast complexity onto what
> is basically a distributed  trust-anchor problem, where the easiest thing
> to do in the real-world is to have a centralized anchor (which might itself
> refer to the PSTN basis anchor).
> 
> How about an alt-root DDNS/ENUM server that itself uses PSTN reachability
> to verify registrations submitted via DDNS?

That may be worth investigating, but the first thing that the WG should
answer, IMHO, is do we want to 1) give up, 2) delay for RELOAD, or 3) replace
RELOAD?

- -- 
Marc Petit-Huguenin

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 26 Jan 2012 16:47:36 -0500

Or (4), don't worry, be happy?  :)

Seriously, the question is whether the group feels that these privacy risks merit changing the work that this group is doing, or whether the benefit of ViPR is enough that exposing one's IP address is a tolerable risk.

IMO, it seems like there are enough operational mitigations to these risks that no fundamental changes to ViPR are needed.  But I maybe I'm misunderstanding; it's been a while since I've thoroughly read through the documents.

--Richard

On Jan 26, 2012, at 4:38 PM, Marc Petit-Huguenin wrote:

> iQIcBAEBCAAGBQJPIcfqAAoJECnERZXWan7E6sQP/2jBmenEmlsQ+Pe5V1F/qn7e
> kSQjw6EuUGKjz5oONhsbEw2N4kAHwtivQlfriJoT4NxeYspWWvg+13Btb4+OlTFU
> QNAU9rY0Zd+AZJvFBII70TGjKl5aRZ5G7LRmgfsyp88OAODs9FtHRVzTtQVSTbEV
> ZYWtzYXRWcYosH+9sML7vFn8gf5njDsR0pTEV1Xt+DVdVbec+MV35zHmX8gOtR84
> +s/LalXe8rPUdmDV7qAHHZir9gCj2FmSuJlb2KGr3IfEj+mD1FeRTfsN8bhtE0zZ
> cfg8yAYjLgvNy7O7ZXFN8GIQx40StJqRXCxuzrJ0CHHDlS3NJ8vv8IVM8mlMIt0d
> UaHnC4DcU3yQGFNGe+f3cG1KrtAIsDTUJyyppsra4Q41dP4eporG8uWZDbIJwDMI
> Jg7nwSJD6RJ8qL6zgWl1gNyfRXOKG3s3Wt8Oy/l00Q837N8+KxGRA7WeEu0PMjkR
> 8d1C/i4dPymKVA5FsdPatG+/dHee8FzbYKriGOmCXsGhx5+rcW3m3tVE+lpzqBZ9
> 0dysmnJmjNJUcsHIp+o+CWKd5FcSewxfNMHy762lmJME7srDVzENd8rWi5luHVWn
> k1KviQe82XaV6PhKb6/K3rSSotNAPKwkSiIvSsuaOeDv1Wmzi472Mp/BX0M2/s9p
> 5hv+PEtbfXzcNBh+zW3r
> =OqpG

---

From: Mary Barnes <[email-masked]>
Date: Thu, 26 Jan 2012 15:49:22 -0600

Unfortunately, options 2 and 3 introduce delays that decrease the
relevance/utility of VIPR , which in my view has significant near term
(i.e., now) value, but in the long term is likely to be far less
useful.

Mary.

---

From: Kurt Bergsbaken <[email-masked]>
Date: Thu, 26 Jan 2012 17:34:21 -0500

Are there viable candidates to displace RELOAD that could be shovel-ready within the acceptable event horizon?

----- Original Message -----
From: Mary Barnes [mailto:[email-masked]]
Sent: Thursday, January 26, 2012 04:49 PM
To: Marc Petit-Huguenin <[email-masked]>
Cc: [email-masked] <[email-masked]>; Dean Willis <[email-masked]>
Subject: Re: [VIPR] VIPR privacy issue

Mary.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 26 Jan 2012 17:27:58 -0700

Few comments about this ...

As pointed out before, if someone is willing to buy enough certificates, all P2P systems I am aware of become insecure in some way. The mitigation to this is to price certificates appropriate and also to be able to detect that someone is doing this and be able to black list them off the DHT. I will note that GoDaddy has many constraints on issues the certificates people are currently using and one of theses is a minimum price. I will also note the more nodes are on a reload ring, the more expensive it becomes to compromise it. And that is is possible to figure out which certificates are being used by nodes which are publishing your number when they should not be. 

For some of the attacks on ViPR, the best defense is to make sure your PSTN numbers are registered. I view this as  feature of the design. I'm sure opinions vary on this. 

I don't think there is anything stopping you from forking the RELOAD draft. But my limited energy will be on the WG draft not some fork of it - I think I fail to see how forking RELOAD will help. The idea that replacing VIPR with some yet to be determined protocol will help speed things up, ah, - lets just say I find that very unlikely. If someone would like to clarify what it is they need RELOAD to do that it does not do, I'd be happy to scratch my head about ways to achieve that. If one of the problems is the attacker can learn the IP of the PVP which reveals the owner, how about running you PVP on Amazon EC2 or whatever you like.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 26 Jan 2012 17:28:00 -0700

On Jan 26, 2012, at 11:53 AM, Marc Petit-Huguenin wrote:

> Cullen's email in

That is not at all what I said. The 2020 was a date where I think we might be possible to have a location privacy solution. As folks may recall from the BOFs when P2PSIP was formed, Cisco had expressed that one of these cases it was interested in was when the communications were not at all anonymous but the location needed to be. The example used as Vice President of the US during an emergency may be moved to a location that is kept very secret but they need to communicate security and with authentication to a large number of people. Todays internet protocols don't offer much in the form of location privacy - with the possible exception of TOR. Some person with General in their title even showed up at Vancouver and Prague IETFs. When P2PSIP got chartered, location privacy got drooped out because it was viewed as it would just be too much to solve. I think I argued for doing location privacy at the time but I was wrong - it clearly would have been too much to do in the first version. 

However, I still hope that we might have a standards based location privacy system by 2020 but others think it is better to do this type of thing just a a proprietary system so who knows.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 26 Jan 2012 17:28:02 -0700

On Jan 26, 2012, at 2:38 PM, Marc Petit-Huguenin wrote:

> 2) delay for RELOAD,

forgive my rolling around on the floor laughing... no matter how slow RELOAD is, I'll bet Eric Burger some fist full of untraceable cash it will be done well before VIPR

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 26 Jan 2012 17:16:26 -0800

On 01/26/2012 04:28 PM, Cullen Jennings wrote:
> forgive my rolling around on the floor laughing... no matter how slow
> RELOAD is, I'll bet Eric Burger some fist full of untraceable cash it will
> be done well before VIPR
> 
> 

Well, it's up to the WG to decide what they want to do with this problem. I
really would have liked to have these drafts in good shape before passing the
torch to someone else in two months, but it seems that it will not happen.

- -- 
Marc Petit-Huguenin

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 26 Jan 2012 18:37:58 -0700

On Jan 26, 2012, at 6:16 PM, Marc Petit-Huguenin wrote:

> Well, it's up to the WG to decide what they want to do with this problem.

agree

> I

I'd love to see VIPR all in good shape by Paris. If I had to guess, I would give RELOAD a 35% chance of being IESG approved by Paris.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 27 Jan 2012 10:08:37 -0500

<hat type="geopriv"/>

Could we please distinguish between "location privacy" and "IP address privacy"?  They are related, but distinct concepts.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 27 Jan 2012 07:19:25 -0800

On 01/27/2012 07:08 AM, Richard L. Barnes wrote:
> <hat type="geopriv"/>
> 
> Could we please distinguish between "location privacy" and "IP address 
> privacy"?  They are related, but distinct concepts.

Yeah, my mistake.  I thought that Cullen was responding to my concern about IP
address privacy in his email to p2psip.

This said, I think that adding one hop to hide the IP address is not enough,
and I believe that onion routing is the way to go to solve the IP address
privacy - which may or may not also solve the location privacy problem.

The interesting part is that business goals are, in this particular case,
aligned with privacy advocates.

In any case, even if Cullen was talking about something different, I do not
think that the dates he provided are wrong.

>>> Cullen's email in P2PSIP was unambiguous in saying that doing this
>>> will push VIPR to 2015/2020.
>> 
>> That is not at all what I said. The 2020 was a date where I think we
>> might be possible to have a location privacy solution. As folks may
>> recall from the BOFs when P2PSIP was formed, Cisco had expressed that one
>> of these cases it was interested in was when the communications were not
>> at all anonymous but the location needed to be. The example used as Vice
>> President of the US during an emergency may be moved to a location that
>> is kept very secret but they need to communicate security and with
>> authentication to a large number of people. Todays internet protocols
>> don't offer much in the form of location privacy - with the possible
>> exception of TOR. Some person with General in their title even showed up
>> at Vancouver and Prague IETFs. When P2PSIP got chartered, location
>> privacy got drooped out because it was viewed as it would just be too
>> much to solve. I think I argued for doing location privacy at the time
>> but I was wrong - it clearly would have been too much to do in the first
>> version.
>> 
>> However, I still hope that we might have a standards based location
>> privacy system by 2020 but others think it is better to do this type of
>> thing just a a proprietary system so who knows.

- -- 
Marc Petit-Huguenin

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Fri, 27 Jan 2012 09:39:20 -0600

> For some of the attacks on ViPR, the best defense is to make sure your PSTN numbers are registered. I view this as  feature of the design. I'm sure opinions vary on this.

Wearing a 'businessperson' hat, I just don't see how this is an 
acceptable situation. This would be similar to saying that if you don't 
choose to advertise in the Yellow Pages, other companies can do it in a 
way that lets them know who your customers are. Granted, there might not 
be much of a direct cost to participate in a public ViPR cloud, but 
there are certainly significant potential indirect costs for companies 
who don't have the equipment/software in place to participate from day one.

In addition, wearing my 'paranoia' hat, who is to say that there won't 
be multiple (possibly many) ViPR clouds being used to route E.164 
numbers? For each one that exists, anyone who wishes to best defend 
their numbers must participate.

I suppose one way to look at this is that it will potentially spawn a 
whole new industry of 'ViPR protection service' companies :-)