Re: [Standards] XEP-0375 (XMPP Compliance Suites 2016) clarification
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
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
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
On Tue, Oct 14, 2014 at 02:48:42PM +0200, Thijs Alkemade wrote: > > On 9 okt. 2014, at 17:06, Peter Saint-Andre - &yet 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
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
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
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
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 ___