[Standards] LAST CALL: XEP-0363 (HTTP File Upload)

Dave Cridland dave at cridland.net
Tue Dec 12 11:07:32 UTC 2017


On 11 December 2017 at 20:15, Kevin Smith <kevin.smith at isode.com> wrote:
> On 29 Nov 2017, at 19:16, Jonas Wielicki (XSF Editor) <jonas at wielicki.name> wrote:
>> This message constitutes notice of a Last Call for comments on
>> XEP-0363.
>>
>> Title: HTTP File Upload
>> Abstract:
>> This specification defines a protocol to request permissions from
>> another entity to upload a file to a specific path on an HTTP server
>> and at the same time receive a URL from which that file can later be
>> downloaded again.
>>
>> URL: https://xmpp.org/extensions/xep-0363.html
>>
>> This Last Call begins today and shall end at the close of business on
>> 2017-12-12.
>>
>> Please consider the following questions during this Last Call and send
>> your feedback to the standards at xmpp.org discussion list:
>>
>> 1. Is this specification needed to fill gaps in the XMPP protocol
>> stack or to clarify an existing protocol?
>
> Kinda. We do have file transfer mechanisms already. This tries to to address a use case that these have traditionally handled badly, although it’s not clear if an entirely new mechanism like this is required, or if it can be adequately addressed inside existing frameworks.
>

The fact it's a new mechanism worries me less than it being a new *model*.

>> 2. Does the specification solve the problem stated in the introduction
>> and requirements?
>
> Yes.
>
>>
>> 3. Do you plan to implement this specification in your code? If not,
>> why not?
>>
>> 4. Do you have any security concerns related to this specification?
>
> Should probably mention that you’re going to be handing out your IP to whichever upload service you use.
>
>>
>> 5. Is the specification accurate and clearly written?
>
> "The service SHOULD NOT impose sanctions on an entity for retrying earlier than the specified time.”
>
> Seems a bit odd - what’s the point in specifying a limit if clients are allowed to ignore it, and the server has to process the request normally anyway?
>
> "It is RECOMMENDED that the service stores the files for as long as possible which is of course limited by storage capacity.”
>
> Seems like an odd place to put normative language to me, surely limits are a local policy choice?
>

I think the impact of imposing a short-term storage is that clients
(or indeed users) expecting long-term storage will suffer
interoperability issues if they rely on this.

Furthermore, it seems possible that one of the suggestions for use
given elsewhere - PEP avatars - would be badly broken if the server
implements RFC 748.

So yes, I think this *is* an interoperability statement, but I don't
think it's addressed well in practical terms beyond handwaving, and
the specification is insufficient to describe the "RECOMMENDED" and
the pitfalls of ignoring it.

> "       • Server operators SHOULD consider the responsibility that comes with storing user data and MAY consider appropriate measures such as full disk encryption.”
>
> And I’m not sure that a XEP can do much normatively about full disk encryption.
>

Oh, I think it can -  this MAY is a security threat mitigation -
although the actual threat is not discussed, and being truly optional
it serves essentially no benefit. You could do a lot more fun things
than this, depending on the threat model.

On the other hand "Server operators SHOULD consider" is useless - this
appears to be ordinary English language, used as a sort of security
virtue signalling, and masquerading as RFC 2119. There is no
interoperability benefit here, nor any security threat or mitigation
defined.

In general, the Security Considerations section appears to be written
like this throughout. "Client implementors MUST consider" does not
make any interoperability statement either.

What's needed here is a set of threats, and how to mitigate them, and
not vague platitudes on how it'd be nice if we all really thought
about it.

>
> Not related to the writing of the XEP, but the approach: this doesn’t cross security boundaries well. While jingle will fall back to IBB (and servers can enforce that fallback), keeping the flow under their control, and allowing data to cross network boundaries, 363 falls apart in the face of non-Internet (and even some Internet) use cases. This is going to become quite relevant to MIX, where you’re going to want to upload files to the MIX, but may well not be able to route to it and would need your server to do pass-through. I *think* (but have not tried to write it) that one could spec a relatively simple pass-through mechanism for this.
>

As noted above, this is changing file transfer from being a
communications path into a store and forward. I don't think that's
necessarily a bad thing, actually, but there's a lot of deployments
where, as you say, this model isn't going to work at all, and it'd be
interesting to consider how they might be unified.

> /K
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________


More information about the Standards mailing list