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

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

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

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

o Attendees:
  Mary Barnes
  Kurt Bergsbaken
  Daryl Malas
  Hakim Mehmood
  Jon Peterson
  Marc Petit-Huguenin
  Michael Procter
  John Ward
  Dean Willis

o Regrets
  Muthu Arul Mozhi Perumal

o Agenda

- - Privacy issue

o Action items

- - We continue working on VIPR.
- - Michael to update his document, please send text.

o Minutes

Marc: I propose to talk about the privacy problem is 3 steps.  First we need to
agree that this is really a problem.  Option 4, proposed by Richard Barnes, was
to not do anything about this.  If we agree that this is problem, then the
second question is do we agree that this requires modification in RELOAD.
Then the 3rd step would be to decide what to do, knowing that doing anything
in RELOAD will take a long time.

Daryl: If this problem has not shown itself in p2psip, I am curious to know if
this problem is unique to VIPR, and then to decide if we want to do any
modification to RELOAD.

Marc: My original plan was to work on VIPR until December, I extended for 3
months, but after the meeting in Paris I will no longer be able to put as much
work on VIPR.  So let's be sure that we have some kind of decision at the end of
this meeting, so I know if I am going to Paris or not.

Marc: So is this privacy issue really a problem?

Dean:  This is a real problem.  You have a 50% chance of being in the first
attempt of verifying the connection, and for every registration you increase
your odds.

Michael: It's right if you stop after the first success.

Jon: The reason for doing that relates to things that are still controversial,
like SIP intermediaries.  From my perspective, it's an interesting problem, but
I do not think that it is a showstopper in the sense that I do not think that
VIPR is worthless if it has this liability.  I would be comfortable with
documenting the problem, and measures that mitigates it. And I would also be
comfortable with saying is there a way to really do an anonymous DHT, but it's
almost a research project.  But I certainly do not think that it render useless
and that we should go home.

Hakim: I agree with everything you said.

Marc: Should we put a requirement in the -overview document saying that we must
fix this privacy problem, and is it just something that we should work on in the
future?

Jon: There is specific threat models that we can discuss.  There is a difference
between someone who register for one number and someone who register for all
numbers.  For example this is an argument to not go through all registrations.
But there is no fix for this, as there is no fix for SIP security issues.

Daryl: I agree with that. There is a lot of architectures that VIPR works very
well within.

Dean: There is potential mitigation that we can build going forward.  For
example adding a web of trust.  Alice calls Bob and successfully validates, then
Alice put something in the overlay saying this, then Charlie, who has an
existing relationship with Alice might then be more inclined to trust the
validation of Bob.  This is things that we can address going forward.  We can
also came with suggestions for RELOAD, and have the RELOAD design change over
time, but they will not change RELOAD in this round.  But that does not prevent
a first version of the protocol to be released.

Daryl: I like that approach. To go back to what Jon said, in the early days of
SIP, there was concerns around security issues, workarounds were documented, but
still people do not implement them - people still are not doing SIP over TLS.

Michael: There is plenty of things we can do to attack the problem, but if we
continue with the idea that there will be only one VIPR network, globally, that
make it a lot harder for us to solve these problems.  If we define things that
should work with a group of participants, then I think that we can make
something that has all the properties for that group of users.  But if we focus
on one overlay for the whole planet, then these problems will really bite.

Jon: I am sure that the designers of VIPR would be reluctant to give up the
property that there something that everyone can join and that it is public.  I
would prefer that we keep that property.

Daryl: Are you suggesting to have multiple VIPR networks, and have some sort of
inter-domain communication?

Jon: Michael is suggesting that it is the public nature of VIPR that is creating
all these problems.  If you imagine a closed trusted community of enterprises,
that would be one way to prevent rogue party to entering and putting bogus
registrations. Cullen alluded to a common CA, so if everybody follow a trust
anchor, we can trace who everybody who is participating is.

Daryl: So it's a federation that's being established.

Jon: That does not change RELOAD.  Changing RELOAD will not happen in any
reasonable time.

Daryl:  I totally agree.  And I agree with the federation that you described.

Jon: Michael, do you think that the only way to combating this is to split the
overlay, or do you think there is alternatives?

Michael:  For some of the attacks we can probably work out mitigation while
maintaining a single DHT.  But I do not think that we can capture all the
problems, and I fear that we will end up with one DHT that cause this huge
problem.  A lot of these problems seems to go away if you deploy in small
groups, so maybe one approach is to finish off a version of VIPR that is
suitable for groups that prominently trust each other.

Jon: Does the current specification mandates a single overlay?

Marc: The specification assumes only one DHT.

Dean: Even with one VIPR cloud, one could imagine adding information in the
overlay to track the relationship between CAs.

Marc: This is not a small modification of VIPR.

Jon: A lot of the mitigation solutions would be looking at the registrations
deciding why one is preferred over the others.

Hakim: You could have one more step where the Fetch comes from your trusted
domain, so you do not start PVP.

Jon: It's like a whitelist, The original design was really to have an
introductory system, to be a way to use the PSTN as a bootstrap.  We can argue
to a point where it's no longer doing what it's supposed to do.

Hakim: It's part of the mitigation.  At the end the goal is for everybody to
use VIPR with confidence, and not undermine privacy and security, but those
measures should be recommended, not mandated.

