[Standards] Fwd: Minutes 2014-04-23
FYI -- Forwarded message -- From: Kevin Smith Date: Thu, Apr 24, 2014 at 9:58 AM Subject: Minutes 2014-04-23 To: XMPP Council Room logs: http://logs.xmpp.org/council/2014-04-23/ 1) Roll call. Lance, Philipp, Matt, Kev present. Tobias absent. 2) http://xmpp.org/extensions/inbox/signing-forms.html Accept as Experimental No objection from Lance. Others have a fortnight to object. 3) http://xmpp.org/extensions/inbox/rayo-clustering.html Accept as Experimental Lance/Philipp to post their objections to the council/standards lists. 4) Date of next meeting 2014-04-30 15:00 UTC 5) Any other business Philipp/Peter Waher report that 'stuff is happening' in their UPnP work. Peter Waher starts a discussion on people not understanding routing rules for IQs (see logs) Fini
[Standards] -1 on rayo-clustering (was: Re: [Council] Minutes 2014-04-23)
Am 24.04.2014 10:58, schrieb Kevin Smith: Room logs: http://logs.xmpp.org/council/2014-04-23/ [...] 3) http://xmpp.org/extensions/inbox/rayo-clustering.html Accept as Experimental Lance/Philipp to post their objections to the council/standards lists. here we go... the requirements make senese. However, Nodes and Clients SHOULD NOT be aware of each others identity of presence, and SHOULD only communicate with the Gateway(s). stated later in section 4.2. actually shows why the XSF does not need to standardize this; it requires no extensions to a stock rayo client. ISTR that ejabberd allows multiple components to connect for the same domain and then does some kind of session-based loadbalancing. This is somewhat more generic but we have not standardized either either. minor issue: The spec is also using RFC 2119 language a little too often in places, where this is not required for interoperability. E.g. for using two domains or when describing load balancing. hat type=guy-who-used-to-write-servers Using resource identifiers to encode the rayo node, similar to the way google talk apparently uses them, might allow the gateway to minimize the state kept. /hat
[Standards] Nytänkande individuell vattenmätning
Sustainable Innovation är ett centrum och en mötesplats för energi-effektivisering och hållbarhet. Vi driver stora demonstrationsprojekt, uppmuntrar innovationer och nyföretagande, bedriver informations-spridning och kunskapsutveckling. Mer info på www.sust.se http://us6.campaign-archive2.com/?u=68d21840b905fc08685f24077id=f375354881e=7fe74c97cb ** Har du idéer kring individuell mätning och debitering av vatten? Datum: 7 maj Tid: 9.00-12.00 Plats: Barnhusgatan 3 Anmäl dig till joachim.lindb...@sust.se (mailto:joachim.lindb...@sust.se?subject=Jag%20vill%20vara%20med%20p%C3%A5%20workshopen%20om%20vattenm%C3%A4tningbody=Hej%20jag%20anm%C3%A4ler%20mig%20till%20workshopen%20den%207e%20maj%20) Då vet du också att det är en växande företeelse som inte riktigt fått genomslag ännu. Framförallt saknas en ekonomiskt gångbar och samtidigt säker teknik att använda i befintliga fastigheter. Detta vill vi drastiskt ändra på. Under 2014 kommer vi på Sustainable Innovation genomföra en nytänkande innovationstävling för att hitta en lösning som skulle kunna påverka hela den globala marknaden inom området. Att lösa montage och mätning skulle påverka såväl miljön som den enskilde boendes ekonomi positivt. Men för att tävlingen ska ge ett bra utslag så behöver vi din hjälp. Välkommen till Sustainable Innovation, Barnhusgatan 3 den 7 maj 2014 kl 09 - 12 på en kreativ workshop där vi tillsammans går igenom existerande tekniker, aktörer, problemområdet i stort, lagar och regler samt ansvar. Syftet är att hitta ett underlag för tävlingen där det blir tydligt vem eller vilka vi ska vända oss till för att få goda tävlingsbidrag, hur tävlingen bäst bör beskrivas. Vi vill inte låsa fast oss i befintliga tekniker eller lösningar utan målet är att tävlingen skulle kunna gå utanför befintliga ramar. Varmt välkommen! Sustainable Innovation AB, ** Barnhusgatan 3 (https://maps.google.com/maps?q=Barnhusgatan+3,+Stockholm,+Sverigehl=svie=UTF8ll=59.336079,18.059936spn=0.003332,0.010568sll=37.0625,-95.677068sspn=42.224734,86.572266oq=barnhusgatan+3hnear=Barnhusgatan+3,+111+23+Stockholm,+Stockholms+län,+Sveriget=mz=17) , 111 23 Stockholm, i...@sust.se, ** www.sust.se (http://www.sust.se) ** forward to a friend (http://us6.forward-to-friend.com/forward?u=68d21840b905fc08685f24077id=f375354881e=7fe74c97cb) | ** unsubscribe from this list (http://sust.us6.list-manage.com/unsubscribe?u=68d21840b905fc08685f24077id=c9538a38e6e=7fe74c97cbc=f375354881) | ** update subscription preferences (http://sust.us6.list-manage2.com/profile?u=68d21840b905fc08685f24077id=c9538a38e6e=7fe74c97cb)
Re: [Standards] XEP-0138: security considerations
Hi Peter, Thanks for keeping me in the loop. I have two comments. Please find them below. On 04/09/2014 01:18 AM, Peter Saint-Andre wrote: Before we released the security note about application-layer compression last week [1] (which now seems to have been overshadowed by the heartbleed bug in OpenSSL), I started to work on some updates to XEP-0138. Here is my proposed text for the Security Considerations section: ### 7. Security Considerations Stream encryption via TLS (as defined in RFC 6120) and stream compression (as defined herein) are not mutually exclusive. However, if both are used then TLS-layer encryption MUST be negotiated before negotiation of application-layer compression, so that the stream is secured first. Many of the security considerations related to TLS compression (see Section 6 of RFC 3749) also apply to stream compression. Several attacks against TLS-layer and application-layer compression have been found, including the CRIME and BEAST attacks (see draft-sheffer-uta-tls-attacks [7]). Mitigation for the CRIME attack involves disabling TLS-layer compression. At the time of this writing (early 2014), there are no general mitigations against the BEAST attack. However, the following safeguards are appropriate: Here, I would propose to keep separated data leakage from resource exhaustion issues. I mean, I would physically separate them into two distinct subsections each of them covering the following points: a) description of the security issue(s), b) security risks and/or known exploitations/attacks, c) recommendation to avoid/solve them; 1. A server implementation MUST NOT turn on compression by default; instead, it MUST enable a server administrator to turn on compression if desired. 2. A server implementation MUST enable a server administrator to limit the size of stanzas it will accept from a connected client or peer server, and also MUST set a reasonable default limit of at least 10,000 bytes. In general, it is reasonable for the maximum stanza size to be the same as the size of the buffer passed to zlib when storing uncompressed data. 3. A server implementation MUST enable a server administrator to limit the amount of bandwidth it will allow a connected client or peer server to use in a given time period. I kind of would like to adjust my earlier statement in which I suggest to turn SHOULDs into MUSTs. In my understanding, MUSTs are used to make sure that a behavior will be shared by two communicating entities... I mean for the sake of interoperability only. I may be wrong on this and know more than me, but I just avoid that. Anyway, to make a long story short: I think that the points a), b) and c) suffice here. The last two requirements are consistent with but stronger than recommendations provided in Section 13.2 of RFC 6120. Failure to provide such protections opens an implementation denial of service attacks. ### Your feedback is welcome. (I have cc'd Giancarlo Pellegrino, who reported the xmppbomb vulnerability; please reply to all so that he can be included in the conversation.) Thanks! Peter [1] http://xmpp.org/resources/security-notices/uncontrolled-resource-consumption-with-highly-compressed-xmpp-stanzas/ Cheers, Giancarlo
Re: [Standards] XEP-0138: security considerations
On Mon, Apr 14, 2014 at 3:53 PM, Peter Saint-Andre stpe...@stpeter.im wrote: On 4/14/14, 8:33 AM, Philipp Hancke wrote: [...] 1. A server implementation MUST NOT turn on compression by default; instead, it MUST enable a server administrator to turn on compression if desired. Any particular reason to use RFC 2119 language here (and in 2+3). Otherwise this LGTM. [...] 3. A server implementation MUST enable a server administrator to limit the amount of bandwidth it will allow a connected client or peer server to use in a given time period. We have that already in http://xmpp.org/extensions/xep-0205.html#rec-bandwidth so if this repeated here (which seems like a good idea) there should be a reference. In fact, some of this text is in RFC 6120: http://tools.ietf.org/html/rfc6120#section-13.12 Mostly we're strengthening that here, and if 6120bis is ever published we'll strengthen the text in the core spec. I hope we wouldn't tighten it - it's already too strong with SHOULDs on stuff that's entirely implementation detail. /K
Re: [Standards] XEP-0138: security considerations
On Mon, Apr 14, 2014 at 5:48 PM, Waqas Hussain waqa...@gmail.com wrote: 1. A server doing anything interesting (e.g., smart dynamic limits based on currently available resources) shouldn't be disallowed from using resources that are available and unused. If a server has 100GB of free RAM, no CPU usage, a client sends a 100MB gzipped payload, which expands into a 1GB stanza, and is directed to e.g., the client itself, the server should be allowed to accept it if it deems it reasonable. A better thing to do is to require mitigation of attacks, but only make suggestions on how to do it. We shouldn't require specific ways of doing it, not with a MUST. Specs shouldn't dictate implementation details. Right. The spec should draw attention to possible issues, and suggest ways an implementation might deal with them. Which methods are used isn't appropriate for the spec. We can say MUST somehow mitigate if we want to, but shouldn't mandate particular methods of mitigation. And especially shouldn't encourage behaviour we know to be harmful, like S2S throttling. /K
[Standards] XEP-0045 Issues
Hi List, I'm a new subscriber, so I don't have the thread to reply to. I recently re-wrote much of the MUC library used in prosody. While doing so, I made a list of ambiguities and issues with the MUC specification (XEP-0045) Regards, Daurnimator. 7.8.2 The room@service itself MUST then add a 'from' address to the invite/ element whose value is the bare JID, full JID, or occupant JID of the inviter and send the invitation to the invitee specified in the 'to' address What 'from' jid should we attach to a mediated invite if you're inviting while not in the room and the room is anonymous 7.8.2 If the inviter supplies a non-existent JID, the room SHOULD return an item-not-found/ error to the inviter. Does this mean we need to track invite ids? Invites do not have to be acknowledged; so this needs to be stored in 'id' or something so the server is stateless 9.5: MAY include the 'nick' and 'role' attributes for each member that is currently an occupant. What if bare_jid is in room under multiple nicks? Just send multiple items? Why are actor and reason missing in example 114? Order of stanzas sent for affiliation changes 9.7 an admin MUST NOT be allowed to revoke moderator status from a user whose affiliation is owner or admin. If an admin attempts to revoke moderator status from such a user, the service MUST deny the request and return a not-allowed/ error to the sender: I feel like admins should be able to remove (hide) their moderator-ship Can a http://jabber.org/protocol/muc#user; have multiple children? e.g. more than one invite? The schema at the end suggests yes... If so; how to signal the failure of a single sub-request 10.1 What should happen in a partial failure of room configuration? e.g. set whois to moderators, then password to blank: the first change has already been applied, but the next one is invalid It seems that room config must all be validated up-front, before making changes rather than processing in order... This suggests race conditions Is configuration Last-Write-Wins?
[Standards] a quick MUC request
Hi folks, More reviews of http://tools.ietf.org/html/draft-ietf-stox-groupchat would be helpful! Philipp Hancke reviewed it (thanks!), but it would be great if one or two more people could read this document and make sure that the mapping to and from MUC makes sense. Send email to s...@ietf.org with your feedback. :-) Thanks! Peter Original Message Subject: [Stox] Extended WGLC for draft-ietf-stox-groupchat-04 [was: WGLC for draft-ietf-stox-groupchat-04] Date: Thu, 24 Apr 2014 18:12:02 +0200 From: Yana Stamcheva y...@jitsi.org To: s...@ietf.org Hello all, Only one review has been received on this list during the WGLC (Thanks Philipp!) and in order to be able to proceed we would need more people to express their support for this document! Therefore, we hereby would like to extend the WGLC period with 2 more weeks and end it on May 5, 2014. Please, if you'd like this document to go forward, send your reviews, comments or support notes to the list before May 5, 2014! If you're willing to review the document but for some reason you won't be able to do it before the above deadline, please contact the chairs. Thanks! Yana Stamcheva Markus Isomaki On 06 Apr 2014, at 20:20, Yana Stamcheva y...@jitsi.org wrote: The editors and the chairs believe that the following draft is now ready and hereby start a 2-week Working Group Last Call for: draft-ietf-stox-groupchat-04 : http://tools.ietf.org/html/draft-ietf-stox-groupchat-04 (Last updated on 2014-03-25) The WGLC ends on April 21, 2014. Please review the document and bring any remaining issues, or issues whose resolution is not satisfactory, to the attention of the Working Group on this list before April 21. If after reviewing the document you find it complete and do not have any comments, please send a note to that effect as well! Regards, Yana Stamcheva Markus Isomaki ___ stox mailing list s...@ietf.org https://www.ietf.org/mailman/listinfo/stox
