jdev - 2020-03-31

Was anyone here around during the JSF days? I'm trying to get a sense of how its mission was different from the XSFs since my understanding is that it was more software focused

Sam Whited: Very few people who're still active. Alex, Edwin, Ralph. Me just about. Not sure about Dave, but I suspect not.

Peter, obviously.

I've probably forgotten someone, but it's that sort of number of people, I think.

Kev: thanks, I'll reach out to them directly

Sam Whited: are you going to make a history write-up? That'd be very interesting

Ge0rG: I wasn't planning on it, but that would be fun if I learn anything interesting

As somebody who is very interested in having a JSF 2.0 of sorts today, I'm probably too biased to do such a thing.

Ge0rG: I've been vaguely thinking about that which is why I asked. I'd like to have something like Apache but for XMPP projects. Something that can act as a fiscal sponsor to help projects raise money, provide a common set of guidelines and dev practices and infrastructure for stuff under its umbrella, etc. but before I ask people what they'd want out of it I figured I'd see what existed before. I'm also not convinced that there is enough interest in XMPP in general to even make it possible, but you never know. Anyways, just doing very preliminary research.

Sam Whited, you should attend board meetings more often

also maybe become a member again so that you see what’s going on on members@

jonas’: I still don't see the point of being a member of the XSF.

so that you get a say on that matter

Sam Whited: nobody is _against_ creating such an organization, but the XSF isn't it, and looks like so far nobody had the resources to actually start it.

Ge0rG: right, that's why I was thinking about doing it separate from the XSF.

you’re most definitely not the first one with that thought

I think that the XSF (and XMPP overall) would vastly benefit from having it, though.

yah, probably not

jonas’: a say in what matter?

Sam Whited, the direction of the XSF and how funds are used.

jonas’: I don't think this should be the XSF, they should be two separate organizations.

MattJ, cc @ you, I think you brought something like that up in one of the more recent board meetings, too ^

Sam Whited, yes, and I think such an organisation should have its roots in the XMPP and XSF communities

jonas’: I agree, but like I said, this is just me doing some preliminary research.

!

I’m saying there’s already efforts in that direction and I suggest you join them. the more the better.

I bring it up all the time

I'm also interested fwiw

to anyone who will listen, or who thinks the XSF is capable of doing all the things people want it to do :)

"jonas’> Sam Whited, yes, and I think such an organisation should have its roots in the XMPP and XSF communities", I agree

Well it's unlikely to have its roots in the Matrix community, I agree :)

No but it could be perceived as a "FU the XSF, it doesn't work, we're doing our own thing"

I almost think, so what if it is? (which is unlikely if you're up-front about the goals) ✏

Modern XMPP also has/had that risk

Even the name and domain :)

I'm pretty sure it won't, because the XSF is very clear about its razor-sharp focus on Protocol.

(XSF should register legacyxmpp.org on 1st April)

MattJ: you could do it right now.

Oh look, that's tomorrow

Must finish my MAM update in time

I kind of forgot about modern XMPP, I'm glad to see this exists. I like the goal of providing docs and UI/UX guidelines and what not.

MattJ: because you want it to appear on the Humorous track?

With DNS-over-XMPP on the Standards Track and MAM on the Humorous track we'll be good

Hmm, I wonder how many libraries/clients would get tripped up by an iq type='get' in one namespace, and the result having a payload with a different namespace

... why would they

Because people make assumptions

why do they? ✏

:)

seems like the easiest thing to do would be to match based on ID then just decode whatever is in the result, and I would assume most people would do the easiest thing and it wouldn't cause problems

MattJ: you'd be surprised how many implementations ignore the xmlns altogether

well it does

if you only match on the id, then you are potentially open to spoofed replies

You match on (jid, id) though

and type

(jid, id, type=(result|error))

Monal won't work on my account because I have a Cisco user on my roster who has a Cisco-namespaced <presence> element inside the jabber:client <presence> element

or have a sufficiently unpredictable ID :)

I'm just patching our minidom implementation in Rust to force namespaces everywhere. It's just not possible to retrieve an element without specifying a namespace, unless you loop over everything all the time

and even (jid, id) is not that trivial as it seems, since there could be multiple values for jid

including, in some cases, nil

don’t get me started on the ambiguity of an absent @to/@from on stanzas

