Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)
Hi Flow, I now realize that I get hung up on PLAIN at little bit in my previous e-mail. But what I was really saying is that ISR should allow any SASL mechanism with HT-* being just one possible (although good) choice. And to be clear when I say PLAIN I mean username+password and not putting the token in there. I just took PLAIN as an example because it uses the same number of round trips as HT-*. But in theory you should be able to do SCRAM-SHA1 too. However before we get hung up on security properties of PLAIN we can also use EXTERNAL (client certificates) as an additional example. If we use EXTERNAL (or PLAIN) we don’t need to request the HT-* token. Hence the token attribute of the element and the mechanism attribute of the element are not needed. (They are currently a MUST) And that's the advantage of requesting the HT tokens with SASL2. It decouples it from ISR and I can choose to do ISR with or without HT-*. Furthermore it would even allow me to use HT-* without ISR. That's not at all an attack on HT-* but there are several scenarios where I can’t use HT-* (I have deployments where we terminate TLS before it hits the XMPP server. There are also scenarios where we don’t use TLS at all. I also have customers that use client certs where doing the ISR auth with EXTERNAL is just more convenient. WRT: Compressions. Dave in his email refers to it as XEP-0138 which is why a Ctrl-F didn’t yield any results. To add to Daves points. Making compression a SASL2 extension also fixes the somewhat weird issue where the session can not be resumed and the server thus doesn’t know if compression was enabled previously or not. It just makes compression explicit rather than handwavey "if it was enabled previously". And yes we are currently implementing it. That's why I’m providing feedback on the XEP. And yes we are using it with compression and yes we do terminate TLS early and can’t use HT-* and yes we use PLAIN for regular logins too and therefor we don’t have an issue with the "downgrade" in security. cheers Daniel On Tue, Aug 23, 2022 at 7:32 PM Florian Schmaus wrote: > > On 22/08/2022 16.07, Daniel Gultsch wrote> I have some new found > interest in Instant Stream Resumption and after > > reading the XEP again I find myself agreeing with a lot of what Dave > > said 4.5 years ago especially with regard to decoupling the HT-* > > family of authentication from ISR itself. One might argue that more > > XEPs means more complexity but to the contrary I think it would > > actually reduce complexity because one could - theoretically - > > implement ISR with PLAIN and then not having to worry about HT-* and > > channel binding. (Don’t get me wrong I like channel binding and I like > > HT-* but if one is in the market for some quick and easy stream > > resumption being able to do it with PLAIN would help a lot.) > > The XEP is written with that in mind (as far as I remember). It has a > strong bias towards SASL HT-* as this mechanisms protects the token, > whereas using PLAIN does not. Furthermore, it is not immediately clear > what Instant Stream Resumption (ISR) and SASL PLAIN exactly is, as there > are (at least) two approaches imaginable (that also do not rule each > other out): First, perform ISR + SASL PLAIN with the users password. > Which would be a big step backwards in terms of security. Second, > perform ISR + SASL PLAIN with the token obtained by ISR. Obviously > better than the first variant, while not as secure as HT-*. > > I think all variants, including the HT-* one have different advantages > and disadvantages, and we ultimately need more implementation > experience. So, by all means, please go ahead. > > > > What Dave outlined in his comment to §4 seems sensible enough to me?! > > I am not sure what the advantage of obtaining the ISR token > simultaneously with the SASL authentication. You need to do the > request/response pair to enable Stream Management anyway afterwards > (unless you would use bind2, I assume, in which case it wouldn't matter > what the parent of the the XML element is). > > What am I missing? > > > > Minor stuff: I’m also agreeing with the feedback on location and > > compression. However the above (allowing multiple SASL mechanisms) is > > the urgent one for me right now. > > I can't find anything regarding 'compression' in Dave's Mail from > 2018-01-22. Furthermore, I am not sure how the 'location' attribute from > Stream Management can be re-used or how that would improve things. > Again, being slightly jet lagged, I am maybe missing something. Examples > would probably help. > > In summary, please go ahead and implement ISR in any way you feel > sensible and report back your findings. :) > > - Flow > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ __
[Standards] XMPP Council Agenda 2022-08-24
Good morning Council members, the next XMPP Council Meeting will take place on Wednesday, August 24th 2022 at 15:00 UTC in xmpp:coun...@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update - UPDATED: XEP-0447 (Stateless file sharing) - STABLE: XEP-0215 (External Service Discovery) - NEW: XEP-0469 (Bookmark Pinning) - NEW: XEP-0470 (Pubsub Attachments) 4) Items for voting a) XEP-0231: clarify where to find hash algo names (https://github.com/xsf/xeps/pull/1193) b) XEP-0004: clarify rules for multi-item forms (https://github.com/xsf/xeps/pull/1194) 5) Pending votes none See Spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1aA6tQJ8XJ_UjCKrcJ6CyG-l3L5xETSlBrPRR-37Z_1E/edit?usp=sharing 6) Date of Next 7) AOB 8) Close ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] NEW: XEP-0470 (Pubsub Attachments)
Version 0.1.0 of XEP-0470 (Pubsub Attachments) has been released. Abstract: This specification provides a way to attach elements to a pubsub item. Changelog: Accepted by vote of Council on 2022-07-27. (XEP Editor (jsc)) URL: https://xmpp.org/extensions/xep-0470.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] NEW: XEP-0469 (Bookmark Pinning)
Version 0.1.0 of XEP-0469 (Bookmark Pinning) has been released. Abstract: This document defines an XMPP protocol extension to allow users to pin PEP Native Bookmarks. Changelog: Accepted by vote of Council on 2022-07-27. (XEP Editor (jsc)) URL: https://xmpp.org/extensions/xep-0469.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] STABLE: XEP-0215 (External Service Discovery)
Version 1.0.0 of XEP-0215 (External Service Discovery) has been released. Abstract: This document specifies an XMPP protocol extension for discovering services external to the XMPP network. Changelog: Accept as Stable as per Council Vote from 2022-08-03. (XEP Editor (jsc)) URL: https://xmpp.org/extensions/xep-0215.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] UPDATED: XEP-0447 (Stateless file sharing)
Version 0.2.0 of XEP-0447 (Stateless file sharing) has been released. Abstract: This specification describes a protocol for stateless asynchronous file sharing with integrity and transport flexibility. It allows clients to provide a good interoperable user experience in combination with Carbons and MAM. Changelog: Add disposition attribute to signal when inlining is desired. (lmw) URL: https://xmpp.org/extensions/xep-0447.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)
On 22/08/2022 16.07, Daniel Gultsch wrote> I have some new found interest in Instant Stream Resumption and after reading the XEP again I find myself agreeing with a lot of what Dave said 4.5 years ago especially with regard to decoupling the HT-* family of authentication from ISR itself. One might argue that more XEPs means more complexity but to the contrary I think it would actually reduce complexity because one could - theoretically - implement ISR with PLAIN and then not having to worry about HT-* and channel binding. (Don’t get me wrong I like channel binding and I like HT-* but if one is in the market for some quick and easy stream resumption being able to do it with PLAIN would help a lot.) The XEP is written with that in mind (as far as I remember). It has a strong bias towards SASL HT-* as this mechanisms protects the token, whereas using PLAIN does not. Furthermore, it is not immediately clear what Instant Stream Resumption (ISR) and SASL PLAIN exactly is, as there are (at least) two approaches imaginable (that also do not rule each other out): First, perform ISR + SASL PLAIN with the users password. Which would be a big step backwards in terms of security. Second, perform ISR + SASL PLAIN with the token obtained by ISR. Obviously better than the first variant, while not as secure as HT-*. I think all variants, including the HT-* one have different advantages and disadvantages, and we ultimately need more implementation experience. So, by all means, please go ahead. What Dave outlined in his comment to §4 seems sensible enough to me?! I am not sure what the advantage of obtaining the ISR token simultaneously with the SASL authentication. You need to do the request/response pair to enable Stream Management anyway afterwards (unless you would use bind2, I assume, in which case it wouldn't matter what the parent of the the XML element is). What am I missing? Minor stuff: I’m also agreeing with the feedback on location and compression. However the above (allowing multiple SASL mechanisms) is the urgent one for me right now. I can't find anything regarding 'compression' in Dave's Mail from 2018-01-22. Furthermore, I am not sure how the 'location' attribute from Stream Management can be re-used or how that would improve things. Again, being slightly jet lagged, I am maybe missing something. Examples would probably help. In summary, please go ahead and implement ISR in any way you feel sensible and report back your findings. :) - Flow OpenPGP_signature Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
