[jdev] JSXC/WebRTC

[Emil Ivov]

Hey Marcel,

Thanks for responding. I certainly didn't mean to appear aggressive or 
criticise the client as a whole. I definitely think it is an awesome 
project and wish you good luck maturing and extending it!

I don't really agree with the views you express below but I have been 
discouraged offlist from continuing the discussion and I certainly 
didn't want it to be construed as anti-client to begin with, so please 
feel free to ignore my comment!

Good luck and congrats once again!

Emil

On 15.06.14, 16:58, Marcel Waldvogel wrote:
> 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
> <mailto: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 <https://jitsi.org/>
>> _______________________________________________
>> JDev mailing list
>> Info:http://mail.jabber.org/mailman/listinfo/jdev
>> Unsubscribe:JDev-unsubscribe at jabber.org
>> <mailto:JDev-unsubscribe at jabber.org>
>> _______________________________________________
>
>
>
> _______________________________________________
> JDev mailing list
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________
>

-- 
https://jitsi.org