[Standards] xep-027 encrypted filetransfers

Matthew Miller linuxwolf at outer-planes.net
Wed Oct 17 15:21:30 UTC 2012


On Oct 17, 2012, at 08:26, Peter Saint-Andre <stpeter at stpeter.im> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 10/17/12 5:57 AM, Александр wrote:
>> On Пятница, 12-окт-2012 00:46:57 Александр wrote:
>> 
>> On Четверг, 11-окт-2012 23:33:48 Andreas Kuckartz wrote:
>> 
>>> Александр:
>> 
>>>> Hi all, i have implemented encrypted filetransfers in my
>> 
>>>> realization of xep-027 in new_gpg plugin fro miranda im/ng,
>>>> but
>> 
>>>> currently it supported only in miranda, i would like to extend
>> 
>>>> xep-027 to have defined encrypted filetransfers. is it possible
>>>> ?
>> 
>>> 
>> 
>>> Did you look at XEP-0234 ?
>> 
>>> 
>> 
>>> Cheers,
>> 
>>> Andreas
>> 
>> 
>> 
>> not yet, but my method implement encrypted transfers for any type
>> of filetransfer, not just jingle (which as i know not supported by
>> most clients currently ?), but my method is very primitive ....
>> 
>> 
>> 
>> i have looked on XEP-0234 and related XEP's, found only some
>> information about optional ssl/tls encryption, but this is not
>> end-to-end, and not pgp like, i mean it's vulnerable to man in
>> middle attack on server side, ot i have missed something ?
> 
> We have not yet defined end-to-end encryption of file transfers. One
> way would be for the sender to encrypt each stanza to the public key
> of the recipient, and then chunk out the file using XEP-0047. However,
> that won't work well for huge files because it will take a long time
> to transfer the file. Another way would be to run your own trusted
> file transfer proxy, use XEP-0065, and require SSL/TLS on both ends of
> the proxy. I'm sure there are other solutions, too (e.g., for a while
> we were discussing something called XTLS). It's not such an easy
> problem to solve, but your ideas are welcome.
> 

Right.

It's important to separate what the content is from how it is transported.  Both [SI] and [JINGLE] do this to allow for agility in transport (Jingle more so than SI), increasing the chance of a successful transfer.  I don't see how relying purely on XEP-0047 does this.  Plus, I expect XMPP service operators would take exception to the transfer of extremely large data through a topology designed for lots of rather small chunks of information.

A more palatable approach is to define a new SI profile (similar to XEP-0096) or Jingle descriptor (similar to XEP-0234) that indicates the data to exchange is encrypted before entering the transport layer.  The actual key exchange could be done in a number of ways; < http://tools.ietf.org/html/draft-miller-xmpp-e2e> has one possible approach included.


- m&m

Matthew A. Miller
<http://goo.gl/LK55L>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2305 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20121017/57dfc070/attachment.bin>


More information about the Standards mailing list