[Standards] IOT-Events
I agree in the need for multiple subscriptions. I have that in several usecases. I would also adress the keep it simple need the xep 323 is very easy to use and the need for events for small sensors are essential to prevent extensive polling. Demanding pubsub and forms notation to the devices adds a lot of complexity to the implementor of the sensor implementor. I could almost argue that the subscription stanza should be added to the xep 323 for simplicity but a see the need for a separate namespace and perhaps other usecases *Regards* Joachim Lindborg CTO, systems architect Sustainable Innovation SUST.se Barnhusgatan 3 111 23 Stockholm Email: joachim.lindb...@sust.se javascript:_e(%7B%7D,'cvml','joachim.lindb...@sust.se'); linkedin: http://www.linkedin.com/in/joachimlindborg Tel +46 706-442270 2014-09-30 18:20 GMT+02:00 Hund, Johannes johannes.h...@siemens.com javascript:_e(%7B%7D,'cvml','johannes.h...@siemens.com');: My $0.02: My core concern here is that this spec (http://xmpp.org/extensions/inbox/iot-events.html) is designed such that one entity can publish events, to which assorted other entities can subscribe, which fundamentally sounds like pubsub, for which we have some coverage in XEP-0060. IOT-Events comes up with a completely new syntax for both the subscribing and the publishing from that described in XEP-0060, and I'd like to see if there is common ground for sharing syntax (and, ideally, semantics). I note at this point that re-use of XEP-0060 syntax would not imply the use of central pubsub services on components or servers. In IOT-Events, a Thing is its own (IOT-Events)pubsub service; I'm interested in seeing if they could be their own (XEP-0060 subset)pubsub service instead. I like this general approach! Excellent. I fully agree that the best way IMHO is generalizing XEP-0060 and keeping as close as possible to the regular semantics The way I read IOT-Events, it was a single subscription, but I'm hoping Peter or other IOT folks can weight in here much more usefully than I can. Fortunately we have the mechanisms in xep60 to cope with either. Maybe I am misundertanding it, but I think single-subscriptions would restrict some use cases. An example use case is if you have different subscriptions with different timely resolutions, maximum ages etc. This can happen when you have an entity that has several applications running which do require different event notifications. I would not restrict it to single-subscription given it does not cause an unreasonable overhead. -- *Regards* Joachim Lindborg CTO, systems architect Sustainable Innovation SUST.se Barnhusgatan 3 111 23 Stockholm Email: joachim.lindb...@sust.se linkedin: http://www.linkedin.com/in/joachimlindborg Tel +46 706-442270
Re: [Standards] draft-ietf-xmpp-websocket-10
On 10/8/14, 9:59 PM, dricha...@coversant.com wrote: -Original Message- From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of Florian Zeitz Sent: Wednesday, October 08, 2014 8:00 PM To: standards@xmpp.org Subject: Re: [Standards] draft-ietf-xmpp-websocket-10 On 08.10.2014 20:42, dricha...@coversant.com wrote: -Original Message- From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of Peter Saint-Andre - yet Sent: Wednesday, October 08, 2014 12:15 PM To: standards@xmpp.org Subject: Re: [Standards] draft-ietf-xmpp-websocket-10 On 10/8/14, 11:04 AM, dricha...@coversant.com wrote: Section 3.2 of draft-ietf-xmpp-websocket-xx specifies that data frames must be of type text and contain UTF-8 encoded data. Was there some reason for this since it makes XMPP stream compression not usable? Hi Dave, I think we'd recommend doing compression at the HTTP layer, just as for WebSocket we're doing security at the HTTP layer. Also, the spec has been approved for publication and is in the RFC Editor queue so it's too late to change it: http://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ And x...@ietf.org is the right list for IETF specs. :-) Peter -- Peter Saint-Andre https://andyet.com/ Argh. No I don't take it back - all it is is a framework for creating compression extensions. It doesn't actually define any specific mechanisms. I don't know what you found, but the latest approach for WebSocket compression within the hybi WG appears to be https://tools.ietf.org/html/draft-ietf-hybi-permessage-compression. It provides a general framework for compression, and registers one specific extension using DEFLATE. The plan for XMPP over WS was indeed always to use such an extension for compression, if required. As no finished draft exists/existed it seems sensible that no reference to this was included. I generally think this is a concern of the WebSocket implementation, and not the XMPP mapping. Regards, Florian Zeitz Thanks for that. I assumed based on Peter's comment that it was going to be a websocket extension thing so I'll take any further comments over there. I did see that doc but then I looked at http://www.iana.org/assignments/websocket/websocket.xhtml which is apparently not up to date. IANA probably won't update that until the Internet-Draft is approved. We do the same thing at the XMPP Registrar. :-) Peter -- Peter Saint-Andre https://andyet.com/
[Standards] Deprecating XEP-0138: Stream Compression
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. 2. Or that we apply framing outside of compression (which I expect to be another can of worms). zlib has a header bit that indicates whether a block is the last block in a stream, but again, that might be zlib-specific. Thoughts? Comments? Best regards, Thijs Alkemade [1] https://blog.thijsalkema.de/blog/2014/08/07/https-attacks-and-xmpp-2-crime-and-breach/ [2] https://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-18#section-8.1.1 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] draft-ietf-xmpp-websocket-10
-Ursprüngliche Nachricht- Von: Standards [mailto:standards-boun...@xmpp.org] Im Auftrag von Florian Zeitz Gesendet: Donnerstag, 9. Oktober 2014 03:00 An: standards@xmpp.org Betreff: Re: [Standards] draft-ietf-xmpp-websocket-10 On 08.10.2014 20:42, dricha...@coversant.com wrote: -Original Message- From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of Peter Saint-Andre - yet Sent: Wednesday, October 08, 2014 12:15 PM To: standards@xmpp.org Subject: Re: [Standards] draft-ietf-xmpp-websocket-10 On 10/8/14, 11:04 AM, dricha...@coversant.com wrote: Section 3.2 of draft-ietf-xmpp-websocket-xx specifies that data frames must be of type text and contain UTF-8 encoded data. Was there some reason for this since it makes XMPP stream compression not usable? Hi Dave, I think we'd recommend doing compression at the HTTP layer, just as for WebSocket we're doing security at the HTTP layer. Also, the spec has been approved for publication and is in the RFC Editor queue so it's too late to change it: http://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ And x...@ietf.org is the right list for IETF specs. :-) Peter -- Peter Saint-Andre https://andyet.com/ Argh. No I don't take it back - all it is is a framework for creating compression extensions. It doesn't actually define any specific mechanisms. I don't know what you found, but the latest approach for WebSocket compression within the hybi WG appears to be https://tools.ietf.org/html/draft-ietf-hybi-permessage-compression. It provides a general framework for compression, and registers one specific extension using DEFLATE. The plan for XMPP over WS was indeed always to use such an extension for compression, if required. As no finished draft exists/existed it seems sensible that no reference to this was included. I generally think this is a concern of the WebSocket implementation, and not the XMPP mapping. Regards, Florian Zeitz One point that I do realize now (too late) is that this means it's not possible to use EXI (XEP-0322) over websocket, right? It's basically a 1:1 binary representation of the information in an XML structure/document and therefore definitely not UTF-8. Regards, Johannes
Re: [Standards] Deprecating XEP-0138: Stream Compression
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? 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? Peter -- Peter Saint-Andre https://andyet.com/
Re: [Standards] draft-ietf-xmpp-websocket-10
On 9 October 2014 15:26, Hund, Johannes johannes.h...@siemens.com wrote: One point that I do realize now (too late) is that this means it's not possible to use EXI (XEP-0322) over websocket, right? It's basically a 1:1 binary representation of the information in an XML structure/document and therefore definitely not UTF-8. I would have thought that you'd want to negotiate an EXI session differently at the HTTP/WebSocket layer anyway, surely?