Marc: If we can anonymize the PVP connection and the RELOAD transactions, then
we can solve this problem without adding more verifications.

Hakim: Agreed.

Jon: I am not even sure where to start with that.  That's almost a research
problem.

Marc: Yes and the problem is that RELOAD is not the best place to do that
currently.

Jon: I agree that anonymyzing RELOAD would be great, but that would require a
new working group, a different charter, and would complete in 5/7 years.  If
we want to continue, our job is to figure how to mitigate with the current system.

Hakim: Was your comment about anonymizing the IP address?

Jon: Yes, because from the source IP address you can find the enterprise.

Hakim: If we use TURN and method B, it would hide the source IP address and
the Caller-ID.

Jon: The problem with TURN is that you do not necessarily trust the people you
are asking.  You need several hops, to have a reasonable assurance that the
nodes you are using are not bad actors.  And I suspect that would be a very
different model for RELOAD.

Michael: You still leak the fact that someone has requested the record for
that phone number.

Jon: That's why it's important to articulate the whole set of threats.  But if
your could solve the problem of hiding analytics, the bittorrent community
would be so thrilled.

Michael:  But the point is that with bittorrent, who have the choice to not
participate, but with VIPR, you do not.

Jon: When I was first reading about this problem, I though about fixing it the
other way: is there anyway we can get as many registrations done as possible.
 There is the interesting property that says that as soon the validation is
done, you are no longer vulnerable, until you need a revalidation.  But the
result for an attacker will be very unpredictable.

Michael:  I agree.

John: We are talking for the point of view of an attacker, but there is all
kind of usages for intermediaries.  For example I can query the DHT and
determine the network topology of my competitors.

Jon: The network topology under VIPR is pretty flat.

John: We will not get away from the point where there will not be intermediaries.

Jon:  It's another approach to privacy.

Dean : Yes, if there is 3 aggregators in the world, there is not much
information leak.

Jon: We need to document thoroughly that the threat is first.  One is where
someone is curious about a particular phone number.  Another is to collect
information on any number.  For each of these threats we need to understand
what they can accomplish, do we have any way to detecting it, and finally what
change to the design we can make to mitigate that.

Daryl: Would this potentially cause a situation where these become just
proprietary VIPR.  I do not want to say at the end to go to one vendor.

Dean:  How would we block aggregator choice of delivery?

Daryl:  The goal is to encourage various vendors to participate, not to create
these proprietary aggregations that never talk to each other.

Jon:  We can add compromising RELOAD to the list of threats.

Dean: Do we have something like the voice hammer attack?

Marc: There is a quota mechanism in RELOAD, so the more registrations you put
on the network, the more hardware you need to contribute.

Jon: Yes, these are active attacks. But we should separate the from the
passive attacks.  The privacy attacks are discoverable, because you can look
after the fact.

Dean: You can also do self verification of validation, i.e. audit your phone
number and if there is strange registrations, make inquiries.

Jon:  Yes, each time there is a failed validation you can record it, and we
can flag the source.

Marc: Yes and remember that in RELOAD there is a blacklist mechanism, so the
people responsible for the overlay configuration document can prevent specific
nodes to join.  But note that it is not because a registration fails that the
guy at the other side is a bad guy. There is a lot of reasons why a
registration can fail and still be a legitimate node.  We do not want to go
overboard, and create a new attack that prevent the right owner to participate.

Jon:  Yes, but if every node reports that there is a problem with a particular
entity, then there is a consensus that there is a problem.

Marc: OK, we have a consensus that we should continue to work on this, and we
agree to document the use cases.

Michael:  Please send text.

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

iQIcBAEBCAAGBQJPJyymAAoJECnERZXWan7EbaEQAIa+zCMXY3LW+t2SyX5iwXqG
DVSIbYWpVFM06Z+yWj+Z7pOaWal2GrfIsqHyhHTj2r2HCakW7Q/fA5LRqg+58K/c
nJwJEuioyLyh25OWbQ1xd0bdcxySIKyXD4EXYLHbOAxwEG3OfT1kieva9+ja0RNt
qMQZnNOjRr70gomhDPjLUejTiVc1zeUSNyDLNG3WbhfYjAvoM2/YEVfyej5f93/N
lzfncI0u+mQ3QrqEFWysUumUe5DPR0OoJoMHFEPWJzXfWpWl3INmAxAq+p96FlvX
MBpPqqF6XbHni3q3tY0s/0rwEI/ouY9jSUJ0rJ+1limJI3eUNzjl8uKDF4qrHYaH
yiu7VVTPhJ7faeeJ1JRcnS9tp4mvwI3+lPWWglFkdXgAmMSbGvQTaPkq5Pdyo7Rr
sE17t5ZDuXFj8bgA4AQbgthTy5EugBMAYMJ4YfYoUcRoeLl6Q3RXeSR+9QnYBEsg
XVH5o5OP92zR+vP0C+xqmCnLDfEnj2eB7fIlsWIE0QbIPX11LMltsV/1wkCwfIY9
4oYVSvbSswbMlhPNRDKmCnzouwDVeV+NfdVn84ybBEQz1Sg/0KgPF1WnWEV1TA/n
3hUmJZCigM23QedwhuX+ooNy5Le5UNX8d09WcMV92xBlIx6kBG0jhlJdoYAcqB9y
4xM8EEX903UWEexiCNia
=/1U3
-----END PGP SIGNATURE-----