On 11 December 2017 at 20:15, Kevin Smith <kevin.sm...@isode.com> wrote: > On 29 Nov 2017, at 19:16, Jonas Wielicki (XSF Editor) <jo...@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@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-unsubscr...@xmpp.org > _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