so you may simply want to generate "good" IDs and be done…

Why would there be multiple values for JID? Do you just mean the server being the domain or the empty attribute?

Sam Whited, that’s not what empty attribute means

jonas’, when is it ambigous?

absent attribute refers to your *account*, not to the server domain.

oh right, that one. Is that what you menat?

yes

Zash, you can’t simply match on the verbatim string, you have to take into account your currently bound-to JID after resource binding, since some servers will always do one thing (present or absent attribute) even if you always send present/absent

yah, that's irritating. I just have my library normalize that on all incoming stanzas

so you have to, in your processing loop, alias empty jid to locally bound bare JID, which is annoying to do

I recall having issues with normalising that actually

jonas’: nothing wrong with empty @from/@to... Until you send a message to yourself and the Carbon copy you receive doesn't have one of those set, but it means a different thing ;)

Just don't find the text that suggests that empty to/from is different from the bare account jid.

jonas’, do you remember which issues you had exactly?

(also, of course it requires the stanza broker to know your local JID, because we all hate self-contained things)

I’ll have to check the git log

What is a "stanza broker"?

Sam Whited, the thing which takes the stanzas from the XML stream and hands it to handlers

I think it’s called mux in mellium

Oh, that's not what does the noramlization in my case (I don't think, if it does it shouldn't be, I can't remember)

The session (or connection) knows your JID, and whenever any tokens are read from it it can normalize them

my point is that there’s *no* layer which should need to know about your locally bound JID in the stanza processing pipeline

Sam Whited: are you also normalizing <forwarded> stanzas? :D

Ge0rG: I don't remember how that works, but those are wrapped in an actual stanza, no? I should probably look, if not I'm probably breaking something there

flow, possibly the normalisation issues were purely in aioxmpp

Sam Whited: yes they are, but they are also <message/> stanzas and there are no guarantees whatsoever on them having @from/@to set correctly

Ge0rG: I don't do any automatic handling at all of those right now, my library is a bit low-level for that. If a package was ever written to handle them, it would have to do its own normalization to remain self contained.

I like to think of it as stanzas inheriting the logical to/from of the parent stream.

After resource binding one could think of those as from=full jid to=bare jid

Zash: that's the logical thing indeed, except that for some people it's not obvious that you have a stream to your account.

Zash, however, as a client, you set stream:stream/@to to the domain, not to the bare account JID ✏

jonas’: Imagine that it changes during resource binding

that does make no sense to me

I kinda wish resource binding was a stream restart thing

changing on SASL, that’d make sense, because that actually binds you to a bare JID of some kind ✏

Drop the resource binding iq hack, server tells you to/from in the post-sasl restart

that’d be kind of sexy, except that the client speaks first on stream resets

Myeah

+ SASL2 gets rid of the stream restart

Tho you could just drop the to/from that the client sends. The server knows who you are after auth and it knows who you authed to.

And by drop I mean the server ignores it.

I'm always torn about the restarts. On the one hand, they're logical and they're probably good from a security perspective. On the other hand, the entire connection process takes forever on a crappy network and anything we can do to speed that up makes me happy.

I did something like that in an experimental CBOR protocol once. No stream restarts, just a message that updates top-level properties like to/from

I don’t even know what stream restarts are supposed to do. the @to is only interesting for client->server really pre-STARTTLS as an SNI-surrogate

aren’t they?

jonas’, rumor is that they are supposed to reset the xml parser state ✏

and thus throw away auth related state that might linger

which is why it's weird to me that SASL2 drops the restart

flow, ah, that makes sense

I’ll probably forget that again, but it *does* make sense

Pretty sure there have been protocol security problems in the past that didn't apply to XMPP because we do restarts

Also older SASL mechanisms can negotiate encryption and stuff, which requires a clear point where it's activated.

I think it's not that bad to have them

not sure about the motivation to drop them in sasl2 though

You need a stream restart after integrity is negotiated.

Both starttls and SASL can negotiate integrity, I think.

Kev, see, that argument I don’t get

Never seen it used in SASL tho, only seen the traces of it in DIGEST-MD5

I can see the argument that you want to throw away an XMPP parser/serialiser after having done auth with it, or that you don’t want to keep an XML pipeline hooked up to a stream potentially in the middle of a TLS handshake. But I don’t get that integrity argument

