[Standards] File Transfer Roadmap

Georg Lukas georg at op-co.de
Mon Jul 27 08:22:26 UTC 2015


* Sam Whited <sam at samwhited.com> [2015-07-27 00:35]:
> With that in mind, I'd like to know what the council (and everyone
> elses) opinion is of moving Jingle File Transfer forward in the process?

I am strictly against pushing forward a mechanism that does not specify
strong, mandatory, end-to-end encryption. We have had mandatory
encryption on s2s links for over a year now, thanks to the Manifesto.
And now we are going to promote plain-text transfers for the really
sensitive data (it's not all lolcats and funny jingles)?

It looks like IBB is currently the only specification that does not
reduce the media transfer security compared to normal chats, at the cost
of killing the server's performance and traffic bills.

There is a bunch of different encryption ideas, implementations and
proposals that all failed to gain adoption so far. I think we need to
evaulate them and pick a winner, which should be promoted into an XEP
then:

 * XEP-0116: Encrypted Session Negotiation (Deferred since 2007)
 * XEP-xxxx: XMPP Transport Layer Security (stale since 2009)
 * OTRv3 media keys (obviously requires OTR; also broken for
     the multi-client use cases)
 * ZRTP (used in Jingle for VoIP traffic)
 * End-to-End Object Encryption (draft-miller-xmpp-e2e; expired in 2013)
 * ChatSecure's HTTP transfers over OTR over XMPP messages
 * Conversations' HTTP Uploader with the key appended to the URL
 * Axolotl (also solves multi-client end-to-end chats; currently
     implemented in Conversations as a GSoC)
 * WebRTC (would allow interop with browsers, if done right; also solves
     the NAT problem; already implemented in jitsi-videobridge?)

Personally, I think that Axolotl and WebRTC are the two strongest
candidates here, with the former establishing a secure channel between
the two (or N) clients, from where a media encryption protocol still
needs to be derived (maybe in combination with Jingle). The latter does
not secure regular messages, and I suppose it does not allow
peer-to-multi-peer data transmissions without a trusted hub server, but
it gives us NAT traversal and interop with browsers.


Georg
-- 
|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y?   ||
++ IRCnet OFTC OPN ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150727/1376c8e7/attachment.sig>


More information about the Standards mailing list