Subject: [perpass] Securing VoIP in the Presence of Pervasive Monitoring

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 09 Sep 2013 11:26:39 +0300

Hi all,

I gave a presentation last week to a group of international data 
protection authorities about VoIP security & privacy. I produced a blog 
post about the presentation and put it here:
http://www.tschofenig.priv.at/wp/?p=997

It contains a number of recommendations, which are addressed to VoIP 
providers and vendors but have to be enforced by data protection 
authorities.

The recommendations unfortunately highlight some challenges...

Would be interesting to hear your thoughts.

Ciao
Hannes

---

From: Linus Nordberg <[email-masked]>
Date: Mon, 09 Sep 2013 13:31:23 +0200

Hannes Tschofenig <[email-masked]> wrote
Mon, 09 Sep 2013 11:26:39 +0300:

| http://www.tschofenig.priv.at/wp/?p=997
| 
| It contains a number of recommendations, which are addressed to VoIP
| providers and vendors but have to be enforced by data protection
| authorities.
| 
| The recommendations unfortunately highlight some challenges...

Indeed. And still, I miss any mention on protection against collecting
data about who's talking to who.

Without claiming any expertise at all in this area, the closest thing to
something implementing this that I've heard of is Mumble over
Tor. Mumble [0] is not standardised AFAICT. The Guardian Project wrote
[1] about this earlier this year. Some people seem to use it [2].

[0] https://en.wikipedia.org/wiki/Mumble_%28software%29
[1] https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/Mumble
[2] https://guardianproject.info/2013/01/31/anonymous-cb-radio-with-mumble-and-tor/

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 09 Sep 2013 14:43:57 +0300

Hi Linus,

thanks for the comments.

I have indeed skipped that topic. I will have to read into the Mumble 
project to see what security and privacy guarantees it provides.

My current conclusion from using VoIP/IM systems without using Tor is 
that you cannot really protect against collecting this transaction data 
(i.e., you have to at least trust the two VSPs, our own and then the VSP 
of your communication partner). While you can influence routing of the 
data traffic to a certain extend it does not work too well when your VSP 
is working against you.

With IM you could at least set up your own server (e.g., by using an 
XMPP server) but with VoIP that's more complicated because nobody else 
will accepted your connection attempts (as explained in the 
interconnection part of my write-up).

I will come back to you on that issue.

Ciao
Hannes

On 09.09.2013 14:31, Linus Nordberg wrote:
> Hannes Tschofenig<[email-masked]>  wrote
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass

---

From: Dean Willis <[email-masked]>
Date: Mon, 9 Sep 2013 09:46:45 -0500

I think we can mostly get there with RELOAD, but the implementations are
still pretty early.
On Sep 9, 2013 6:53 AM, "Hannes Tschofenig" <[email-masked]>
wrote:

> My current conclusion from using VoIP/IM systems without using Tor is that
> you cannot really protect against collecting this transaction data (i.e.,
> you have to at least trust the two VSPs, our own and then the VSP of your
> communication partner). While you can influence routing of the data traffic
> to a certain extend it does not work too well when your VSP is working
> against you.
>
> With IM you could at least set up your own server (e.g., by using an XMPP
> server) but with VoIP that's more complicated because nobody else will
> accepted your connection attempts (as explained in the interconnection part
> of my write-up).
>
>> Hannes Tschofenig<hannes.tschofenig@**gmx.net <[email-masked]>>
>>  wrote
>> | http://www.tschofenig.priv.at/**wp/?p=997<http://www.tschofenig.priv.at/wp/?p=997>
>> |
>> [0] https://en.wikipedia.org/wiki/**Mumble_%28software%29<https://en.wikipedia.org/wiki/Mumble_%28software%29>
>> [1] https://trac.torproject.org/**projects/tor/wiki/doc/**
>> TorifyHOWTO/Mumble<https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/Mumble>
>> [2] https://guardianproject.info/**2013/01/31/anonymous-cb-radio-**
>> with-mumble-and-tor/<https://guardianproject.info/2013/01/31/anonymous-cb-radio-with-mumble-and-tor/>
>> ______________________________**_________________
>> perpass mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/perpass<https://www.ietf.org/mailman/listinfo/perpass>
>>
>
> ______________________________**_________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/perpass<https://www.ietf.org/mailman/listinfo/perpass>
>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 9 Sep 2013 11:09:45 -0400

I'm still worried about the role of the enrollment server.  If it got compromised, then mischief would be possible (you may not know who you are talking to).  I think MITM would be hard.

