Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)

[Philipp Hörist]

Hi,

Im also looking into implementing ISR.
I think also that the HT-* method should be split out from the XEP.

ISR has value without making auth a one step action. It reduces in its
basic form without token auth the RTTs already.

If there is a auth method which reduces RTTs even more, great, recommend it
or link to it, but dont mandate it.

Further make it future proof, Who knows what new auth methods will be
invented. Provide a framework for fast resumption, but let people choose
themself how fast they need to go. (read what auth method they use).

Regards
Philipp

Am So., 28. Aug. 2022 um 16:44 Uhr schrieb Matthew Wild :

> On Wed, 24 Aug 2022 at 12:18, Matthew Wild  wrote:
> > I'm also looking at potentially implementing it in Prosody very soon,
> > as part of the modern auth project (
> > https://docs.modernxmpp.org/projects/auth/ ).
>
> Now that I've read the XEP through some more times, and have a bit of
> an implementation, I'm wondering why we are bundling instant stream
> resumption and token auth together?
>
> At least one client/deployment has indicated the desire to do the
> round-trip saving resumption using normal password authentication
> (i.e. with-isr-token='false').
>
> Also, if the client has an ISR token but cannot resume the stream
> (e.g. it has restarted and didn't persist the local stream state),
> there is no way to authenticate using the token, and there is no way
> to enable a new XEP-0198 session within .
>
> For the 2FA use-case, I need to use tokens to identify specific
> device/client installations over the long term, independent of
> XEP-0198 sessions. As things stand, I don't think XEP-0397 can
> properly fulfill this requirement. Note that just because I need to
> identify the device in the long term, doesn't mean the token must stay
> the same (I actually like that it can be rotated on each use). But I
> feel there are corner cases, such as if a disconnect occurred between
>  and the XEP-0198 ,
> where the client may end up needing to fall back to password
> authentication.
>
> This subtle complexity where ISR seems to fail at saving round-trips
> in some cases and at preserving client credentials in others, along
> with some deployments only wanting password auth, leads me to
> wondering if we shouldn't just split the two concerns into different
> specs co-existing within the framework of SASL2.
>
> Regards,
> Matthew
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)

[Matthew Wild]

On Wed, 24 Aug 2022 at 12:18, Matthew Wild  wrote:
> I'm also looking at potentially implementing it in Prosody very soon,
> as part of the modern auth project (
> https://docs.modernxmpp.org/projects/auth/ ).

Now that I've read the XEP through some more times, and have a bit of
an implementation, I'm wondering why we are bundling instant stream
resumption and token auth together?

At least one client/deployment has indicated the desire to do the
round-trip saving resumption using normal password authentication
(i.e. with-isr-token='false').

Also, if the client has an ISR token but cannot resume the stream
(e.g. it has restarted and didn't persist the local stream state),
there is no way to authenticate using the token, and there is no way
to enable a new XEP-0198 session within .

For the 2FA use-case, I need to use tokens to identify specific
device/client installations over the long term, independent of
XEP-0198 sessions. As things stand, I don't think XEP-0397 can
properly fulfill this requirement. Note that just because I need to
identify the device in the long term, doesn't mean the token must stay
the same (I actually like that it can be rotated on each use). But I
feel there are corner cases, such as if a disconnect occurred between
 and the XEP-0198 ,
where the client may end up needing to fall back to password
authentication.

This subtle complexity where ISR seems to fail at saving round-trips
in some cases and at preserving client credentials in others, along
with some deployments only wanting password auth, leads me to
wondering if we shouldn't just split the two concerns into different
specs co-existing within the framework of SASL2.

Regards,
Matthew
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)

[Thilo Molitor]

+1 for MUST


Am Samstag, 27. August 2022, 11:41:38 CEST schrieb Dave Cridland:
> On Wed, 24 Aug 2022 at 07:56, Daniel Gultsch  wrote:
> > 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.
> 
> Just on the TLS early termination, could you still support
> tls-server-end-point, which (IIRC) doesn't need anything but a static
> configuration of the server's certificate?
> 
> It's also a SHOULD, I saw, in XEP-0440 - I'd be inclined to raise that to a
> MUST, even though I prefer tls-exporter if possible, because it's very easy
> to support. Assuming, of course, that any form of channel binding is
> possible.
> 
> Dave.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)

[Dave Cridland]

On Wed, 24 Aug 2022 at 07:56, Daniel Gultsch  wrote:

> 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.
>
>
Just on the TLS early termination, could you still support
tls-server-end-point, which (IIRC) doesn't need anything but a static
configuration of the server's certificate?

It's also a SHOULD, I saw, in XEP-0440 - I'd be inclined to raise that to a
MUST, even though I prefer tls-exporter if possible, because it's very easy
to support. Assuming, of course, that any form of channel binding is
possible.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)

