[VIPR] Minutes for 2012/01/20 conference call

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

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

VIPR Design Team conference call on Friday January 20h, from 9:05am to 9:55am PST.

o Attendees:
  Hakim Mehmood
  Marc Petit-Huguenin
  Michael Procter
  Dean Willis

o Regrets
  Mary Barnes
  Daryl Malas
  Muthu Arul Mozhi Perumal
  Jon Peterson
  John Ward

o Agenda

- - ICE support in VIPR
- - Traffic statistics leakage
- - Obtaining the PVP credentials in an office environment
- - Registering multiple PVP servers to validate based on time tolerance

o Action items

- - Continue discussion on privacy issue.
- - Discuss about anonymizing the Node-ID in the RELOAD record.
- - Add ICE as mandatory for the RELOAD overlay.
- - Document the statistic issue in the specs.

o Minutes

Marc: The discussion in this meeting is about the privacy concerns as listed
in Michael Procter's draft.  The first one was the Caller-ID, and the
agreement was to hash the Caller-ID in method A and publish a new method "C"
that invert the selector and the secret.  The next concern was source IP
identification, and one obvious solution to hide it is to use a relay or a
series of relays.  One of the simplest solution to do this is to use the TURN
servers that should be available in the RELOAD overlay.  But TURN servers are
only mandatory if the RELOAD overlay uses ICE.  So the question shifts to "Do
we want to support ICE or not?".  We can still mandate TURN servers if the
overlay does not require ICE, but there is probably other ways in this case to
hide the source.  There is an assumption in the specs that the VIPR servers
are installed either on the Internet or in the DMZ of a firewall, which
implied a non-ice solution.  But what is the granularity that we want for the
VIPR server?  For example as a proof of concept, I am development a prototype
of what I call a VIPR Fax, where the VIPR server is embedded inside a fax
machine and connect directly on the RELOAD overlay on its own, without
requiring external servers.

Hakim: Why does this problem applies only to source?  Anybody can do a Fetch
and find the destination.  Why is it more important for the caller than for
the callee?

Marc: This is a valid but different attack and we should talk about it.  I
will add this concern to the agenda of the next meeting.

Hakim: In the enterprise space, the feedback is that all the security things
are good to do but should not be mandatory.

Michael: I am not sure how compatible that is with the view that there should
be one VIPR overlay.  I do not know how we can make many things optional and
still have a working overlay.

Hakim:  It's just the feedback I have from my customers.

Marc: My concern is that the lack of security will prevent people to join the
VIPR network.

Hakim: The architecture should be a compromise between security and manageability.

Michael: Going back to something Marc said.  If Alice wants to call Bob, but
Bob thinks that VIPR does not have the proper security and decide to not
participate in VIPR, when Alice call Bob, the fact that she calls still leaks.
Bob cannot stop the privacy leak even by just not participating.  Without even
reducing the security, there is already privacy issues, even if you do not
participate.

Hakim: I was more talking about source IP disclosure.

Michael: What I said applies to that too.

Hakim: But how does that compromise my security in this use case?

Michael: It all goes back to asymmetric expectations.  Alice in this case
could have her fully itemized phone bill posted on the Internet.

Hakim: But I was talking about a particular use case.  Alice probably does not
care, but Bob cares and he can anonymize. So as long Bob has the security he
wants it's fine.

Michael: It is not.

Marc: What about putting a flag inside RELOAD asking for privacy?  This has
the advantage that each registration can choose the level and privacy and will
not put as much pressure on the overlay.

Michael: It is essentially a bid-down attack.  The problem is that you have to
be on VIPR to protect your privacy.  This is a fundamental problem and
expecting everyone to opt-in to protect their privacy is a bit of a challenge.

Marc: Let's put on the agenda for next week. We can still talk about the
requiring ICE in the overlay.

Michael: I like the the VIPR fax use case.  I think that it will keep us
honest in other areas, because it does not mean that we automatically assume
that only companies over 200 employees will be in VIPR.  And because of this
we'll need ICE.

