Re: [Standards] Deprecating XEP-0138: Stream Compression
On Mon, Aug 29, 2016 at 09:29:23AM +0200, Florian Schmaus wrote: > On 29.08.2016 05:29, Sam Whited wrote: > > 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? > > Exactly. I don't think that XEP-0138 as whole should be deprecated. Not > every compression mechanism may be vulnerable to the class of attacks. > Even zlib can very likely be made secure by using "full flush". I also > think that the worsened compression ratio by doing so, can be cushioned > by only performing a full flush, i.e. dropping the > dictionary/compression state, if the receiving entity changes. > > […] > > Of course, both entities of an XMPP connection would need to perform > this on their outgoing stream. > > I don't think that we will reach consensus on deprecating XEP-0138. But > I think we all agree that the XEP should discuss the known security > issues in the "Security Considerations" section. So instead of focusing > on deprecating the XEP, I suggest we first add this information to the XEP. > > - Florian > I was reminded about the XEP while browsing PIFT [1], and while wondering if I should implement/enable it, I had a faint memory about security issues concerning compression. So, while searching my inbox for clues, I found this thread which didn’t evolve since 2014. I would be happy with a substantial update to the security considerations as well. Actually, if 0138 implementations were limited to the platforms described in the XEP introduction, it wouldn’t be an issue at all, which is why I agree that deprecacting the XEP might be overkill. [1] https://www.zash.se/xmpp-clients.html signature.asc Description: PGP signature ___ 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 Sun, Aug 28, 2016 at 08:57:11PM +0100, Dave Cridland wrote: > 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. Makes sense, I was only nitpicking a bit; it is after all only a recommendation XEP, but it’s kind of weird to build a client that fits "Advanced Client" with 2012 compliance suites but not even "Core Client" under 2016 suites. > 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. I was only asking; if you feel it would complicate the XEP, then it’s not worth it, since not fulfilling the requirements for a profile doesn’t stop a client developer from doing anything. > > > 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" ...? > Sure. I’ll whip up a PR for that soon-ish. > > > > 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 ___
Re: [Standards] XEP-0356 (Privileged Entity)
It occurs to me, also, that even in the “managed_entity” type, the component may need to know who’s sending presence, because it may handling presence in multiple roles, and so even there, it makes sense to have the stanzas use XEP-0297. -bjc > On 29-Aug-2016, at 10:12, Brian Cully wrote: > > When dealing with presence information from the standpoint of the > privileged entity, we lose information about to whom the original > (non-forwarded) presence was sent. This wouldn’t affect the semantics when > the privilege is of type “managed_entity”, but when it’s “roster” it’s > important to know when using directed presence. > > I propose that, like stanzas, stanzas also use > XEP-0297, so the privileged entity can extract the original ‘to’ attribute > when necessary. I also like that it gives parity to both incoming stanzas > cases, but that’s a fairly small concern. > > -bjc ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [Council] Council Meeting 2016-08-24
On 29 August 2016 at 16:44, Tobias Markmann wrote: > > On Mon, Aug 29, 2016 at 2:16 PM, Tobias Markmann > wrote: >> >> ## Roll call >> >> - Lance (chairing) >> - MattJ >> - Tobias > > > Forgot to mention those absent: > - Dave > - Peter > > I assume they'll also vote on list. > I commented already, when I saw EME, that I would not object to it (and that I'd miss these meetings). :-) >> >> >> ## 1) Accept EME? http://xmpp.org/extensions/inbox/eme.html >> - Lance +1 >> - MattJ on list >> - Tobias on list > > > +1 on this. > > Cheers, > Tobi > > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Council Meeting 2016-08-24
On Mon, Aug 29, 2016 at 2:16 PM, Tobias Markmann wrote: > ## Roll call > > - Lance (chairing) > - MattJ > - Tobias > Forgot to mention those absent: - Dave - Peter I assume they'll also vote on list. > > ## 1) Accept EME? http://xmpp.org/extensions/inbox/eme.html > - Lance +1 > - MattJ on list > - Tobias on list > +1 on this. Cheers, Tobi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0356 (Privileged Entity)
When dealing with presence information from the standpoint of the privileged entity, we lose information about to whom the original (non-forwarded) presence was sent. This wouldn’t affect the semantics when the privilege is of type “managed_entity”, but when it’s “roster” it’s important to know when using directed presence. I propose that, like stanzas, stanzas also use XEP-0297, so the privileged entity can extract the original ‘to’ attribute when necessary. I also like that it gives parity to both incoming stanzas cases, but that’s a fairly small concern. -bjc ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Meeting 2016-08-24
# 2016-08-24 Council Meeting Logs: http://logs.xmpp.org/council/2016-08-24/#15:15:10 ## Roll call - Lance (chairing) - MattJ - Tobias ## 1) Accept EME? http://xmpp.org/extensions/inbox/eme.html - Lance +1 - MattJ on list - Tobias on list ## Date of next 2016-08-31 15:15:00 UTC ## AOB None ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Deprecating XEP-0138: Stream Compression
On 29 Aug 2016 04:30, "Sam Whited" wrote: > > 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? > Very much agree. Where radio is used, for example, encryption can be applied at the link layer, fully padded, which defeats all such attacks. In other cases, the general approach of stimulating known traffic from a particular entity can be used to gain information even in the absence of compression. As examples, you can determine if a particular client is in a chatroom by sending traffic to that chatroom, for example. My understanding of the attacks is that they leak metadata, in XMPP, rather than credentials as in HTTP - and they still require the ability to both stimulate traffic and observe the full packet flow. > —Sam > > > -- > Sam Whited > pub 4096R/54083AE104EA7AD3 > ___ > 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] Depreciating XEP-0146: Remote Controlling Clients
On 27.08.2016 14:27, 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! +1 for deprecating it. But let's not just put the status to 'deprecated' but also let us add a short note about the intended alternatives in order to provide guidance regarding the upgrade path. - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Deprecating XEP-0138: Stream Compression
On 29.08.2016 05:29, Sam Whited wrote:
> 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?
Exactly. I don't think that XEP-0138 as whole should be deprecated. Not
every compression mechanism may be vulnerable to the class of attacks.
Even zlib can very likely be made secure by using "full flush". I also
think that the worsened compression ratio by doing so, can be cushioned
by only performing a full flush, i.e. dropping the
dictionary/compression state, if the receiving entity changes.
Pseudocode:
---
So instead of
List outgoingElements = ...
for (StreamElement e : outgoingElements) {
socket.write(e);
// Drop compressor state.
socket.fullFlush();
}
we get
List outgoingElements = ...
Jid lastTo = null;
for (StreamElement e : outgoingElements) {
socket.write(e);
if (lastTo != e.getTo()) {
// Drop compressor state.
socket.fullFlush();
}
lastTo = e.getTo();
}
Of course, both entities of an XMPP connection would need to perform
this on their outgoing stream.
I don't think that we will reach consensus on deprecating XEP-0138. But
I think we all agree that the XEP should discuss the known security
issues in the "Security Considerations" section. So instead of focusing
on deprecating the XEP, I suggest we first add this information to the XEP.
- Florian
signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