[Dave Cridland]

On Wed, 24 Aug 2022 at 12:19, Matthew Wild  wrote:

> On Wed, 24 Aug 2022 at 07:56, Daniel Gultsch  wrote:
> >
>
> > 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.
>
> I'm also looking at potentially implementing it in Prosody very soon,
> as part of the modern auth project (
> https://docs.modernxmpp.org/projects/auth/ ).
>
> My main motivation is support for 2FA, which is impractical without a
> way for devices to re-identify themselves (you don't want an OTP
> prompt every time your mobile reconnects to the server). ISR seems to
> be a good way to fill that gap, while providing other benefits. The
> alternative on my radar is XEP-0399 (Client Key).
>
>
I have implemented Client Key, of course. I have also sketched out an HT-*
implementation.

While I like Client Key for all sorts of reasons - for one thing, the
counter gives you a better binding to the client device - HT-* is way
easier to implement and deploy. We might want XEP-0399's device list
management at some point, for sure, but let's focus on what's easiest to
get out and deploy.

XEP-0400 works for enrolling and requiring a TOTP-based 2FA across an
entire server - there is no optional enrollment, so if we want that we'll
have to consider how. It might be the trigger needed to develop optional
Post Auth Tasks in SASL2.


> I do agree that while the goals of enforcing channel binding are
> noble, it is impractical to enforce across the network. It excludes
> web clients and a bunch of deployments that terminate TLS before the
> XMPP server. What are thoughts on a HT- variant without channel
> binding (and adding RFC 9266's tls-exporter while we're at it)?
> Combined with ISR's mechanism pinning, I think this still provides
> some advantages over just using PLAIN (which is icky, but the
> alternative).
>
>
Thilo Molinar has some thoughts around better negotiation of TLS channel
bindings as part of SASL2.

As for an HT-*-NONPLUS, I think that's reasonable.

I also think - unverified by code or a recent reading of HT-* - that my
suggestion of butchering HT-* into payloading an encrypted
username/password pair works, so that covers that side, in which case we've
a workable solution for most deployment cases.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)

[Matthew Wild]

On Wed, 24 Aug 2022 at 07:56, Daniel Gultsch  wrote:
>

> 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.

I'm also looking at potentially implementing it in Prosody very soon,
as part of the modern auth project (
https://docs.modernxmpp.org/projects/auth/ ).

My main motivation is support for 2FA, which is impractical without a
way for devices to re-identify themselves (you don't want an OTP
prompt every time your mobile reconnects to the server). ISR seems to
be a good way to fill that gap, while providing other benefits. The
alternative on my radar is XEP-0399 (Client Key).

I do agree that while the goals of enforcing channel binding are
noble, it is impractical to enforce across the network. It excludes
web clients and a bunch of deployments that terminate TLS before the
XMPP server. What are thoughts on a HT- variant without channel
binding (and adding RFC 9266's tls-exporter while we're at it)?
Combined with ISR's mechanism pinning, I think this still provides
some advantages over just using PLAIN (which is icky, but the
alternative).

Thoughts and/or guidance welcome. I'm particularly interested to hear
input from client developers. A lot of our community discussions have
an element of "it would be nice if we could...", but I'm actually
working on this project right now, it has time constraints, and
whatever I end up implementing will be in the next Prosody release. It
would be super if whatever gets rolled out is actually something
developers *want* to interact with.

Regards,
Matthew
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)

