[OTR-dev] OTR Encrypted File Transfer, Spec Draft

[Hans-Christoph Steiner]

On 06/10/2013 07:41 PM, Dev Random wrote:
> On 06/10/2013 04:15 PM, Hans-Christoph Steiner wrote:
>>
>> On 06/10/2013 06:45 PM, Paul Wouters wrote:
>>> On Wed, 5 Jun 2013, Hans-Christoph Steiner wrote:
>>>
>>>> Rate limiting will affect both XMPP in-band and OTR in-band the same.  Only an
>>>> out-of-band file transfer would get around that.  So we'll need to find a way
>>>> to deal with that gracefully regardless of whether its in-band XMPP or OTR.
>>>
>>> Why not provide a URI that defines the transport mechanism? If we are
>>> now already discussing the limits of one kind of file transfer
>>> mechanism, we're bound to need different ones over time.
>>>
>>> Providing a URI could also mean I can encrypt it and put it up on an ftp
>>> server.
>>>
>>> Paul
>>
>> I like that idea, so you'd have something like:
>>
>> XMPP-side-channel://
>> XMPP-in-band://
>> otr-in-band://
>> https://
>> ftp://
>> sftp://
> 
> This seems to fit with the idea to have HTTP-like headers and verbs.  So
> you could do something like:
> 
> OFFER otr-in-band:/filename1.ext
> 
> and if peer approves, their user-agent does:
> 
> GET otr-in-band:/filename1.ext

Yes!  Then there could also be a failure mode to renegotiate if the transfer
does not complete for any reason.  So it would try OTR-in-band first, if that
fails because of rate limiting, for example, then it would bump to
XMPP-side-channel with TLV8.  Maybe there could be a UDP mode via STUN servers
as a firewall failsafe if you really need to get the data thru, privacy leak
or not.  That UDP mode could still be encrypted using TLV8.

Perhaps these would also be possibilities:
dropbox://
google-drive://
mega://

etc.

.hc