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 <isr-enabled/> element and the mechanism attribute of the <isr-enable/> 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 <[email protected]> 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 <isr-enable(d)/> 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: [email protected] > _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
