[Standards] end to end encryption vs. usability and feature

Olivier Goffart ogoffart at kde.org
Mon Feb 26 21:22:18 UTC 2007


Hello,

I heard that the XSF want to push end-to-end encryption for everyone in order 
to have a "secure" network with respect the privacy.
I think this is not worth, and this is even a bad thing.

I have not read all the security XEP, because they are way too long.

Anyway, here is what i understand :
TLS is actually used to encrypt internet connection between clients and 
servers, and between servers.  So the servevers are the only point of 
faillure. One of the assumption (that need to be proved) is that we don't 
trust servers, so end-to-end encryption is required.

But a normal user don't care about privacy.
So it need to be simple, or nobody will use it.  And that's why existing 
extentions like PGP are used only by geeks : because generating keys and 
sharing them is complex.

So to work, we need a simple, and automatic and transparent for the user way 
to do e2e encryption.

But I pretend this is not possible !

Let's see some protocol like OTR :  
You generate a private and public key, and you send the public key to your 
contact so it can generate a session key with it.
Problem : the public key is routed thought the server, which is not trusted. 
So the server can sand another key to the contact, and be the "man in the 
middle"

There is no way to get this working without key certification, which can't be 
user friendly. (no way to make this transparent for the user)

Also, I think the server can be trusted.  The server is an entity you may 
choose. You can use a server hosted in the country you wish. You may even run 
the server yourself.  And if the server is trusted, and if TLS is used, all 
the chain is secure,  without e2e encryption.

The problem with e2e encryption is that 
 - It make the client more complex. 
 - Lot of feature are not possible anymore (multicast, caching some 
information (like in XEP-0115),  automatic server archive, ... )

And i think than having something more complex, which isn't secure in the end, 
and which make loss of features is not a good thing.

-- 
Olivier
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070226/bb40a177/attachment.sig>


More information about the Standards mailing list