I think we need to come up with a new way to come up with credentials that is less dependent on servers that are subject to co-opting by the authorities.

It's a HECK of a lot better than conventional VoIP though.

Brian

On Sep 9, 2013, at 10:46 AM, Dean Willis <[email-masked]> wrote:

> I think we can mostly get there with RELOAD, but the implementations are still pretty early.
> 
> On Sep 9, 2013 6:53 AM, "Hannes Tschofenig" <[email-masked]> wrote:
> Hi Linus,
> 
> thanks for the comments.
> 
> I have indeed skipped that topic. I will have to read into the Mumble project to see what security and privacy guarantees it provides.
> 
> My current conclusion from using VoIP/IM systems without using Tor is that you cannot really protect against collecting this transaction data (i.e., you have to at least trust the two VSPs, our own and then the VSP of your communication partner). While you can influence routing of the data traffic to a certain extend it does not work too well when your VSP is working against you.
> 
> With IM you could at least set up your own server (e.g., by using an XMPP server) but with VoIP that's more complicated because nobody else will accepted your connection attempts (as explained in the interconnection part of my write-up).
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Sep 2013 16:30:33 +0100

Hi Brian, Dean,

RELOAD [1] is a bit of a gigantic spec though but I agree could
be promising in this space. I wonder if anyone might be interested
enough to write a draft saying how to use RELOAD to be more
privacy friendly?

I've no idea if that'd be easy or a huge amount of effort for
someone who already knows the protocol, but I'm pretty sure it'd
be a major task for someone starting from scratch.

S.

[1] http://tools.ietf.org/wg/p2psip/draft-ietf-p2psip-base/

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 09 Sep 2013 08:32:32 -0700

On 09/09/2013 08:09 AM, Brian Rosen wrote:
> I'm still worried about the role of the enrollment server.  If it got 
> compromised, then mischief would be possible (you may not know who you are 
> talking to).  I think MITM would be hard.
> 
> I think we need to come up with a new way to come up with credentials that
> is less dependent on servers that are subject to co-opting by the
> authorities.

Yes.  If anyone has a knowledge of some method (even theoretical research)
that could be used for that, I would be more than happy to help adapt it to
RELOAD.

> On Sep 9, 2013, at 10:46 AM, Dean Willis <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>> On Sep 9, 2013 6:53 AM, "Hannes Tschofenig" <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>> 
>> Hi Linus,
>> 
>> thanks for the comments.
>> 
>> Ciao Hannes
>> Hannes Tschofenig<[email-masked] 
>> <mailto:[email-masked]>>  wrote Mon, 09 Sep 2013 11:26:39
>> +0300:
>> 
>> | http://www.tschofenig.priv.at/__wp/?p=997 
>> <http://www.tschofenig.priv.at/wp/?p=997> | | It contains a number of
>> recommendations, which are addressed to VoIP | providers and vendors but
>> have to be enforced by data protection | authorities. | | The
>> recommendations unfortunately highlight some challenges...
>> 
>> something implementing this that I've heard of is Mumble over Tor. Mumble
>> [0] is not standardised AFAICT. The Guardian Project wrote [1] about this
>> earlier this year. Some people seem to use it [2].
>> 
>> [0] https://en.wikipedia.org/wiki/__Mumble_%28software%29 
>> <https://en.wikipedia.org/wiki/Mumble_%28software%29> [1] 
>> https://trac.torproject.org/__projects/tor/wiki/doc/__TorifyHOWTO/Mumble 
>> <https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/Mumble> 
>> [2] 
>> https://guardianproject.info/__2013/01/31/anonymous-cb-radio-__with-mumble-and-tor/
>>
>> 
<https://guardianproject.info/2013/01/31/anonymous-cb-radio-with-mumble-and-tor/>

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 09 Sep 2013 08:55:50 -0700

On 09/09/2013 08:30 AM, Stephen Farrell wrote:
> 
> Hi Brian, Dean,
> 
> RELOAD [1] is a bit of a gigantic spec though but I agree could be
> promising in this space. I wonder if anyone might be interested enough to
> write a draft saying how to use RELOAD to be more privacy friendly?

I wrote a draft adapting some of the ideas of TOR to RELOAD:

http://tools.ietf.org/html/draft-petithuguenin-p2psip-reload-anonymous-02

That was presented in Atlanta:

http://www.ietf.org/proceedings/85/slides/slides-85-p2psip-1.pdf

Interestingly the reason for this draft was not end-user privacy, but to
prevent commercial entities to discovers competitors' customers in the context
of VIPR.

