Re: [Standards] XEP-0375 (XMPP Compliance Suites 2016) clarification

[Sam Whited]

On Sun, Aug 28, 2016 at 2:34 PM, Mathieu Pasquet  wrote:
> Could we get a footnote for User Avatar saying that clients having
> specific restrictions (e.g. console clients like poezio, profanity,
> mcabber, freetalk…, or dedicated clients, for example if someone makes a
> client for blind people) do not have to implement it? It is obviously
> possible to implement with some quirks, but much less relevant to the
> users’ needs.

I don't really think we need a footnote; if we add a footnote for
every possible exception that may be relavant to some special
client we'd end up with a lot of footnotes, and it should be
fairly obvious that it doesn't make sense to implement user avatars in
a console client.

> Also I would replace in the specific sentence “Only one of the
> recommended providers must be implemented for compliance. ”, the use of
> “must”, with “needs to”. Otherwise one could confuse it with having a
> limitation of one provider for the service.

Yes, sorry, this needs to be clarified; I'll try to remember to get
too it the next time I end up working on the document, however, I
sadly no longer have the luxury of working on XMPP related things
during work hours (at least, not as much as I could before), so I'm a
bit slow and really just working on one thing at a time at the moment
(currently some MIX revisions). Pull requests welcome.

—Sam


-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Deprecating XEP-0138: Stream Compression

[Sam Whited]

On Sun, Aug 28, 2016 at 2:53 PM, Mathieu Pasquet  wrote:
> Two years late, but can we deprecate it XEP-0138 now, lest someones
> comes along and implements/enables it in their client?

Though I'm aware of the security risks, stream compression is still
useful, and may even be necessary in some deployments. Maybe it would
be better to just expand the security section to explain when stream
compression might be a risk instead of deprecating the entire (still
useful) XEP?

—Sam


-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0375 (XMPP Compliance Suites 2016) clarification

[Dave Cridland]

On 28 August 2016 at 20:34, Mathieu Pasquet  wrote:
> On Wed, Jul 20, 2016 at 02:22:48PM +, XMPP Extensions Editor wrote:
>> Version 0.3 of XEP-0375 (XMPP Compliance Suites 2016) has been released.
>>
>> Abstract:
>>   This document defines XMPP protocol compliance levels for 2016.
>>
>>
>> Changelog: [See revision history] (ssw)
>>
>> Diff: http://xmpp.org/extensions/diff/api/xep/0375/diff/0.2/vs/0.3
>>
>> URL: http://xmpp.org/extensions/xep-0375.html
>>
>
> Hi,
>
> Could we get a footnote for User Avatar saying that clients having
> specific restrictions (e.g. console clients like poezio, profanity,
> mcabber, freetalk…, or dedicated clients, for example if someone makes a
> client for blind people) do not have to implement it? It is obviously
> possible to implement with some quirks, but much less relevant to the
> users’ needs.
>

If a typical user wanted an XMPP client, they'd want graphical
avatars. Poezio (and mcabber, profanity, etc) are all great clients,
but they're quite obviously niche clients, and I worry that building
in exceptions might end up with a horribly slippery slope.

That said, I take your point, and I don't want to exclude these
clients entirely either if we can come up with some sane language.

> Also I would replace in the specific sentence “Only one of the
> recommended providers must be implemented for compliance. ”, the use of
> “must”, with “needs to”. Otherwise one could confuse it with having a
> limitation of one provider for the service.
>

Perhaps "a minimum of one" ...?

>
> Thanks
>
>
> --
> Mathieu Pasquet (mathieui), poezio developer
>
> ___
> 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] Deprecating XEP-0138: Stream Compression

[Mathieu Pasquet]

On Tue, Oct 14, 2014 at 02:48:42PM +0200, Thijs Alkemade wrote:
> 
> On 9 okt. 2014, at 17:06, Peter Saint-Andre -   wrote:
> 
> > On 10/9/14, 7:59 AM, Thijs Alkemade wrote:
> >> Hello all,
> >> 
> >> Stream compression is insecure, that was shown with CRIME and BREACH and 
> >> the
> >> situation for XMPP isn't much different [1]. I think we should look at the
> >> easiest way to deprecate XEP-0138 and move to something better.
> >> 
> >> Using a "full flush" (in zlib terms) after every stanza would solve the
> >> problem, as I can't find any realistic examples where an attacker could 
> >> insert
> >> their own payload into the same stanza as something secret they want to 
> >> know.
> >> However, clients and servers have no way to negotiate a mode like that, so
> >> it's not possible to reject connections that won't do a per-stanza full 
> >> flush.
> >> Reading draft-ietf-hybi-permessage-compression-18, I was happy to see that 
> >> this
> >> could be negotiated in WebSocket extension [2].
> >> 
> >> From my own (very small scale) tests with raw XMPP XML, it appears that 
> >> full
> >> flushing after every stanza yields about the same compression ratio as
> >> compressing each stanza separately. Doing that would have a number of
> >> advantages:
> >> 
> >> 1. Not relying on nothing leaking through the "full flush", which may be a
> >> concept that other compression algorithms than zlib don't have or don't do
> >> securely enough.
> >> 
> >> 2. Practically no memory overhead in the server or client between messages.
> >> There's no context to keep around, each new message can be decompressed 
> >> with a
> >> fresh new context. Memory overhead for compression is a real concern for
> >> servers: one of the reasons Prosody was pushing for XEP-0138 to replace TLS
> >> compression was that it's impossible configure the memory use of TLS
> >> compression to sane levels in OpenSSL.
> >> 
> >> However, it also has downsides. It requires either:
> >> 
> >> 1. That the concatenation of two compressed stanzas can be separated
> >> unambiguously.
> > 
> > Could you explain that a bit more? For example, are you talking about 
> > compressing two stanzas and sending them in the same TCP packet?
> 
> Instead of sending:
> 
> zlib(“...”)
> 
> (Where you’d occasionally send the compressed data you have so far.)
> 
> You'd send:
> 
> zlib(“”) + zlib(“”) + zlib(“”) + zlib(“”)
> 
> (Where + is concatenation.)
> 
> This is easy in zlib because it’s possible to tell when a zlib stream ends 
> [1][2].
> 
> > 
> >> 2. Or that we apply framing outside of compression (which I expect to be
> >> another can of worms).
> > 
> > Yes, I'd expect so. I recall debates about framing (or the lack thereof) 
> > for XMPP on this very list from over 10 years ago. ;-)
> > 
> > a> zlib has a header bit that indicates whether a block is the last block 
> > in a
> >> stream, but again, that might be zlib-specific.
> > 
> > Would it be worthwhile to investigate what the various compression 
> > algorithms support here?
> 
> I've been trying to look into LZW, as it is described by XEP 0229, but while I
> can find enough descriptions of the algorithm itself, I can't find much about
> the output encoding. Most of the LZW API's I've seen also have no flush-method
> or something similar.
> 
> Regards,
> Thijs
> 
> [1] = http://zlib.net/manual.html:
> 
> "If the flush parameter is Z_FINISH, the remaining data is written and the
> gzip stream is completed in the output. If gzwrite() is called again, a new
> gzip stream will be started in the output. gzread() is able to read such
> concatented gzip streams."
> 
> [2] = https://docs.python.org/2/library/zlib.html#zlib.Decompress.unused_data
> 

