Re: [VIPR] VIPR privacy issue

[Cullen Jennings <[e-mail]>]

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. 



On Jan 24, 2012, at 1:53 PM, Marc Petit-Huguenin 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.
> 
> 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)
> 
> 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-----
> _______________________________________________
> VIPR mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vipr