Re: [Standards] Feedback to Compliance Suites 2020
On Thu, Oct 10, 2019 at 11:20 AM, JC Brand wrote: Now you're saying "limitation", previously you said "restriction". I use those words interchangeably in this context. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Feedback to Compliance Suites 2020
On Thu, Oct 10, 2019 at 10:59 AM, JC Brand wrote: Well, to come back to Georg's point of not deprecating BOSH until we have a solution, it seems that XEP-0397 would need to be included in the compliance suite, at least for this particular use-case (maintaining anonymous logins over websocket). Well, as I already said, the issue with anonymous logins and XEP-0198 resumption already exists for "normal" TCP/TLS c2s connections. It's unrelated to websockets. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Feedback to Compliance Suites 2020
On Thu, Oct 10, 2019 at 11:01:56AM +0300, Evgeny wrote: > On Thu, Oct 10, 2019 at 10:52 AM, JC Brand wrote: > > You're arguing against a point nobody made. > > > > Nobody advocated using BOSH to bypass restrictions in XEP-0198. > > The issue Georg mentioned isn't due to anything in XEP-0198. > > > > The issue is with the SASL anonymous login mechanism not allowing you to > > reconnect with the same JID, which happens **before** trying to resume a > > XEP-0198 session. > > The issue is *exactly* due to limitation in XEP-0198 that you're trying to > bypass with BOSH: since XEP-0198 doesn't allow you to resume a session > without re-authentication (and with SASL ANONYMOUS you cannot > re-authenticate with the same JID), you resort to use BOSH to bypass this > restriction, since it's *implicitly* using session identifiers as > authentication tokens. Now you're saying "limitation", previously you said "restriction". I agree that XEP-0198 is limited in the sense that it doesn't concern itself with authentication and that this problem occurs at the authentication level. Seems like XEP-0397 solves it though. signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Feedback to Compliance Suites 2020
On Thu, Oct 10, 2019 at 10:52 AM, JC Brand wrote: You're arguing against a point nobody made. Nobody advocated using BOSH to bypass restrictions in XEP-0198. The issue Georg mentioned isn't due to anything in XEP-0198. The issue is with the SASL anonymous login mechanism not allowing you to reconnect with the same JID, which happens **before** trying to resume a XEP-0198 session. The issue is *exactly* due to limitation in XEP-0198 that you're trying to bypass with BOSH: since XEP-0198 doesn't allow you to resume a session without re-authentication (and with SASL ANONYMOUS you cannot re-authenticate with the same JID), you resort to use BOSH to bypass this restriction, since it's *implicitly* using session identifiers as authentication tokens. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Feedback to Compliance Suites 2020
On Wed, Oct 09, 2019 at 09:13:59PM +0200, Jonas Schäfer wrote: > On Mittwoch, 9. Oktober 2019 21:01:18 CEST JC Brand wrote: > > On Wed, Oct 09, 2019 at 05:24:49PM +0200, Georg Lukas wrote: > > > * Evgeny [2019-10-09 17:08]: > > > > I would like to see BOSH dropped and moving the XEP to historical or > > > > deprecated state, because I see zero advantages over Websockets now > > > > (supporting both XEP-0198 and BOSH makes no sense at all). > > > > > > there is still an open issue with WebSockets for anonymous sessions: you > > > can't 0198 resume anon sessions because you can't re-login with the same > > > credentials, and thus BOSH will survive a page reload, whereas WS won't. > > > Until this problem is solved, I'd rather not kill BOSH. > > > > Yes, I was affected by this issue recently. > > > > I don't see how this will get resolved without allowing the client to > > specify the full JID it wants to re-use so that it can then use XEP-0198 to > > resume its previous session. > > > > At least one server developer was against the idea, IIRC saying that it goes > > breaks the semantics of anonymous connections. > > Which is true. > > I think that for those cases, [XEP-0397] would come in handy. It can serve > here not only as a speedup of resumption, but also as a way to make > resumption > possible. Ok, so it seems the reasoning here is that XEP-0397 is the solution because when you're using it you're not trying to log in anonymously with a pre-specified JID (which is not allowed) in order to resume a XEP-0198 session, instead you resume the session by means of a token (which implies a particular JID). The difference is very subtle, but makes sense to me. Well, to come back to Georg's point of not deprecating BOSH until we have a solution, it seems that XEP-0397 would need to be included in the compliance suite, at least for this particular use-case (maintaining anonymous logins over websocket). signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Feedback to Compliance Suites 2020
On Wed, Oct 09, 2019 at 10:24:54PM +0300, Evgeny wrote: > On Wed, Oct 9, 2019 at 10:20 PM, Evgeny wrote: > > I still doubt this is anyhow more secure than session resumption in > > XEP-0198 (which btw requires real re-authentication). > > Let me explain: using BOSH to bypass restriction of XEP-0198 (namely, SASL > re-authentication) doesn't justify usage of BOSH, in my opinion. Such > explanation looks really weird, to say the least. You're arguing against a point nobody made. Nobody advocated using BOSH to bypass restrictions in XEP-0198. The issue Georg mentioned isn't due to anything in XEP-0198. The issue is with the SASL anonymous login mechanism not allowing you to reconnect with the same JID, which happens **before** trying to resume a XEP-0198 session. At least this is the case with Prosody, I haven't tested on other servers. With websocket the connection and session immediately drop when you reload the page and if you used anonymous login, you will then need a way to reconnect and then re-establish your previous session. You can't however because SASL anon doesn't allow you to reuse your same JID. With BOSH you don't have this problem because the XMPP server keeps the session alive between requests, so you're not re-establishing an old session, you're just sending a new request to the original session. Therefore with BOSH you can reload the page and still maintain your anonymous session while with websocket you can't. Non-web clients don't have this problem because their connections are long-lived. With websocket-using web-clients your connection can be terminated at any time when the user reloads the tab. signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Feedback to Compliance Suites 2020
On Mittwoch, 9. Oktober 2019 20:48:15 CEST JC Brand wrote: > On Wed, Oct 09, 2019 at 04:56:54PM +0200, Jonas Schäfer wrote: > > - Should we really require both BOSH and WebSockets for the Web Suite for > > clients? Maybe it makes more sense to require it both for Servers, but > > only > > one of them for clients, possibly even phasing out BOSH. (Disclaimer: I’m > > not a Web person). > > Looking at footnote 14, it appears as if only one of the two is required for > compatibility, not both. This is true, I overlooked that. > That said, I agree that supporting only one web connection mechanism is > enough. For a web client application? Why not? > If only BOSH is supported, then XEP-0198 isn't needed since it's not > compatible with BOSH which in any case has its own session management > protocol. This needs to be made explicit. This is a good point. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Feedback to Compliance Suites 2020
On Wed, Oct 9, 2019 at 6:07 PM, Evgeny wrote: supporting both XEP-0198 and BOSH makes no sense at all I would also add that implementing both XEP-0198 and BOSH in the server is not a trivial task at all. I would say both are very complex to implement correctly and have tons of caveats. So by recommending/requiring both in the compliance suite the Council needs clearly understand what burden this puts on server developers. Just my few cents. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Feedback to Compliance Suites 2020
On Wed, Oct 9, 2019 at 10:20 PM, Evgeny wrote: I still doubt this is anyhow more secure than session resumption in XEP-0198 (which btw requires real re-authentication). Let me explain: using BOSH to bypass restriction of XEP-0198 (namely, SASL re-authentication) doesn't justify usage of BOSH, in my opinion. Such explanation looks really weird, to say the least. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Feedback to Compliance Suites 2020
On Wed, Oct 9, 2019 at 10:11 PM, JC Brand wrote: "Restoring" a session means simply making a new request within the timeout period. Whether the browser tab has been reloaded in the meantime is irrelevant. I still doubt this is anyhow more secure than session resumption in XEP-0198 (which btw requires real re-authentication). ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Feedback to Compliance Suites 2020
On Mittwoch, 9. Oktober 2019 21:01:18 CEST JC Brand wrote: > On Wed, Oct 09, 2019 at 05:24:49PM +0200, Georg Lukas wrote: > > * Evgeny [2019-10-09 17:08]: > > > I would like to see BOSH dropped and moving the XEP to historical or > > > deprecated state, because I see zero advantages over Websockets now > > > (supporting both XEP-0198 and BOSH makes no sense at all). > > > > there is still an open issue with WebSockets for anonymous sessions: you > > can't 0198 resume anon sessions because you can't re-login with the same > > credentials, and thus BOSH will survive a page reload, whereas WS won't. > > Until this problem is solved, I'd rather not kill BOSH. > > Yes, I was affected by this issue recently. > > I don't see how this will get resolved without allowing the client to > specify the full JID it wants to re-use so that it can then use XEP-0198 to > resume its previous session. > > At least one server developer was against the idea, IIRC saying that it goes > breaks the semantics of anonymous connections. Which is true. I think that for those cases, [XEP-0397] would come in handy. It can serve here not only as a speedup of resumption, but also as a way to make resumption possible. kind regards, Jonas [XEP-0397]: https://xmpp.org/extensions/xep-0397.html signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Feedback to Compliance Suites 2020
On Wed, Oct 09, 2019 at 06:32:12PM +0300, Evgeny wrote: > On Wed, Oct 9, 2019 at 6:27 PM, Evgeny wrote: > > According to such logic this "problem" should be resolved for plain TCP > > c2s as well. Unless it's not solved we should not kill BOSH. > > Ah, and another question is raising: why actually BOSH allows you to restore > the session without re-authentication, when XEP-0198 doesn't? Is BOSH a more > secure transport? HTTP is short-lived and stateless, so the XMPP server needs to keep the session alive between requests and also for a certain period of time (usually ~60s) after it has received the last request. Because HTTP is stateless, individual requests need to be "authenticated" as well. This is done with a session token and a continuously incrementing request token, both of which need to be included per request. "Restoring" a session means simply making a new request within the timeout period. Whether the browser tab has been reloaded in the meantime is irrelevant. signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Feedback to Compliance Suites 2020
On Wed, Oct 09, 2019 at 05:24:49PM +0200, Georg Lukas wrote: > * Evgeny [2019-10-09 17:08]: > > I would like to see BOSH dropped and moving the XEP to historical or > > deprecated state, because I see zero advantages over Websockets now > > (supporting both XEP-0198 and BOSH makes no sense at all). > > there is still an open issue with WebSockets for anonymous sessions: you > can't 0198 resume anon sessions because you can't re-login with the same > credentials, and thus BOSH will survive a page reload, whereas WS won't. > Until this problem is solved, I'd rather not kill BOSH. Yes, I was affected by this issue recently. I don't see how this will get resolved without allowing the client to specify the full JID it wants to re-use so that it can then use XEP-0198 to resume its previous session. At least one server developer was against the idea, IIRC saying that it goes breaks the semantics of anonymous connections. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Feedback to Compliance Suites 2020
On Wed, Oct 09, 2019 at 04:56:54PM +0200, Jonas Schäfer wrote: > - Should we really require both BOSH and WebSockets for the Web Suite for > clients? Maybe it makes more sense to require it both for Servers, but only > one of them for clients, possibly even phasing out BOSH. (Disclaimer: I’m not > a Web person). Looking at footnote 14, it appears as if only one of the two is required for compatibility, not both. That said, I agree that supporting only one web connection mechanism is enough. If only BOSH is supported, then XEP-0198 isn't needed since it's not compatible with BOSH which in any case has its own session management protocol. This needs to be made explicit. Regards JC ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Feedback to Compliance Suites 2020
On Wed, Oct 9, 2019 at 6:27 PM, Evgeny wrote: According to such logic this "problem" should be resolved for plain TCP c2s as well. Unless it's not solved we should not kill BOSH. Ah, and another question is raising: why actually BOSH allows you to restore the session without re-authentication, when XEP-0198 doesn't? Is BOSH a more secure transport? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Feedback to Compliance Suites 2020
On Wed, Oct 9, 2019 at 6:24 PM, Georg Lukas wrote: Until this problem is solved, I'd rather not kill BOSH. According to such logic this "problem" should be resolved for plain TCP c2s as well. Unless it's not solved we should not kill BOSH. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Feedback to Compliance Suites 2020
* Evgeny [2019-10-09 17:08]: > I would like to see BOSH dropped and moving the XEP to historical or > deprecated state, because I see zero advantages over Websockets now > (supporting both XEP-0198 and BOSH makes no sense at all). there is still an open issue with WebSockets for anonymous sessions: you can't 0198 resume anon sessions because you can't re-login with the same credentials, and thus BOSH will survive a page reload, whereas WS won't. Until this problem is solved, I'd rather not kill BOSH. Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e h- r++ y? || ++ IRCnet OFTC OPN ||_|| signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Feedback to Compliance Suites 2020
On Wed, Oct 9, 2019 at 5:56 PM, Jonas Schäfer wrote: - Should we really require both BOSH and WebSockets for the Web Suite for clients? Maybe it makes more sense to require it both for Servers, but only one of them for clients, possibly even phasing out BOSH. (Disclaimer: I’m not a Web person). I would like to see BOSH dropped and moving the XEP to historical or deprecated state, because I see zero advantages over Websockets now (supporting both XEP-0198 and BOSH makes no sense at all). ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
