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 <[email protected]
<mailto:[email protected]>>:
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:[email protected]
<mailto:[email protected]>
_______________________________________________
_______________________________________________
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [email protected]
_______________________________________________
--
https://jitsi.org
_______________________________________________
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [email protected]
_______________________________________________