I'm always confused when I walk up to my laptop and there's a ton of new messages I hadn't seen.

jonas’: Because if you assume pre-integrity that things might have been injected into the stream, people could have mangled your to/from and stream id, as well as injecting things into your XML parser.

right, so to/from/stream id are 100% irrelevant, aren’t they?

So you're potentially doing authorisation based on injected data.

I don't believe they are, no.

you authenticate the server with TLS/SASL, likewise for the client.

I never saw the stream ID used for anything

It's used in dialback

that’s more interesting

(maybe my view is too client-centric?)

I think it might be :)

but clients are most hurt by stream restarts either way

Didn't the non-SASL auth also use the stream id?

> SHA1-encrypted Hmmm

> SHA1(concat(sid, password))

Obsoleted nearly 12 years ago? Why do we still ship code for this?

Altho I fondly remember typing https://xmpp.org/extensions/xep-0078.html#example-3 into a telnet console once upon a time

I think it should be brought back, just the PLAIN though, and only over TLS of course

if it's good enough for HTTP why not XMPP

eugh

SASL made sense before TLS was mandatory, I don't really think it brings any advantages nowadays though

This notion makes me sad

unless you see "complexity" or "not being able to upgrade ever" as an advantage

are there actual advantages to SASL ?

you mean SASL SCRAM?

There's an advantage to having a choice of mechanisms, if that's the question. And once you've got a choice of mechanisms, why not use SASL.

yeah there is more than sasl scram

you need a protocol to tell the server how you are going to auth

may it be via 2FA or external via client cert or even PLAIN

"good enough for http", but the web uses a lot of OAuth and stuff that only works if you're a browser

client cert can be handled at the TLS layer, 2FA can just be a token appended to your password which makes it the same as PLAIN

fair re: oauth ugh

Also, I sure hope you're not making the argument that popular == good

no, I'm arguing that PLAIN user+pass is "good enough" and KISS and sasl-scram and friends is needless complexity for no gain

i agree about sasl scram over tls is probably not very useful

but not about getting rid of extendable protocol that can define any kind of auth mechanism

it's useful because you don't need to store the password on the client

or on the server

or send it over the wire

even if TLS helps there

More useful than not having an upgrade path if SHA-1 gets broken?

and it's cheap to verify for the server, even if you did a billion rounds of PBKDF2

Does this exact discussion with these exact words get repeated every couple of months?

Unrelated: but is Apache Vysper still being developed? Randomly wound up on its Git page and there are a bunch of recent commits by names I don't recognize. That is suprising

https://github.com/xsf/xmpp.org/pull/592#issuecomment-514935602

yah, they're not wrong, it's not easy to find. Good to know.

Looks like they did a bunch of stuff last year

Hmm, is it a XMPP server?

Yes

I thought it had something different to it (a reason to make it active again that other XMPP servers do not have or something)

moparisthebest, fyi you cant do the full client cert spec without sasl

a cert could be valid for more than one account

so you need a way to tell the server the account you want to auth with

don't know though if anyone does that

Ge0rG, and how is not storing the password on the client useful?

your xmpp account password should already only be used for xmpp, so if someone has access to your account, it doesn't really matter if they have the password or not

moparisthebest, that’s a pretty strong "should" there

first: user reality begs to differ. second: single-sign-on systems *do* exist.

should be a MUST , we need to stop catering to idiots

if someone uses "password" or "mustang1" across all their accounts, it doesn't really matter that the xmpp client doesn't store it locally

if someone uses "7GvdunCpiwkUKty9dj3/u8l5" for their company single-sign-on which also has an XMPP service, it does matter though ✏

Uh in those cases you can't use SCRAM anyways since you need to send that password in plain text to some validation service.

shush

... unless it's some OAuth-derivative thing

jonas’, does it? cause their browser stores it in plaintext in that case, also probably outlook

moparisthebest, "others are bad, let’s also be bad"

burning coal works just fine, let's do more of that!

jonas’, yep, if it provides no benefit in any case and brings complexity, let's not bother

so far we've established it's useless if it's unique to the xmpp account, or in the case of single sign on, where is it useful then?

I don’t agree with your assessment of the SSO situation

I don't agree that there's no benefit.