[jdev] JSXC/WebRTC

[Marcel Waldvogel]

I use „end-to-end encryption“ in contrast to „gateway-to-gateway“ (or „hop-by-hop“) encryption which is provided by the concatenation of multiple TLS-based c2s and s2s connections.

But it seems that I’ve stirred up a hornets’ nest with that statement. My understanding of end-to-end goes back to „End-to-End Arguments in System Design“ (Saltzer, Reed, and Clark, 1981). It says that the function is provided without intermediaries, i.e., does not need to be re-encrypted at intermediary servers. It is not meant to indicate „unbreakable“ or similar. Maybe an example helps:

I guess you would all agree that OTR provides end-to-end encryption as well. Assume an implementation bug or failure to compare fingerprints. IMHO, the encryption is still end-to-end, but may be vulnerable to MITM.

The same is true for WebRTC. But we appreciate any progress in this field and will do whatever we can to make our RTP channel more secure. (For example, we would like to use ZRTP for interoperability with Jitsi, which happens to be my native XMPP client of choice…)

-Marcel

PS: Going beyond XMPP/JSXC, I feel that we should make more and more data encrypted, leaking less and less information. We require two directions, which, depending on the use case can be in any order:
(1) make products using encryption easy to use and therefore widespread. For this step, even opportunistic encryption is good enough.
(2) make products watertight, so they are immune to active or pervasive attacks (this also implies the reduction of metadata).
Together, they will lead to a more secure world. But, if only one is available, I’ll take the one which is without waiting for the other. (Some more thoughts about mechanisms in either direction can be found at https://netfuture.ch/publications/)

Back to JSXC: By reducing the entry threshold to general users, we can get them away from other, centralized/proprietary services, to the federated infrastructure of XMPP. Unfortunately, for a large part of the younger generation, even the better educated ones, services only exist if they are not preinstalled on their device or are web-accessible. JSXC is our approach to make the transition as easy as possible. When they get the hang of it, they can go for native clients, which always has more flexibility and power.

Am 15.06.2014 um 14:25 schrieb Emil Ivov <emcho at jitsi.org>:
> 
> On 13.06.14, 21:33, Philipp Hancke wrote:
>> Am 13.06.2014 14:02, schrieb Emil Ivov:
>>> Hey Marcel,
>>> 
>>> Congrats for the release.
>> 
>> same here, ^5 Klaus!
>> 
>>> One question
>>> 
>>> On 12.06.14, 18:40, Marcel Waldvogel wrote:
>>>> * End-to-end encrypted audio and video calls from Firefox and Chrome
>>>> without plugin
>>> 
>>> Is this referring to WebRTC's use of DTLS-SRTP? Because, if so,
>>> "end-to-end" is a bit misleading given that today's implementation of
>>> DTLS-SRTP there is vulnerable to to MitM attacks from the service
>>> provider.
>> 
>> Well, it's end-to-end. It's not end-to-end with authenticated peers.
> 
> Sure but isn't that a core promise of and what's really meant by end-to-end? Without that constraint SDES would also qualify.
> 
> Quoting wikipedia:
> 
> "The intention of end-to-end encryption is to prevent intermediaries, such as Internet providers or application service providers, from being able to discover or tamper with the content of communications. "
> 
> There's currently no such protection in WebRTC's current DTLS-SRTP implementation.
> 
> Emil
> 
> 
> 
> -- 
> https://jitsi.org
> _______________________________________________
> JDev mailing list
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.jabber.org/jdev/attachments/20140615/3d903f3d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4570 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20140615/3d903f3d/attachment.bin>