> 
> I've no idea if that'd be easy or a huge amount of effort for someone who
> already knows the protocol, but I'm pretty sure it'd be a major task for
> someone starting from scratch.
> 
> S.
> 
>> compromised, then mischief would be possible (you may not know who you
>> are talking to).  I think MITM would be hard.
>> 
>> I think we need to come up with a new way to come up with credentials
>> that is less dependent on servers that are subject to co-opting by the
>> authorities.
>> 
>>> wrote: Hi Linus,
>>> (i.e., you have to at least trust the two VSPs, our own and then the
>>> VSP of your communication partner). While you can influence routing of
>>> the data traffic to a certain extend it does not work too well when
>>> your VSP is working against you.
>>> 
>>> On 09.09.2013 14:31, Linus Nordberg wrote: Hannes
>>> Tschofenig<[email-masked]>  wrote Mon, 09 Sep 2013 11:26:39
>>> +0300:
>>> 
>>> | http://www.tschofenig.priv.at/wp/?p=997 | | It contains a number of
>>> recommendations, which are addressed to VoIP | providers and vendors
>>> but have to be enforced by data protection | authorities. | | The
>>> Without claiming any expertise at all in this area, the closest thing
>>> to something implementing this that I've heard of is Mumble over Tor.
>>> Mumble [0] is not standardised AFAICT. The Guardian Project wrote [1]
>>> about this earlier this year. Some people seem to use it [2].
>>> 
>>> [0] https://en.wikipedia.org/wiki/Mumble_%28software%29 [1]
>>> https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/Mumble 
>>> [2]
>>> https://guardianproject.info/2013/01/31/anonymous-cb-radio-with-mumble-and-tor/

- --
Marc Petit-Huguenin

---

From: Brian Rosen <[email-masked]>
Date: Mon, 9 Sep 2013 11:48:19 -0400

RELOAD is a rendezvous protocol - it yields a URI to send SIP messages to in order to establish a p2p connection.  

It uses an algorithm (the RELOAD spec is designed around a pluggable algorithm) of which Distributed Hash Table examples like Chord are good candidates.  The algorithm defines how a p2p distributed databases of these URIs is created, and how you query the DHT to find the URI of the party you want to talk to.  You start with an identifier, query the DHT and get the URI.  

Then you send a normal SIP INVITE to that URI.  This means the SIP signaling itself does not go through any intermediaries, nor does the media (assuming a TURN relay is not needed).

Contrast this with how normal SIP calling works, where you send the INVITE to a proxy server in your local domain (carrier) who routes it through some set of proxy servers to the destination domain (possibly including a transit domain) who routes it to the destination.  Along the way, as implemented, any number of changes to the SIP INVITE are made, including changing the media end point IP addresses, so the media is forced through middle boxes in the carrier network.

So RELOAD is privacy friendly by turning calling into true p2p with signaling and media not transiting any third party.

The concern I have is that to get credentials enabling you to store your URI in the DHT, you interact with an enrollment server.  That server only issues credentials, it's not in the path of the call,  but if it was co-opted, it could create mischief with those credentials.

Brian

---

From: Scott Brim <[email-masked]>
Date: Tue, 10 Sep 2013 08:18:38 -0400

> The concern I have is that to get credentials enabling you to store your URI in the DHT, you interact with an enrollment server.  That server only issues credentials, it's not in the path of the ca…

There could be multiple enrollment servers, so all you need is an
enrollment server that you both trust (but then we go around that loop
again).  Also, a grassroots system doesn't have to be under legal
obligation to reveal information.

---

From: SM <[email-masked]>
Date: Tue, 10 Sep 2013 16:59:30 -0700

Hi Hannes,
At 01:26 09-09-2013, Hannes Tschofenig wrote:
>protection authorities about VoIP security & privacy. I produced a 
>blog post about the presentation and put it here:
>providers and vendors but have to be enforced by data protection authorities.

There seems to be an agreement between a country which you can guess 
and a country in Europe which bypasses data protection 
requirements.  I did not verify the information.

I suggest looking at the 3GPP use-case in respect to SIP identity.

One of the issues with transparency is that it is overruled by "in 
accordance with the law".

Lawful intercept seems to be quite broad in a country even though the 
legislation says otherwise.

The list of recommendations is a good start.

Regards,
-sm

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 12 Sep 2013 14:27:17 +0300

Hi Dean,

I may not be up to speed with RELOAD but I understood that all the 
energy has vanished from that work. There were also a number of 
technical problems.

Maybe someone can give us a brief update on the status.

Ciao
Hannes

