-
Sam Whited
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
-
Kev
Sam Whited: Very few people who're still active. Alex, Edwin, Ralph. Me just about. Not sure about Dave, but I suspect not.
-
Kev
Peter, obviously.
-
Kev
I've probably forgotten someone, but it's that sort of number of people, I think.
-
Sam Whited
Kev: thanks, I'll reach out to them directly
-
Ge0rG
Sam Whited: are you going to make a history write-up? That'd be very interesting
-
Sam Whited
Ge0rG: I wasn't planning on it, but that would be fun if I learn anything interesting
-
Ge0rG
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.
-
Sam Whited
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.
-
jonas’
Sam Whited, you should attend board meetings more often
-
jonas’
also maybe become a member again so that you see what’s going on on members@
-
Sam Whited
jonas’: I still don't see the point of being a member of the XSF.
-
jonas’
so that you get a say on that matter
-
Ge0rG
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.
-
Sam Whited
Ge0rG: right, that's why I was thinking about doing it separate from the XSF.
-
jonas’
you’re most definitely not the first one with that thought
-
Ge0rG
I think that the XSF (and XMPP overall) would vastly benefit from having it, though.
-
Sam Whited
yah, probably not
-
Sam Whited
jonas’: a say in what matter?
-
jonas’
Sam Whited, the direction of the XSF and how funds are used.
-
Sam Whited
jonas’: I don't think this should be the XSF, they should be two separate organizations.
-
jonas’
MattJ, cc @ you, I think you brought something like that up in one of the more recent board meetings, too ^
-
jonas’
Sam Whited, yes, and I think such an organisation should have its roots in the XMPP and XSF communities
-
Sam Whited
jonas’: I agree, but like I said, this is just me doing some preliminary research.
-
pep.
!
-
jonas’
I’m saying there’s already efforts in that direction and I suggest you join them. the more the better.
-
MattJ
I bring it up all the time
-
pep.
I'm also interested fwiw
-
MattJ
to anyone who will listen, or who thinks the XSF is capable of doing all the things people want it to do :)
-
pep.
"jonas’> Sam Whited, yes, and I think such an organisation should have its roots in the XMPP and XSF communities", I agree
-
MattJ
Well it's unlikely to have its roots in the Matrix community, I agree :)
-
pep.
No but it could be perceived as a "FU the XSF, it doesn't work, we're doing our own thing"
-
MattJ
I almost thing, so what if it is? (which is unlikely if you're up-front about the goals)✎ -
MattJ
I almost think, so what if it is? (which is unlikely if you're up-front about the goals) ✏
-
MattJ
Modern XMPP also has/had that risk
-
MattJ
Even the name and domain :)
-
Ge0rG
I'm pretty sure it won't, because the XSF is very clear about its razor-sharp focus on Protocol.
-
MattJ
(XSF should register legacyxmpp.org on 1st April)
-
Ge0rG
MattJ: you could do it right now.
-
MattJ
Oh look, that's tomorrow
-
MattJ
Must finish my MAM update in time
-
Sam Whited
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.
-
Ge0rG
MattJ: because you want it to appear on the Humorous track?
-
MattJ
With DNS-over-XMPP on the Standards Track and MAM on the Humorous track we'll be good
-
MattJ
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
-
jonas’
... why would they
-
MattJ
Because people make assumptions
-
jonas’
why do tehy?✎ -
jonas’
why do they? ✏
-
MattJ
:)
-
Sam Whited
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
-
Ge0rG
MattJ: you'd be surprised how many implementations ignore the xmlns altogether
-
flow
well it does
-
flow
if you only match on the id, then you are potentially open to spoofed replies
-
MattJ
You match on (jid, id) though
-
Zash
and type
-
Zash
(jid, id, type=(result|error))
-
Ge0rG
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
-
jonas’
or have a sufficiently unpredictable ID :)
-
pep.
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
-
flow
and even (jid, id) is not that trivial as it seems, since there could be multiple values for jid
-
flow
including, in some cases, nil
-
jonas’
don’t get me started on the ambiguity of an absent @to/@from on stanzas
-
flow
so you may simply want to generate "good" IDs and be done…
-
Sam Whited
Why would there be multiple values for JID? Do you just mean the server being the domain or the empty attribute?
-
jonas’
Sam Whited, that’s not what empty attribute means
-
Zash
jonas’, when is it ambigous?
-
jonas’
absent attribute refers to your *account*, not to the server domain.
-
Sam Whited
oh right, that one. Is that what you menat?
-
jonas’
yes
-
jonas’
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
-
Sam Whited
yah, that's irritating. I just have my library normalize that on all incoming stanzas
-
jonas’
so you have to, in your processing loop, alias empty jid to locally bound bare JID, which is annoying to do
-
jonas’
I recall having issues with normalising that actually
-
Ge0rG
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 ;)
-
Zash
Just don't find the text that suggests that empty to/from is different from the bare account jid.
-
flow
jonas’, do you remember which issues you had exactly?
-
jonas’
(also, of course it requires the stanza broker to know your local JID, because we all hate self-contained things)
-
jonas’
I’ll have to check the git log
-
Sam Whited
What is a "stanza broker"?
-
jonas’
Sam Whited, the thing which takes the stanzas from the XML stream and hands it to handlers
-
jonas’
I think it’s called mux in mellium
-
Sam Whited
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)
-
Sam Whited
The session (or connection) knows your JID, and whenever any tokens are read from it it can normalize them
-
jonas’
my point is that there’s *no* layer which should need to know about your locally bound JID in the stanza processing pipeline
-
Ge0rG
Sam Whited: are you also normalizing <forwarded> stanzas? :D
-
Sam Whited
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
-
jonas’
flow, possibly the normalisation issues were purely in aioxmpp
-
Ge0rG
Sam Whited: yes they are, but they are also <message/> stanzas and there are no guarantees whatsoever on them having @from/@to set correctly
-
Sam Whited
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.
-
Zash
I like to think of it as stanzas inheriting the logical to/from of the parent stream.
-
Zash
After resource binding one could think of those as from=full jid to=bare jid
-
Ge0rG
Zash: that's the logical thing indeed, except that for some people it's not obvious that you have a stream to your account.
-
jonas’
Zash, however, as a client, you set @to to the domain, not to the bare account JID✎ -
jonas’
Zash, however, as a client, you set stream:stream/@to to the domain, not to the bare account JID ✏
-
Zash
jonas’: Imagine that it changes during resource binding
-
jonas’
that does make no sense to me
-
Zash
I kinda wish resource binding was a stream restart thing
-
jonas’
changing on SASL, that’d make sense, because that actually binds you to a JID✎ -
jonas’
changing on SASL, that’d make sense, because that actually binds you to a bare JID of some kind ✏
-
Zash
Drop the resource binding iq hack, server tells you to/from in the post-sasl restart
-
jonas’
that’d be kind of sexy, except that the client speaks first on stream resets
-
Zash
Myeah
-
Zash
+ SASL2 gets rid of the stream restart
-
Zash
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.
-
Zash
And by drop I mean the server ignores it.
-
Sam Whited
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.
-
Zash
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
-
jonas’
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
-
jonas’
aren’t they?
-
flow
jonas’, rumar is that they are supposed to reset the xml parser state✎ -
flow
jonas’, rumor is that they are supposed to reset the xml parser state ✏
-
Zash
and thus throw away auth related state that might linger
-
Zash
which is why it's weird to me that SASL2 drops the restart
-
jonas’
flow, ah, that makes sense
-
jonas’
I’ll probably forget that again, but it *does* make sense
-
MattJ
Pretty sure there have been protocol security problems in the past that didn't apply to XMPP because we do restarts
-
Zash
Also older SASL mechanisms can negotiate encryption and stuff, which requires a clear point where it's activated.
-
flow
I think it's not that bad to have them
-
flow
not sure about the motivation to drop them in sasl2 though
-
Kev
You need a stream restart after integrity is negotiated.
-
Kev
Both starttls and SASL can negotiate integrity, I think.
-
jonas’
Kev, see, that argument I don’t get
-
Zash
Never seen it used in SASL tho, only seen the traces of it in DIGEST-MD5
-
jonas’
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
- Sam Whited realizes that as we speak I am extremely far behind on my phone because the connection got dropped and on this crappy mobile network it takes ages to be re-established.
-
Sam Whited
I'm always confused when I walk up to my laptop and there's a ton of new messages I hadn't seen.
-
Kev
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.
-
jonas’
right, so to/from/stream id are 100% irrelevant, aren’t they?
-
Kev
So you're potentially doing authorisation based on injected data.
-
Kev
I don't believe they are, no.
-
jonas’
you authenticate the server with TLS/SASL, likewise for the client.
-
jonas’
I never saw the stream ID used for anything
-
Zash
It's used in dialback
-
jonas’
that’s more interesting
-
jonas’
(maybe my view is too client-centric?)
-
Kev
I think it might be :)
-
jonas’
but clients are most hurt by stream restarts either way
-
Zash
Didn't the non-SASL auth also use the stream id?
-
Zash
> SHA1-encrypted Hmmm
-
Zash
> SHA1(concat(sid, password))
-
Zash
Obsoleted nearly 12 years ago? Why do we still ship code for this?
-
Zash
Altho I fondly remember typing https://xmpp.org/extensions/xep-0078.html#example-3 into a telnet console once upon a time
-
moparisthebest
I think it should be brought back, just the PLAIN though, and only over TLS of course
-
moparisthebest
if it's good enough for HTTP why not XMPP
-
Zash
eugh
-
moparisthebest
SASL made sense before TLS was mandatory, I don't really think it brings any advantages nowadays though
-
Zash
This notion makes me sad
-
moparisthebest
unless you see "complexity" or "not being able to upgrade ever" as an advantage
-
moparisthebest
are there actual advantages to SASL ?
-
lovetox
you mean SASL SCRAM?
-
Kev
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.
-
lovetox
yeah there is more than sasl scram
-
lovetox
you need a protocol to tell the server how you are going to auth
-
lovetox
may it be via 2FA or external via client cert or even PLAIN
-
Zash
"good enough for http", but the web uses a lot of OAuth and stuff that only works if you're a browser
-
moparisthebest
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
-
moparisthebest
fair re: oauth ugh
-
Zash
Also, I sure hope you're not making the argument that popular == good
-
moparisthebest
no, I'm arguing that PLAIN user+pass is "good enough" and KISS and sasl-scram and friends is needless complexity for no gain
-
lovetox
i agree about sasl scram over tls is probably not very useful
-
lovetox
but not about getting rid of extendable protocol that can define any kind of auth mechanism
-
Ge0rG
it's useful because you don't need to store the password on the client
-
Zash
or on the server
-
Zash
or send it over the wire
-
Zash
even if TLS helps there
-
Sam Whited
More useful than not having an upgrade path if SHA-1 gets broken?
-
Zash
and it's cheap to verify for the server, even if you did a billion rounds of PBKDF2
-
Zash
Does this exact discussion with these exact words get repeated every couple of months?
-
Sam Whited
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
-
Zash
https://github.com/xsf/xmpp.org/pull/592#issuecomment-514935602
-
Sam Whited
yah, they're not wrong, it's not easy to find. Good to know.
-
Zash
Looks like they did a bunch of stuff last year
-
SouL
Hmm, is it a XMPP server?
-
Zash
Yes
-
SouL
I thought it had something different to it (a reason to make it active again that other XMPP servers do not have or something)
-
lovetox
moparisthebest, fyi you cant do the full client cert spec without sasl
-
lovetox
a cert could be valid for more than one account
-
lovetox
so you need a way to tell the server the account you want to auth with
-
lovetox
don't know though if anyone does that
-
moparisthebest
Ge0rG, and how is not storing the password on the client useful?
-
moparisthebest
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
-
jonas’
moparisthebest, that’s a pretty strong "should" there
-
jonas’
first: user reality begs to differ. second: single-sign-on systems *do* exist.
-
moparisthebest
should be a MUST , we need to stop catering to idiots
-
moparisthebest
if someone uses "password" or "mustang1" across all their accounts, it doesn't really matter that the xmpp client doesn't store it locally
-
jonas’
if someone uses "7GvdunCpiwkUKty9dj3/u8l5" for their company single-sign-on which also has an XMPP client, it does matter though✎ -
jonas’
if someone uses "7GvdunCpiwkUKty9dj3/u8l5" for their company single-sign-on which also has an XMPP service, it does matter though ✏
-
Zash
Uh in those cases you can't use SCRAM anyways since you need to send that password in plain text to some validation service.
-
jonas’
shush
-
Zash
... unless it's some OAuth-derivative thing
-
moparisthebest
jonas’, does it? cause their browser stores it in plaintext in that case, also probably outlook
-
jonas’
moparisthebest, "others are bad, let’s also be bad"
-
Zash
burning coal works just fine, let's do more of that!
-
moparisthebest
jonas’, yep, if it provides no benefit in any case and brings complexity, let's not bother
-
moparisthebest
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?
-
jonas’
I don’t agree with your assessment of the SSO situation
-
Zash
I don't agree that there's no benefit.