Re: [Standards] XEP Versioning

[Philipp Hörist]

Hi,

I just wanted to throw into the discussion that breaking changes is not the
only thing to consider.
Often new features are added to XEPs which are not breaking but someone
still wants to know if a client implements it.

Example XEP: 0045
Version 1.30: Add 333 status code with OPTIONAL feature.

As a server/client developer i can imagine that a quick scan over all
clients/servers who implements > 1.30 can be useful.

This happens in my opinion more often in XEPs than breaking changes which
need a namespace bump.

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

Re: [Standards] XEP Versioning

[Melvin Keskin]

Hi Dave,

thanks for your explanation!

What is the reason for having a state such as Stable or Final and a
redundant state (major) version?

In my opinion, it would make more sense to have a separate state and
semantic versioning as specified by https://semver.org . Or, if for any
reason the state must be declared by the version, the version
scheme state.major.minor.patch as Zash said in xmpp:
x...@muc.xmpp.org?join would make more sense to me. The namespace would
then change when the major version changes. Developers as well as XEP
lists could quickly determine if there was a breaking change by
checking the major version.


___
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] XEP Versioning

[Dave Cridland]

Hi,

I like that we're documenting the versioning mechanism we use for XEPs, so
- to be clear - I don't object to this change at all.

I'm not so sure on the rationale given, though:

@horazont  The reason for specifying that
topic was that @wurstsalat3000  wanted
to create a list of XEPs a client, library or server implements and show a
hint if the implemented version is not up-to-date. But such a hint should
not be shown for different patch versions since they are only meant for
editorial changes. The problem was that it was not clear and we could not
find any document that specified it. I will sent a link to this PR to the
corresponding mailing list.


(From GitHub)

So, if the XEP changes but it's purely editorial - that is, an
implementation is very unlikely to require changes - then as this comment
says it's irrelevant to interoperability.

If a major version changes, it is also irrelevant to interoperability,
though, since advancement doesn't change the XEP's content, only its state.

And if the minor version changes, it might have an effect on
interoperability or might not depending on whether the namespace changes.
If the namespace does not change between versions but we break interop,
then we have well and truly fucked up. (And if it was in
Active/Stable/Final, then Council have to buy us all beers or chocolate, as
per XEP-0028).

So should we maybe have that list show the hint based on the namespace, and
not the version number?

I've always assumed the version number to be as Kev says in his comment -
but perhaps more usefully, it's most useful as an opaque label for a
particular version, and semantics are best ignored outside of process
wonkery.

So yes, document away, but don't list XEPs by version - list them by
namespace if we need that level.

Dave.

On Wed, 24 Aug 2022 at 13:57, Melvin Keskin  wrote:

> Hi,
>
> I created a PR for precisely specifying the versioning of XEPs:
> https://github.com/xsf/xeps/pull/1200
>
> Here is the reason:
> https://github.com/xsf/xeps/pull/1200#issuecomment-1225678948
>
> Please let me know what you think.
>
> ___
> 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
___

[Standards] XEP Versioning

[Melvin Keskin]

Hi,

I created a PR for precisely specifying the versioning of XEPs:
https://github.com/xsf/xeps/pull/1200

Here is the reason:
https://github.com/xsf/xeps/pull/1200#issuecomment-1225678948

Please let me know what you think.

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

[Standards] XMPP Council Agenda 2022-08-24

[Daniel Gultsch]

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
___