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

[Sam Whited]

On Tue, Dec 12, 2017, at 15:49, Ruslan N. Marchenko wrote:
> Yes, I don't like the approach with wide open PUT limited by certain 
> high-level content constraints and (luckily) headers in the latest
> revision.
> At least content hash (as in jingle) would be beneficial. Shall we say 
> slot path element (public one) should be content hash (and hence part of 
> request)?
> That allows all 3 parties (sender, mediator, receiver) to verify somehow 
> validity of the content. Otherwise there's possibility of the content 
> injection.

The PUT is not necessarily wide open: that's a matter of service policy.
The addition of required headers means that you could require the PUT to
contain a token that is unique to the specific upload slot being
requested.
Since there are no interoperability concerns if different servers
implement this in different ways no specific mechanism needs to be
mandated by this spec.

You may not always know the content hash up front, and it may not be
desirable to read large files twice (first to generate the hash, the
second time to actually send the file to the server).

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Ruslan N. Marchenko]

On 29.11.2017 20:16, Jonas Wielicki (XSF Editor) 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?

I'm not quite sure about it. Alas it works.

2. Does the specification solve the problem stated in the introduction
and requirements?

That it does.

3. Do you plan to implement this specification in your code? If not,
why not?

Yes, because it works already.

4. Do you have any security concerns related to this specification?
Yes, I don't like the approach with wide open PUT limited by certain 
high-level content constraints and (luckily) headers in the latest revision.
At least content hash (as in jingle) would be beneficial. Shall we say 
slot path element (public one) should be content hash (and hence part of 
request)?
That allows all 3 parties (sender, mediator, receiver) to verify somehow 
validity of the content. Otherwise there's possibility of the content 
injection.

5. Is the specification accurate and clearly written?


XMPP part yes. The rest is left to implementers.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0060: Register publish options 'persist-items'

[Daniel Gultsch]

After some discussion on the XSF MUC I created a third alternative
which has the added benefit of making the language in that section a
lot clearer.

https://github.com/xsf/xeps/pull/557

2017-12-08 14:20 GMT+01:00 Daniel Gultsch :
> Hi,
>
> XEP-0048, XEP-0223 and possibly others are referencing a
> publish-option called 'persist-item'. XEP-0060 says that any
> publish-options MUST be registered. This hasn't happened yet.
>
> Here is a pull request that does: https://github.com/xsf/xeps/pull/555
> (editors will still have to pull this into the registry)
>
> as an alternative approach we could agree that every registered
> node-configuration double acts as a publish-options PRECONDITION with
> the same name.
>
> Here is a pull request that adds such wording to XEP-0060.
>
> https://github.com/xsf/xeps/pull/556
>
> This pull request also removes the possibility of registering
> publish-options as OVERRIDE (They would probably have to share the
> same name as the node-configuration publish-options and confuse
> people.
>
> These two PR are mutually exclusive.
> Pick your poison. PR#555 is a pretty simple and required for 0223 (or
> else the XEP wont work). PR#556 is a more fundamental change but
> arguably the 'saner' choice.
>
> cheers
> Daniel
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Guus der Kinderen]

On 29 November 2017 at 20:16, Jonas Wielicki  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?
>
>
Yes


> 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?
>
>
Yes


> 4. Do you have any security concerns related to this specification?
>
>
Perhaps warnings should be added that explicitly state that the TLS
configuration of the file transfer might differ from that of the XMPP
client connection, and that the receiving end might not want to
auto-display/execute data.


5. Is the specification accurate and clearly written?
>
>
Yes


> Your feedback is appreciated!
> ___
> 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
___

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

[Dave Cridland]

On 11 December 2017 at 20:15, Kevin Smith  wrote:
> On 29 Nov 2017, at 19:16, Jonas Wielicki (XSF Editor)  
> 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
> 

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

[Dave Cridland]

On 12 December 2017 at 09:10, Daniel Gultsch  wrote:
> 2017-12-11 21:15 GMT+01:00 Kevin Smith :
>> On 29 Nov 2017, at 19:16, Jonas Wielicki (XSF Editor)  
>> wrote:
>>> 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.
>
> I can add that.
>
>>
>>>
>>> 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?
>
> The point is that clients don't have to parse the timestamp and could
> just retry at their own convenience.
> Retrying earlier will of course give them the exact same error message
> again but it won't get them locked out for good or anything.

You say "will of course", but the specification says "SHOULD NOT", so
what are the reasons you're anticipating a server might impose
sanctions?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0352 (Client State Indication)

[Daniel Gultsch]

On Dec 7, 2017 18:37, "Jonas Wielicki"  wrote:

This message constitutes notice of a Last Call for comments on
XEP-0352.

Title: Client State Indication
Abstract:
This document defines a way for the client to indicate its
active/inactive state.

URL: https://xmpp.org/extensions/xep-0352.html

This Last Call begins today and shall end at the close of business on
2017-12-21.

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?


Yes


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?


Yes. I did. Like three years ago or so.


4. Do you have any security concerns related to this specification?


No


5. Is the specification accurate and clearly written?


Yes


Your feedback is appreciated!
___
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
___

Re: [Standards] LAST CALL: XEP-0352 (Client State Indication)

[Ruslan N. Marchenko]

On 07.12.2017 18:35, Jonas Wielicki (XSF Editor) wrote:

This message constitutes notice of a Last Call for comments on
XEP-0352.

Title: Client State Indication
Abstract:
This document defines a way for the client to indicate its
active/inactive state.

URL: https://xmpp.org/extensions/xep-0352.html

This Last Call begins today and shall end at the close of business on
2017-12-21.

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?


Yes.


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?

Yes.


4. Do you have any security concerns related to this specification?

No.


5. Is the specification accurate and clearly written?

It is intentionally leaves lot of space for implementers, but we can 
live with it for the time being.
Presence and bodiless stanzas are called out and they represent majority 
of the messages which could be safely dropped/delayed (yes, there's also 
omemo).


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Daniel Gultsch]

2017-12-11 21:15 GMT+01:00 Kevin Smith :
> On 29 Nov 2017, at 19:16, Jonas Wielicki (XSF Editor)  
> wrote:
>> 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.

I can add that.

>
>>
>> 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?

The point is that clients don't have to parse the timestamp and could
just retry at their own convenience.
Retrying earlier will of course give them the exact same error message
again but it won't get them locked out for good or anything.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___