1. Voice over Internet Services and Privacy

2. Agenda Problem Description Scope Recommendations

3. Problem Description Skype spying on users – Academic paper. Academic paper – Press article in English Press article – Press article in German Press article Weak/broken security – Blog post about WhatsApp Blog post – Cryptocat: German article / English articleGerman articleEnglish article Government surveillance – XKeyscore XKeyscore

4. Introduction to Communication Protocols Alice & Bob register with application server. Alice wants to call Bob. – Signaling message travels to server – Server does a lookup on Bob’s current IP address. – Server sends signaling msg to Bob. Alice and Bob exchange data traffic.

5. What route does data take? What data? – Voice, video, real-time text, text, data Routing: – “Directly” between the two endpoints Example: ICE use with XMPP JingleICEXMPP Jingle – Via application servers Example: Regular XMPP instance messaging – Via some other servers TURN relays, VPN overlays, Onion routing network In general, an application provider can influence data path routing.

6. Extending Basic Scenario Interconnection Common scenario for VoIP-PSTN interworking.

7. Typical Questions What technology is used by the two providers? What interconnection technology is used? How many intermediaries are along the path? What do the intermediaries get to see? (signaling only? Data as well?)

8. Outsourcing the Identity Provider WebRTC-based JavaScript APIs

9. Security & Privacy 1.Protect signaling traffic (hop-by-hop) 2.Protect data traffic (end-to-end) 3.Convey identity information (or hide it)

10. Protect Signaling Traffic Server-to-Server: – Use TLS (or IPsec) with mutual authentication between servers. End device-to-Server: – Use server-side authenticated TLS between end device and application server. – Various user authentication techniques deployed. Protects against eavesdroppers on the wire. Does not protect against application servers collecting data about user behavior.

11. Protect Data Traffic Depends on the assumptions of who to trust and the anticipated capability of the adversary. – There are also challenges in the interworking with existing technologies. Examples: – ZRTP assumes that calling parties recognize their voice. – DTLS-SRTP assumes that SIP identity protects the fingerprints. A summary of the requirements and use cases can be found in RFC 5479.RFC 5479

12. Convey or Hide Identity Information In the context of VoIP this typically means the calling party identifier (phone number or URI) + contact information. Two approaches have been developed: – Chain of Trust approach (e.g., P-Asserted-Identity)P-Asserted-Identity – Cryptographic approach (e.g., SIP Identity)SIP Identity Various problems surfaced with the chain of trust approach (which is also used in today’s telephone system) with caller-id spoofing and telephony denial of service attacks. A more detailed discussion of the topic can be found here. here

13. Recommendations (To VSPs) Transparency about the Data Collection and Use – What information is collected by whom and for what purpose? What is the retention period? User Participation – What are the controls for users to control sharing with other users and with intermediaries? e.g., identity information – Ability to review and revoke access to camera, microphone, etc. Security – Mandatory security for signaling traffic – Mandatory E2E security for data traffic? – Perfect forward secrecy to avoid future compromise? Perfect forward secrecy – Protection against unauthorized access – Regular software updates to address vulnerabilities Privacy-friendly defaults

14. Recommendations, cont. (To VSPs) Re-use open standards / open source that enjoyed wider community review (  transparency) Allow users to choose their identity provider (  competition and choice) Offer federated use and data portability (  competition and choice) Preference for cryptographic identity conveyance (  misattribution & intrusion) Offer capabilities for direct exchange of data (  data minimization)

15. Recommendations (To Users) Select application providers operating in jurisdictions you feel comfortable with (  applicable data protection laws)

16. Final Remarks Are these recommendations detailed enough? What is the likelihood that those recommendations will be considered by VSPs? Should we provide recommendations to other parties as well? (e.g., open source developers, standardization organizations) How to support innovation in the application space?