XMPP Council - 2024-05-14

Hi

It’s time

1) Roll call

👋️

singpolyma, moparisthebest dan.caseley you around?

we don’t really have anything on the agenda. I (Editor) only just now processed a new proto xep which didn’t make it into this weeks agenda

👋

but will be put into next weeks agenda

as a bit of homework for next week maybe familiarize yourself with the current Last Calls (occupant ids and channel binding)

for occupant ids it looks like larma as the author might want to add 1-2 sentences to the security section

Yes

channel binding will probably be more controversial...

Good shout

we barely have quorum but I’m gonna spare everyone from going through an empty agenda. we have no pending votes either

No objection :)

so yes. see you next week. Thanks :-)

Hi, I'm late but I guess we're done heh

Thanks daniel

oops sorry about that, thanks for the updates! I gotta catch up on mailing list for channel binding and respond again 💀

A quick summary of my current stance is that '440 needs deprecated and clients should just try tls-exporter on TLS 1.3 and pin it to always be required if it works, that's it.

Clients are free to do that, though it will make upgrading to a better one harder when exporter breaks

Even that leaves a bunch of open questions... What if suddenly as a client you can only connect to websockets?

If someone insists on doing websockets in a real client they can still do channel binding

> Clients are free to do that, though it will make upgrading to a better one harder when exporter breaks singpolyma: I think in the upgrade case clients are always free to try the stronger one and pin that if it works... I'm still not convinced asking the potentially evil server if you should upgrade is good ↺

> If someone insists on doing websockets in a real client they can still do channel binding Right but it seems like a potential footgun for admins, maybe should be documented somewhere ↺

I understand that exporter is currently the best secure channel binding mechanism. But 440 still adds something to XMPP ✏

> I understand that exporter is currently the best secure channel binding mechanism. But 440 still adds something to XMPP What does it add? I think just negotiation with the attacker between 3 channel binding methods, 2 broken and 1 good 😬 *If* we want this negotiation, I'm not fully convinced it's good, but if we do, the XEP needs to: 1. Clearly spell out the priority/upgrade path between methods 2. Clearly spell out all the footguns with tls-unique, like how it MUST NEVER be used in the absence of the TLS master secret extension, since that renders it trivially vulnerable to the MITM it's trying to prevent. 3. Clearly spell out what guarantees these provide and what they don't. 4. Provide a time/ttl to cache these, either via protocol or a MUST in the XEP or something. Otherwise attacker can just not offer them. 5. Document known attacks, like offering tls-unique/tls1.3 and then a mitm coming along and only offering tls-unique/tls1.2 without the master secret extension. ↺

Actually if we want this negotiable, probably makes sense to advertise it out of band, either host-meta-2 or DNSSEC, both already having the needed TTL

I honestly think the place for most of that info is in the communities/specs that define the channel binding methods. We don't document known tls vulns either because it's out of scope we just say "use tls"

Maybe, but unless there's a place to point to then we have to do it imho, we can't publish a security spec full of known footguns and just hope client authors do all the research

channel-binding is a bit more of a special case than TLS because it's nearly only XMPP that does it

Even XMPP didn't until a few months ago 🙂

I really wonder how much of the xmpp network uses tls1.3

And now because of missing security considerations and no one having done the research they are all vulnerable to the MITM this was meant to prevent... Feels like this proves my point

daniel, >90% of s2s from what I can tell

(a mitm from 2015 documented in the tls-exporter RFC by the way)

I mean the XEP was written before exporter existed. Maybe it is save to just assume exporter when -PLUS is announced

I guess I'm not fully convinced that assuming (which is what moparisthebest is advocating for) is better than knowing

Didn't we need this because Java land can *only* do the cert hash channel binding?

daniel: see https://curl.se/mail/lib-2024-03/0006.html I know https isn't XMPP but tl;dr every maintained XMPP server already supports 1.3

Knowing (which is what 440) gives you doesn't mean you can't enforce exporter if you choose to

> Didn't we need this because Java land can *only* do the cert hash channel binding? That may or may not have been true when the xep was written

Conversations does exporter

> Knowing (which is what 440) gives you doesn't mean you can't enforce exporter if you choose to But without security considerations, it does open you to trivial attacks that simply enforcing exporter does not ↺

> And now because of missing security considerations and no one having done the research they are all vulnerable to the MITM this was meant to prevent... Feels like this proves my point Um, not in any way they weren't before? ↺

endpoint isn't insecure

It just doesn't protect against all attacks that exporter might

I realize that stealing certs might be a thing. But it might also not be

endpoint is also needed by ~MITM~ TLS offloading proxies

We can't use those anyway because none support starttls

> endpoint is also needed by ~MITM~ TLS offloading proxies Yes and no. An argument has been made that the proxy could also just forward the exporter bytes

That's obviously custom code. But if you have the need for early tls termination you are in it so deep that a bit of custom code won't hurt you

True. In theory.

But from what I gather it's all HAproxy PROXY protocol, and unless that supports it then it's unlikely to happen

Fwiw I reckon that if you do early tls termination you are not doing starttls

I honestly don't know why anyone would use starttls these days

> Fwiw I reckon that if you do early tls termination you are not doing starttls Sure, but then you won't be able to federate ↺

I did! Nginx did! :P

No channel binding for s2s (yet) tho, so how does that matter?

Yeah I'm just speaking about c2s here

Oh, right. No channel binding for s2s so I guess I'm back to not caring about it

xmpp-proxy does TLS termination and starttls and I've had the code 95% done to pass the exporter bytes to prosody over the PROXY header for months 💀 just need to stop being lazy, figure out the Lua, and push it

Though are you going to tls proxy for c2s but not s2s? Seems like a very unique setup

>> And now because of missing security considerations and no one having done the research they are all vulnerable to the MITM this was meant to prevent... Feels like this proves my point > Um, not in any way they weren't before? Except now they think they have some protection against MITM but they don't, which is worse ↺

I think they thought that before to, so it's the same 😂

xmpp-proxy supports c2s and s2s if that's the question

I think when people talk about tls proxies they mean generic ones one finds in a hosting platform, not xmpp-proxy 😉

> xmpp-proxy does TLS termination and starttls and I've had the code 95% done to pass the exporter bytes to prosody over the PROXY header for months 💀 just need to stop being lazy, figure out the Lua, and push it How is that done? I just read the proxy 'spec' and it doesn't seem like it has extensions

> I realize that stealing certs might be a thing. But it might also not be daniel: imho if they can steal the cert they can also steal the user credential database and neither channel binding nor key pinning can detect this ↺

>> xmpp-proxy does TLS termination and starttls and I've had the code 95% done to pass the exporter bytes to prosody over the PROXY header for months 💀 just need to stop being lazy, figure out the Lua, and push it > How is that done? I just read the proxy 'spec' and it doesn't seem like it has extensions daniel: PROXY v2 has extensions, v1 is just text based like IRC so can just add something non-standard to the end ↺

> I think when people talk about tls proxies they mean generic ones one finds in a hosting platform, not xmpp-proxy 😉 singpolyma: PRs to those welcome I suppose :P I can't help it they aren't fully featured 🤣 ↺

If we go the "when a server announces -PLUS we mean exporter" route we need an informational xep to document that I guess?

And mention that in the compliance suite and other relevant places?

The only down side to that approach is that we can never upgrade to something better than exporter

And so you'd cache+pin the scram mechanism and exporter would be implied? Seems good

If we ever get a solution to upgrade scram mechs it could be used here too 💀

We'll be moving to opaque before that happens 😉