Marc:  The only concern with ICE is the complexity.  But it's not like RELOAD
is simple without ICE.  RELOAD is complex, and is even more complex with ICE.
 Anyway the main case for RELOAD was SIP, and you need ICE for SIP, so any
standard RELOAD server will probably also support ICE.

Marc:  Let's move to statistics leakage.  Even if we manage to fully anonymize
the PVP transactions, the simple fact that PVP transactions are made discloses
information.

Michael: As an example we have a taxi company as customer, and simply by
looking at the Internet traffic pattern, we can predict the weather in the
city in which this company operates. Even adding noise would not help and I
think that this attack is real.

Marc: This is true for a lot of other things in the Internet.  This is
something that we need to document, even if we cannot fix it.

Michael: And here also the problem exists either people participate or not in
the VIPR overlay.

Marc:  Moving to the office pranks attacks.  These attacks exists from the
facts that in some environments, you have access to more information, for
example inside an enterprise.  These attacks can be carried by a virus inside
an enterprise.  First attack was to obtain the PVP validation.  One of the way
to mitigate this is to do validation per user, instead of per enterprise.
Interestingly it parallel the VIPR fax use case, where each device also has
its own VServiceID.

Marc: The last attack is similar but was using the rounding.  Note that this
attack and the previous one come from the low security of methods A and B. If
we mandate a validation based on e.g. fingerprinting, then we no longer have
these issues, but these methods are the minimum common denominator.

Michael: If ICE is not adopted because of its complexity, then we will have a
problem adopting fingerprinting, which is even more complex.

Marc: Yes, and this also creates a problem for SIP intermediaries who do not
have access to the media.

Hakim: Two mains themes with our customers has been:  Why does it take so long
to validate, and what rounding should I use to have my validations succeeding.

Marc: We can solve a lot of problems by simply forgetting about these methods,
but we are restricting the use of this technology, But these methods looks so
bad, between reliability, privacy and time to succeed, that it is perhaps not
worth the effort.

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

iQIcBAEBCAAGBQJPHZJ/AAoJECnERZXWan7EbKsP/RjkAh6cf7AFngJ7a22OfOxK
Q2KilGCjpIcfL8Z6MHf8Qp9JVUg7zTwZXy6UEZabUWWjEs6l3IqPCXL1mF+YFjCX
Wpv0bofkZzW+95x2ZmTVd47W1rVT5H/zcZoU6c8RASd8Xhorout1VXZDDW4NxfEi
vTdSU58DmOBJTCFcrFJYBeGWiK6RHLI9Ufxp7QMZu/oWfIDepN2FPBfQNKgbEiWR
XTamwFuXt1m9gzW0ACePVElA29/fSeoL6WjjLZ4A5f1ahfVPbCuMdso5bxQ8RW6y
cYIWFacLNAMvr1+vaOKp03cPF2EBkc8ZZvljB1kF5DrTIedaNxaIx8uRVv3qb7vy
3bAfy95o7H80HmRn0YWCIDxn2YgFTm3fJgRMk7EKP+qIP5BDpXT2XQ26i+/UxVY2
xW9dIYXgJQ1OyjaxM/y6QVLboBjNNYvGtm1w+BhCEHsSs0oEzpjkQeQjF6Zxb1fe
26m8eBLYn82VHkxQwJK5rVl+rLOqNSwZikLCng6TleohnGKEzEuL7lIv0/CQKB+g
pZZxzrjEmAwwxu3qR5p3ZScOoS+qbA4e6mJ1QqLZ1Os4U2n2hqVDmxnUfs+HfoN3
iBT34BDkL99qwKXAptwXMOuwGKSuMrWk6uafYQANfjqr6TDTnF5GifNaipbB+wtx
Y47/BGUEO1YYPYUZoxPk
=13ni
-----END PGP SIGNATURE-----