[Dave Cridland]

On Wed, 24 Aug 2022 at 07:56, Daniel Gultsch  wrote:

> 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.
>

Right. HT is great, it really is, but the fundamentals of ISR will work
with any SASL mechanism in principle.

Using PLAIN isn't ideal, but there's a number of deployments constrained
into using PLAIN - and probably plenty constrained into using a token-based
1-RTT mechanism too, which has similar outcomes.

Furthermore it would even allow me to use HT-* without ISR.
>

This too. The whole client-key stuff was aimed in a similar direction to
"HT-* without ISR". There's some entertaining work for someone in combining
all this together more coherently than I managed.


> 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".
>
>
Yeah, exactly this. As I said 4 years ago, SASL2 was built so we can
negotiate everything at once without implicit negotiation, so we might as
well use it.


> 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.
>

(Well, you might have an issue, but not one you can address).

And yes, been there, done that, do not have a t-shirt but do have a badge
lanyard.

BTW, aside: if you're able to use a pure token mechanism, you can basically
pack the PLAIN response into a Fernet token or similar and keep the
security model identical. And you *can* use HT-* still, then, because of
the details of how GS2 TLS channel binding works, the server is always
given the binding data and can just blind trust it. You don't get actual
channel binding of course, but the authentication side still works.
Although you may never stop crying silently.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)

[Daniel Gultsch]

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
> ___

Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)

[Florian Schmaus]

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
___

Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)

[Daniel Gultsch]

Hi,

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.)

What Dave outlined in his comment to §4 seems sensible enough to me?!

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.

cheers
Daniel

On Mon, Jan 22, 2018 at 1:18 PM Dave Cridland  wrote:

> Not ready for Draft, but actually surprisingly close for a newly
> adopted XEP. The main thing preventing me from implementing this in
> Openfire today is actually the overhead of implementing HT-* properly,
> which'd take me a little longer. I think this is very likely to be a
> general problem for implementors, and removing the hard dependency
> between them (even if it remains a SHOULD, which seems sensible) would
> improve deployment.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)

[Thilo Molitor]

I think I should give you a real example where ISR really matters:

Under iOS you can not run your app in the background and keep it permanently 
connected. And push doesn't always wake up your app in the background (there 
are *some* circumstances which allow this but much more exceptions).

So: If you get a message you will receive a push notification saying that there 
is a message waiting for you (not containing the content of the message for  
obvious privacy reasons).
If you tap on this notification your app will open, connect to the xmpp server, 
receive the message (either via MAM or by resuming an already existent smacks 
session) and display it.

+1s RTTs on slow mobile links are not an exception. So every time a user wants 
to read a new message he has to wait a couple of seconds till the app is ready 
to actually display what he wants to know. Even if the UI is designed well and 
shows a waiting screen with a spinner on it or something like this the user 
*still* has to wait for 5 seconds or even longer.

Everything that reduces the needed RTTs makes this situation better and I 
think XEP-0397 should be more than welcome if it solves (or at least 
attenuates) the described issue .

Only my two cent.