Two years late, but can we deprecate it XEP-0138 now, lest someones
comes along and implements/enables it in their client?

Best regards,

-- 
Mathieu Pasquet (mathieui), poezio developer


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

[Standards] XEP-0375 (XMPP Compliance Suites 2016) clarification

[Mathieu Pasquet]

On Wed, Jul 20, 2016 at 02:22:48PM +, XMPP Extensions Editor wrote:
> Version 0.3 of XEP-0375 (XMPP Compliance Suites 2016) has been released.
> 
> Abstract: 
>   This document defines XMPP protocol compliance levels for 2016.
> 
> 
> Changelog: [See revision history] (ssw)
> 
> Diff: http://xmpp.org/extensions/diff/api/xep/0375/diff/0.2/vs/0.3
> 
> URL: http://xmpp.org/extensions/xep-0375.html
> 

Hi,

Could we get a footnote for User Avatar saying that clients having
specific restrictions (e.g. console clients like poezio, profanity,
mcabber, freetalk…, or dedicated clients, for example if someone makes a
client for blind people) do not have to implement it? It is obviously
possible to implement with some quirks, but much less relevant to the
users’ needs.

Also I would replace in the specific sentence “Only one of the
recommended providers must be implemented for compliance. ”, the use of
“must”, with “needs to”. Otherwise one could confuse it with having a
limitation of one provider for the service.


Thanks


-- 
Mathieu Pasquet (mathieui), poezio developer


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

[Standards] Depreciating XEP-0270 and advancing XEP-0302 to draft standard

[Emmanuel Gil Peyrot]

Hello,

It might be a bit late for that, but I’d like to propose a Last Call
for XEP-0302 (XMPP Compliance Suites 2012), in order to depreciate
XEP-0270 (XMPP Compliance Suites 2010).  At this point it might make
more sense to focus on XEP-0375 (XMPP Compliance Suites 2016) instead,
but having three different versions in flight is not very useful.

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

Re: [Standards] Depreciating XEP-0146: Remote Controlling Clients

[Peter Saint-Andre]

On 8/27/16 6:27 AM, Emmanuel Gil Peyrot wrote:

Hello,

I’d like to propose deprecating XEP-0146, on the basis that some of its
features are a security hazard, some overlap with better solutions
available now, and some are just kind of useless.

XEP-0146 defines five use-cases:
1. Change status
2. Forward unread messages residing at the remote client to the local
   client
3. Change run-time options
4. Accept pending file transfer requests
5. Leave groupchats

Of those, 2. is the biggest problem, at least some implementations will
happily send a plain-text version of their logs to any other resource
requesting it.  It is also a use-case solved in a much nicer way by
XEP-0313.

The main reason for 4., poor routing of iq-based file transfers, is
already solved by XEP-0353 (alongside XEP-0280 in some situations).  It
might make sense to keep this feature for other reasons, like if you
are on a bandwidth-limited mobile network but want to accept a big file
transfer on your home server so you can have the file once you come
home, I don’t feel strongly about deprecating this part of XEP-0146.

The rest of the use-cases can possibly be security issues as well
(especially 3. depending on what gets exposed), but are mostly not
really useful, especially with the direction XMPP is moving to (like
MIX using PAM to handle groupchat join-ness, or multiple resources
being more hidden in modern UIs).

So I propose deprecating this XEP, or at least the bad parts of it, or
at least improving the Security Considerations, let’s discuss!


IMHO XEP-0146 was always a somewhat informal proposal and not widely 
implemented, so I'd be in favor of deprecating it (especially because of 
the security holes).


Peter

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

Re: [Standards] Proposed XMPP Extension: Explicit Message Encryption

[Emmanuel Gil Peyrot]

Hello,

I proposed a newer version[1] which tried to fix every piece of
feedback I received on this thread and elsewhere, direct or indirect,
please comment. :)

I chose to keep the 'name' attribute, but made it optional, and let
i18n issues be determined by the sending client if it wants to add it.

[1] https://github.com/xsf/xeps/pull/241

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