Subject: [VIPR] Agenda & Handout for 2012/01/27

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 26 Jan 2012 07:15:04 -0800

A. Agenda

- - Privacy issue

Note that the sum of the time allocated to each topic may exceeds the time
allocated to the whole call.  The topics that cannot make it to the discussion
will be postponed to the next conference call if they are not subsequently
decided in the mailing-list.

Because the conference bridge as a limited capacity, an individual invitation to
the conference will be sent shortly after this email to each member of the
design team.  Please send me an email if you are not on this list and want to
receive an invitation.

Note that the design team conference call is not a way to short-circuit the
normal process, but a way to accelerate it by increasing face to face time.  All
decisions made must be confirmed on the mailing-list.

This conference call is subject to the rules of RFC 5378 and RFC 3979 (updated
by RFC 4879).

B. Handout (reading time: 5 min)

Michael Procter explained on the last VIPR design team weekly conference call
a privacy attack that is a great source of concern.  The end result is simple
to explain:  VIPR turns the Internet into a "trap and trace device", 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 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 an opaque ID.

There is ways to fix all of these leakages, but they make RELOAD and VIPR
much, much more complex.  Using TURN to anonymize, as I proposed, does not
work because of the multiple places where data is leaked and fixing RELOAD
itself will require among other things adding something like onion routing and
a way to use anonymous end to end authentication.  The added complexity of
having to anonymize the PVP connection can be reduced by running PVP directly
on top of the anonymized RELOAD messages, but that require to define SRP-DTLS
and then the various RELOAD messages to do this, and so on.

But complexity is not the only concern. We made slow and steady progress in
finding consensus on issues that are pure VIPR, but on the RELOAD side no
amount of energy spent seems to help accelerate things.  Forking the RELOAD
spec to have at least a decent subset that VIPR can use and adapt to its needs
is probably not legal, and anyway would prevent reusing standard
implementations of RELOAD for the purpose of running VIPR.

So our options as I see them are:

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

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.