Am Montag, 22. Januar 2018, 17:13:00 CET schrieb Evgeny Khramtsov:
> Mon, 22 Jan 2018 13:42:59 +
> 
> Dave Cridland  wrote:
> > I don't think RTTs should block UI either, but startup RTTs mean we
> > cannot send or receive messages for several RTTs, and that's a very
> > real problem over slower networks.
> 
> What problem? If you're on slow network, expect everything to be
> slow, because, well, the network is slow.
> 
> > From a more cynical standpoint, it also addresses a commonly held
> > belief about XMPP (startup is really slow and it's really chatty!)
> > without causing harm.
> 
> I don't see this as a "commonly held belief". If you know how Web works,
> you would never assume XMPP is slow. I don't remember anyone
> complaining in my bugtracker about slow RTT.
> 
> To put it simply: I agree there can be use cases when you absolutely
> need to work in a slow network (sending stanzas to the Moon and back,
> as an example), and maybe there are indeed some problems with RTTs. But
> I see this as a very narrow use case. So I would agree that the XEP will
> be used by *some* software, and I'm fine with that. What bothers me is
> that this may become a trend, seeing the XEP as a successor to the
> "standard" approach, and even be put into "compliance suite".
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)

[Evgeny Khramtsov]

Mon, 22 Jan 2018 13:42:59 +
Dave Cridland  wrote:

> I don't think RTTs should block UI either, but startup RTTs mean we
> cannot send or receive messages for several RTTs, and that's a very
> real problem over slower networks.

What problem? If you're on slow network, expect everything to be
slow, because, well, the network is slow.

> From a more cynical standpoint, it also addresses a commonly held
> belief about XMPP (startup is really slow and it's really chatty!)
> without causing harm.

I don't see this as a "commonly held belief". If you know how Web works,
you would never assume XMPP is slow. I don't remember anyone
complaining in my bugtracker about slow RTT.

To put it simply: I agree there can be use cases when you absolutely
need to work in a slow network (sending stanzas to the Moon and back,
as an example), and maybe there are indeed some problems with RTTs. But
I see this as a very narrow use case. So I would agree that the XEP will
be used by *some* software, and I'm fine with that. What bothers me is
that this may become a trend, seeing the XEP as a successor to the
"standard" approach, and even be put into "compliance suite".
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)

[Dave Cridland]

On 22 January 2018 at 13:26, Evgeny Khramtsov  wrote:
> Mon, 22 Jan 2018 11:16:40 -
> Jonas Wielicki (XSF Editor)  wrote:
>
>> Version 0.1.0 of XEP-0397 (Instant Stream Resumption) has been
>> released.
>
> Previous discussion has faded away, so I will be ranting here again: I
> don't see excessive RTT as a problem. I'm not convinced that excessive
> RTTs block UI, I think that's a problem of bad UX design, and should be
> fixed by the application author. Also, the traffic is negligible
> during the RTTs anyway (compared to HTML pages). So the XEP is
> attempting to solve non-existing problem.

I don't think RTTs should block UI either, but startup RTTs mean we
cannot send or receive messages for several RTTs, and that's a very
real problem over slower networks. For my purposes, "mobile" isn't the
driving factor, and doesn't really qualify as a "slower network", but
it's nice to solve and will, I think, bring some benefits.

>From a more cynical standpoint, it also addresses a commonly held
belief about XMPP (startup is really slow and it's really chatty!)
without causing harm.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)

[Evgeny Khramtsov]

Mon, 22 Jan 2018 11:16:40 -
Jonas Wielicki (XSF Editor)  wrote:

> Version 0.1.0 of XEP-0397 (Instant Stream Resumption) has been
> released.

Previous discussion has faded away, so I will be ranting here again: I
don't see excessive RTT as a problem. I'm not convinced that excessive
RTTs block UI, I think that's a problem of bad UX design, and should be
fixed by the application author. Also, the traffic is negligible
during the RTTs anyway (compared to HTML pages). So the XEP is
attempting to solve non-existing problem.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)

[Dave Cridland]

On 22 January 2018 at 11:16, Jonas Wielicki  wrote:
> URL: https://xmpp.org/extensions/xep-0397.html

So now this is published, I think I can list my (current) blockers for
advancing it, as well as more general improvements that I think ought
to be made, and suggestions for unblocking.