On 09.09.2013 17:46, Dean Willis wrote:
>     I have indeed skipped that topic. I will have to read into the
>     Mumble project to see what security and privacy guarantees it provides.
>
>     My current conclusion from using VoIP/IM systems without using Tor
>     is that you cannot really protect against collecting this
>     transaction data (i.e., you have to at least trust the two VSPs, our
>     own and then the VSP of your communication partner). While you can
>     influence routing of the data traffic to a certain extend it does
>     not work too well when your VSP is working against you.
>
>     XMPP server) but with VoIP that's more complicated because nobody
>     else will accepted your connection attempts (as explained in the
>         <mailto:[email-masked]>>  wrote
>         <http://www.tschofenig.priv.at/wp/?p=997>
>         |
>         _________________________________________________
>         perpass mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/perpass
>         <https://www.ietf.org/mailman/listinfo/perpass>
>
>
>     _________________________________________________
>     perpass mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/perpass
>     <https://www.ietf.org/mailman/listinfo/perpass>
>

---

From: Brian Rosen <[email-masked]>
Date: Thu, 12 Sep 2013 08:20:45 -0400

There is low energy in the work group at the moment, but the technical problems have been addressed and there are a few implementations.

The base spec should be published soon (it's in AUTH48).  We need the SIP spec to be finished.  There are some subsidiary specs that are in process which improve operation in certain circumstances, but base RELOAD and the SIP application of RELOAD would provide a good basis for VoIP which is substantially less susceptible to interception.

As it is a true peer to peer solution, the opportunity to charge customers lots of money to place calls is somewhat limited.  There are some opportunities in the enrollment server, but they are limited, and as I had mentioned previously, if the enrollment server was compromised, mischief could be inserted into the credentialing.

I think if this seemed to be one of our responses to recent revelations, work could be completed rather quickly.

Brian
On Sep 12, 2013, at 7:27 AM, Hannes Tschofenig <[email-masked]> wrote:

> Hi Dean,
> 
> I may not be up to speed with RELOAD but I understood that all the energy has vanished from that work. There were also a number of technical problems.
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Sep 2013 10:12:36 +0300

Hi Linus,

now I had the time to look at the Mumble project.

I might be incorrect in my assessment. I found some information but it 
was mostly irrelevant to make a good assessment about the security and 
privacy properties about it.

There seems to be the (wrong) believe that if you publish software as 
open source then everyone can look at the code and the quality will be 
good.

That's of course not the case. There are a few words here and there 
about security but I failed to see enough to even give me enough to say 
something meaningful about it.

 From what I can tell the software does not interoperate with anything 
else other than their own silo, which is bad.

If you use a provider that runs that VoIP service then you have to trust 
him like with any other VoIP providers. Of course you can run your own 
server but then your friends have to be on your own server as well, if I 
understood it correctly. Maybe that's a great idea that everyone should 
have their own server and if you want to talk to someone then they 
create an account at your server and start communicating with you. (You 
could simplify the account creating by using identity federations, even 
if they don't have anything to do with VoIP.) Of course, this would be 
OK with gaming (which seems to be the main target audience of that VoIP 
platform) but not for normal communication use because it would not be 
obviously for anyone trying to contact you how to reach you unless you 
have a permanent VoIP provider.

 From the point of view what we are trying, namely to develop globally 
interoperable VoIP solutions, this is obviously a step backwards (maybe 
20 years).

What is worse, in my point of view, is that adding Tor to Mumble may not 
actually provide you any additional privacy/security benefits.
If you trust the VoIP provider than you could very easily create an 
end-to-end security solution. Without Tor the other party would most 
likely still see the IP address of your device (or the IP address of 
some NAT). That's what Tor (or other tunneling technologies) could hide. 
The VoIP provider still knows who you are talking with and, depending on 
how the details look like, he may still be able to decrypt the VoIP 
communication.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Sep 2013 10:20:40 +0300

There may well be a mismatch between data protection laws and lawful 
intercept but I think it is outside my realm to solve that problem.

On the SIP Identity and 3GPP: To my knowledge the 3GPP IMS does not make 
use of SIP Identity; it only relies on PAI.

On 11.09.2013 02:59, SM wrote:
> There seems to be an agreement between a country which you can guess and
> a country in Europe which bypasses data protection requirements. I did
> not verify the information.
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 13 Sep 2013 09:36:46 +0200

Changing subject a little.

I've looked at the Tor project and thought about how it would adopt to a SIP solution. The current network has way too much latency to be useful for anything else than push-to-talk messages.

What is done in Tor (if I understand correctly) is that they adopt three layers of TLS encryption from the user agent to the exit server - maybe a fourth to the final service. 

There's an old draft defining a new method that opens a clear connection through a proxy, much like websockets, in order to be able to do TLS peer to peer. This could come in handy. Maybe we could just use the Tor network Socks interface.

So signalling may not be a big problem, but the question is if that could be done with something like SRTP+DTLS?

Would the three layer encryption simply add too much latency to be useful?

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 13 Sep 2013 09:38:19 +0200

13 sep 2013 kl. 09:20 skrev Hannes Tschofenig <[email-masked]>:

> On the SIP Identity and 3GPP: To my knowledge the 3GPP IMS does not make use of SIP Identity; it only relies on PAI.

And the number of implementations are depressingly low.

I've run a half test of SIP Identity at SIPit. The other half failed...

/O

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 13 Sep 2013 08:52:37 -0400

If by "SIP Identity" you mean RFC 4474, it's not deployable as I think you know; and even were it deployed it wouldn't actually provide identity for E.164's which are the most common form of identifier for SIP deployments (including 3gpp ones); nor does it provide any new/additional privacy benefits afaik.  Essentially the RFC was dead on arrival, and we all knew it.

-hadriel

On Sep 13, 2013, at 3:20 AM, Hannes Tschofenig <[email-masked]> wrote:

> There may well be a mismatch between data protection laws and lawful intercept but I think it is outside my realm to solve that problem.
>

---

From: Dean Willis <[email-masked]>
Date: Fri, 13 Sep 2013 08:58:58 -0500

I and several others are still working at it and making good progress. I'm
currently researching storage over RELOAD.

There are some ways around the credentialing issues for pseudonymous modes
that preserve the useful property of "this identity owns that data" without
making strong assertions about the identity. It's also workable with
client-generated certs or even pgp keys. Any extension of trust between
identities can be handled by out-of-band fingerprint verification, as in
PGP and zRTP.

One could certainly use RELOAD as a messaging substrate without much work.
 On Sep 12, 2013 6:27 AM, "Hannes Tschofenig" <[email-masked]>
wrote:

> Hi Dean,
>
> I may not be up to speed with RELOAD but I understood that all the energy
> has vanished from that work. There were also a number of technical problems.
>
>> <mailto:hannes.tschofenig@gmx.**net <[email-masked]>>> wrote:
>>
>>     Hi Linus,
>>
>>     thanks for the comments.
>>
>>         Hannes Tschofenig<hannes.tschofenig@_**_gmx.net
>>         <mailto:hannes.tschofenig@gmx.**net <[email-masked]>>>
>>  wrote
>>         | http://www.tschofenig.priv.at/**__wp/?p=997<http://www.tschofenig.priv.at/__wp/?p=997>
>>         <http://www.tschofenig.priv.**at/wp/?p=997<http://www.tschofenig.priv.at/wp/?p=997>
>> >
>>         |
>>         [0] https://en.wikipedia.org/wiki/**__Mumble_%28software%29<https://en.wikipedia.org/wiki/__Mumble_%28software%29>
>>         <https://en.wikipedia.org/**wiki/Mumble_%28software%29<https://en.wikipedia.org/wiki/Mumble_%28software%29>
>> >
>>         [1]
>>         https://trac.torproject.org/__**projects/tor/wiki/doc/__**
>> TorifyHOWTO/Mumble<https://trac.torproject.org/__projects/tor/wiki/doc/__TorifyHOWTO/Mumble>
>>         <https://trac.torproject.org/**projects/tor/wiki/doc/**
>>         https://guardianproject.info/_**_2013/01/31/anonymous-cb-**
>> radio-__with-mumble-and-tor/<https://guardianproject.info/__2013/01/31/anonymous-cb-radio-__with-mumble-and-tor/>
>>         <https://guardianproject.info/**2013/01/31/anonymous-cb-radio-**
>>         ______________________________**___________________
>>         perpass mailing list
>>         https://www.ietf.org/mailman/_**_listinfo/perpass<https://www.ietf.org/mailman/__listinfo/perpass>
>>         <https://www.ietf.org/mailman/**listinfo/perpass<https://www.ietf.org/mailman/listinfo/perpass>
>> >
>>
>>
>>     ______________________________**___________________
>>     perpass mailing list
>>     https://www.ietf.org/mailman/_**_listinfo/perpass<https://www.ietf.org/mailman/__listinfo/perpass>
>>     <https://www.ietf.org/mailman/**listinfo/perpass<https://www.ietf.org/mailman/listinfo/perpass>
>> >
>>
>>
>