The essential problem is that, while it now delegates the
authentication itself to the SASL layer, it also requires a single,
specific, SASL mechanism. Where the client has a client certificate,
for example, or where we can (via ATLAS, perhaps) imbue a resumed TLS
session with application-layer authentication detail, we can just use
EXTERNAL.

In more general terms, while HT-* has been developed into a quite nice
1-RTT one-shot authentication method, it's not the only 1-RTT SASL
mechanism we could use sensibly.

Equally, the implication that HT-* is only used during ISR also gets
lost this way - clients could use HT-* in other cases (like those
suggested by CLIENT-KEY).

So, with that in mind:

Section §3:

If we follow the logic above, then any SASL mechanism available could
be used with ISR, so the child  element would go. I do
appreciate there's limited utility in using ISR with, say, SCRAM, but
the functionality would not be limited and there would be no negative
security implications.

As a comment, I don't think it's possible to advertise both 
and  together, and I'm pretty sure you'd need to advertise SASL2
here.

Section §4:

Usual comment about made-up "Nonza" word here.

This is the area which we'd lose most by breaking the hard link to
HT-*, by introducing a possible further RTT. That said, we might
coalesce that RTT into the authentication exchange instead, by using
more SASL2 magic.

So what you'd do here is this:

Within the  element you add (whether doing ISR or not)
a  element. (Or , or whatever). This requests
the ht-* token - presumably it'd need a mechanism element - much like
Example 3.

In the  element, the server would provide the client with a
token and scope, like Example 4.

Note that I'm somewhat conflating HT-* support and ISR here, and it
might be as well to split them into to distinct documents.

Section §5.1

XEP-0198 already has a "location", shouldn't we be using that?

Section §5.2

I don't think the client can be the one to choose if HT-* is performed
with a password or not - my gut feeling is that HT-* with a
traditional password is an entirely distinct proposition to HT-* with
a one-shot token due to the distinction is security criteria for
password storage.

Section §5.2.1

I think the token disappears here.

I'm also concerned with the deviation of including XEP-0138 here, but
not in XEP-0198. I think overall I'd rather we looked into recasting
XEP-0138 as a SASL2 extension, which would then bring benefits
throughout. There's a risk that everyone will think that I want all
stream negotiation to be part of SASL2. They're right. This is,
roughly, the point of SASL2. There's no need to try to introduce such
things via the backdoor inside another SASL2 extension.

Section §5.2.3-4

I don't think these sections are needed, are they? They're restating
things from XEP-0388 which have been stated already in the SASL2
document. (More seriously, I worry people might think there's a
difference, when there isn't).

Section §6

I believe that the second paragraph ought to be covered by the
draft-schmaus-ht-* draft, and you probably ought to point specifically
to that draft at this point.

The first paragraph is probably generic to any 
extension, and I'd welcome text for XEP-0388 on that basis.

Summary:

Not ready for Draft, but actually surprisingly close for a newly
adopted XEP. The main thing preventing me from implementing this in
Openfire today is actually the overhead of implementing HT-* properly,
which'd take me a little longer. I think this is very likely to be a
general problem for implementors, and removing the hard dependency
between them (even if it remains a SHOULD, which seems sensible) would
improve deployment.

If my comments above are all addressed - and I think they still leave
the same essential properties of a secure 1-RTT resumption - I'd be
happy to see this advance.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] NEW: XEP-0397 (Instant Stream Resumption)

[XSF Editor]

Version 0.1.0 of XEP-0397 (Instant Stream Resumption) has been
released.

Abstract:
This specification introduces a mechanism for instant stream
resumption, based on Stream Management (XEP-0198), allowing XMPP
entities to instantaneously resume an XMPP stream.

Changelog:
Accepted by council vote from 2017-12-13. (XEP Editor (jwi))

URL: https://xmpp.org/extensions/xep-0397.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
___