XSF Discussion - 2024-05-31

Is Egypt known to block XMPP? While my dad was there lots of stuff seemed blocked on web and xmpp didn't work, and I see they at least used to block signal

Why does an XMPP server need a DNS resolver? I'm wondering because 85% of the dependencies of prosody are perl packages to build libunbound; does prosody really need that?

XMPP uses SRV records extensively, which isn't always supported by OS native APIs. Prosody also wants async and DNSSEC support.

Thanks Zash

It's worth pointing out that libunbound is optional (but our "internal" implementation may be less robust and does not support DNSSEC), and that you seem to be talking about build-time dependencies of a dependency, perl is not a direct or indirect runtime dependency of Prosody

We also need all these from Lua, which Prosody is written in. Prior to writing a Lua binding to libunbound, the available options were basically zero unless we'd drop some requirements.

IIRC the openssl build system also depends on perl and is much worse :)

of course yes. in any event as far as dependencies go I'm just pissed at perl (again) for pulling in what looks like an entire webserver suite for it's XML-Parser package alone... I totally agree that libunbound looks correct as a dep of prosody!

Building Prosody requires building a C compiler, which requires a C compiler ;)

or you bootstrap the whole thing with guix and then its scheme all the way down :P

that is how prosody is build on guix i bet

naive q, is dnssec actually important for normal use?

No

Basically everything will work without support too.

isnt authenticity guaranteed if a server can sign its traffic with the correct domaon name?

It is authenticated with valid certificates. DANE is currently only a dream for something better.

DNSSEC is important for my continued motivation

huh on ill read up on dsne ty

manday: it really depends what you're doing and what your threat model is

There are several reasons why dnssec might be important. but indeed just like TLS it is not essential for basic operation

i mean isnt TLS basically essential if you want to federate at all in the xmpp network?

theoretically its not of course. xmpp can be completely unencrypted

TLS has been mandatory since 2014

MSavoritias fae.ve: most servers require it these days yes. But depending how old you are one might consider this recent

heh fair

So yes mandatory DANE checking for s2s is "a dream" but in the way that mandatory TLS was in 2006

Just like with TLS pre-2014, you can enable DANE and it'll work with anyone who set it up. (Read: me, singpolyma, and maybe 5 others 😁️)

83 hosts at least according to certwatch

Neat

but tls alone *should* be enough to protect against mitm, right?

dnssec is not needed for that

No, because you need to know the certificate is valid somehow

See eg jabber.ru mitm incident

But isn't the TLS certificate signed by the parent CA?

If the attacker has control over the dns, then they can mitm it. https://notes.valdikss.org.ru/jabber.ru-mitm/ ✏

So you know that the server you are talking to really *is* certified to be server XYZ?

https://notes.valdikss.org.ru/jabber.ru-mitm/ The attacker got valid letsencrypt certs by controlling the ip See the small abbr on top

_generally_ valid certs are quite good yes.

_often_ good enough

The CA process these days is "do the sit in the path to the ip address advertised by dns?" So any mitm can get a valid cert

Sorry, any mitm of the server. Not an mitm of your client ✏

So the CA system as used protects one half of the attack surface

Fun fact: The rules for CAs are made by the CAs and the web browser vendors. _We_ here, or email, or other TLS stakeholders have very little say.

(modulo old cas which do things by hand and may be social engineered)

Hm okay, how disappointing

Didn't know that's the way things are

The 'HTTP-01' ACME challenge method looks a lot like trust-on-first-use, recorded in a file and signed by the CA

It's probably an improvement in how they used to be, where it was always done manually and could be social engineered

Now it's almost always automated

CAs use DNS before they give you a certificate. DNSSEC can help secure some bits there, which is nice.

There's a whole bunch of possible mitigations, but for many things and especially for xmpp s2s specifically, DANE is the gold standard

E.g. when they fetch TXT or CAA records

Zash I'm still trying to wrap my head around the unbound dependency of prosody (and the lua bindings). Why is it that prosody itself has to be concerned with DNSSEC? I've read that normally to use DNSSEC you have the program just use normal DNS lookup to a local, secure DNS server (like unbound; I guess) - why is it not done that way in prosody?

> Is Egypt known to block XMPP? While my dad was there lots of stuff seemed blocked on web and xmpp didn't work, and I see they at least used to block signal Did you see I added a setting to enforce DANE connections in monocles chat singpolyma ? ↺

(i.e. anyone wanting to assert authenticity of DNS will use a regular DNS lookup, e.g. libc, and the system admin will guarantee that the result is secured by running a DNSSEC server locally)

> Is Egypt known to block XMPP? While my dad was there lots of stuff seemed blocked on web and xmpp didn't work, and I see they at least used to block signal singpolyma: does the XMPP server support direct TLS on port 443 ↺

manday: this might help https://wiki.xmpp.org/web/The_Knight

Yes all systems should hopefully be set up to reject bad DNSSEC signed records, the problem for prosody or anything using Dane comes from the fact that without special DNS tools you can't tell the difference between "valid because it's signed with DNSSEC" vs "valid because DNSSEC isn't enabled on the domain"

uhm... wouldn't the (local) resolver figure out the difference?

I don't understand what prosody can possibly achieve by meddling with DNSSEC directly (and thereby accepting or rejecting) than just let the local DNS server accept or reject as is right

(i can't say I've grasped DNSSEC I admit, as I just learned TLS can't be trusted because certs are being given away to malicious parties, how does the same not apply to breaking the chain of trust in DNSSEC, ... meh)

> uhm... wouldn't the (local) resolver figure out the difference? manday: yes, but prosody needs to know the difference because it affects how TLS certificates are authenticated (read the wiki I linked and ask if you need more clarification) ↺

I actually read the story of the knight but what you refer to must have eluded me, I'll read more carefully again ;)

in effect though, I deduce from your statement that libc's resolver is unfit for DNSSEC and needs a better API... (?)

> Zash I'm still trying to wrap my head around the unbound dependency of prosody (and the lua bindings). Why is it that prosody itself has to be concerned with DNSSEC? I've read that normally to use DNSSEC you have the program just use normal DNS lookup to a local, secure DNS server (like unbound; I guess) - why is it not done that way in prosody? By validating in the process itself there's no room for anything inbetween to flip the single bit that says an anwer is secure. ↺

manday, and the primary reason is to have async DNS support that supports SRV records. By using libunbound, we can concentrate on developing an XMPP server instead of having to also develop a stub DNS resolver (which you can still use if you don't want to use libunbound)

> in effect though, I deduce from your statement that libc's resolver is unfit for DNSSEC and needs a better API... (?) manday: I mean... Yes? Or no depending on if your application cares 😂 in TLS using applications, DNSSEC status changes the way TLS is validated, so those need them for ssh/ping the current API is fine ↺

so basically some minimal info would have to be added to addrinfo in https://man7.org/linux/man-pages/man3/getaddrinfo.3.html to make libc sufficient? is there a pr for that?

Does it support SRV records? Does it support async queries?

Those are the hard requirements.

no zach your points nonwithstandinf

DNSSEC is a nice-to-have

asynch however i dont see the problem, thats something an app can do and wouldnt require an entire resolver builtin

It's ok all apps will have their own DNS resolver soon because https mandates it now

http3 specifically

😯

also everybody uses browers or browser containers now which also have their own resolvers pretty much

libc things are obsolete for a while

Browsers have had their own for... Probably a decade at least

yep

>> Is Egypt known to block XMPP? While my dad was there lots of stuff seemed blocked on web and xmpp didn't work, and I see they at least used to block signal > Did you see I added a setting to enforce DANE connections in monocles chat singpolyma ? Arne-Brün: that's great! I have it on my list to add such an option soon as well ↺

none of them dep on unbound though so i didnt notice 😂

> Yes all systems should hopefully be set up to reject bad DNSSEC signed records, the problem for prosody or anything using Dane comes from the fact that without special DNS tools you can't tell the difference between "valid because it's signed with DNSSEC" vs "valid because DNSSEC isn't enabled on the domain" Well, you can if you trust the resolver (eg it is in localhost) by checking the ad flag ↺

>> Yes all systems should hopefully be set up to reject bad DNSSEC signed records, the problem for prosody or anything using Dane comes from the fact that without special DNS tools you can't tell the difference between "valid because it's signed with DNSSEC" vs "valid because DNSSEC isn't enabled on the domain" > Well, you can if you trust the resolver (eg it is in localhost) by checking the ad flag Which you need special support for, getaddrinfo isn't enough, and we are back at square 1 😁 ↺

Oh sure, getaddrinfo doesn't return the flags AFAIK

>> Is Egypt known to block XMPP? While my dad was there lots of stuff seemed blocked on web and xmpp didn't work, and I see they at least used to block signal > singpolyma: does the XMPP server support direct TLS on port 443 singpolyma: so? 😁 ↺

i mean it's prolly a good thing that we are moving away from libc resolver - a chance for one kitchen sink fewer in libc, right? 🙃

moparisthebest: since they were blocking most 443 traffic as well I'm not sure that would have helped. But definitely not relevant to my question 🙂

singpolyma: I think it is relevant? I'm wondering if they were blocking/filtering TLS on port 443 or not, and if so, in what way?

"are they blocking XMPP" isn't that helpful "how are they blocking XMPP" is what we need to know for how to work around

Need to know if there's anything to work around first though

sure

But knowing that the server supported TLS on 443, if the client still couldn't connect, would indicate either srv is blocked or they are filtering TLS on 443

Well we know they're not filtering *all* TLS on 443 at least since any (but not all) webpages work

> I actually read the story of the knight but what you refer to must have eluded me, I'll read more carefully again ;) Ah, the Knight is still around. Poor chap. You may prefer RFC 6125, but the short version is that DNSSEC allows us to gather more than one domain name to match against the Subject of the certificate (either by Subject CommonName, or better, by an explicit SAN). Additionally, we can look up TLSA records, use DANE, and potentially ignore bits of PKIX, potentially even all of it.

One of these days, RFC 7250

The sad irony is DNSSEC let's us validate a cert against more than one domain, but SNI only allows us to ask for a cert matching 1 domain, so... gotta guess or try multiple times 😱

dwd: for the record I always thought the knight story was perfect and frankly the best way I've ever seen this mess explained to date <3

> The sad irony is DNSSEC let's us validate a cert against more than one domain, but SNI only allows us to ask for a cert matching 1 domain, so... gotta guess or try multiple times 😱 Luckily in practise we always know exactly what domain is in the jid anyway ↺

> The sad irony is DNSSEC let's us validate a cert against more than one domain, but SNI only allows us to ask for a cert matching 1 domain, so... gotta guess or try multiple times 😱 SNI also only says what domain the client wants, not what domain the server should expect. Some of Metre's use cases are quite tricky due to that on '368

Once you use DANE SNI becomes borderline meaningless anyway since your certs don't need to have any particular names in them.

and with RFC 7250 you don't even need the certificate container! ✏

https://mov.im/stickers/miho/e599dca3de182a821ef2e92234fb2bfca04a325e.png

> Once you use DANE SNI becomes borderline meaningless anyway since your certs don't need to have any particular names in them. Only if all your clients support Dane though, in the meantime you have to hand them the cert they ask for with sni ↺

I'm not usually thinking if clients when I talk about certs, but sure either way we support pkix fallback yes. And SNI works the same there as it always did

I enjoyed reading these words: https://lobste.rs/s/ymxynk/calling_time_on_dnssec#c_hfqngl

I liked that comment but also enjoyed that they misremembered the name as xmpp.ru

> I'm not usually thinking if clients when I talk about certs, but sure either way we support pkix fallback yes. And SNI works the same there as it always did singpolyma: no it can't, say with DNSSEC you will accept a cert for bob.com or srv1.xmpphost.net, you have to ask for one with SNI and you don't know which they have, if you ask for bob.com and they send you a cert only valid for alice.com you really have to ask again using srv1.xmpphost.net because they might have that instead ↺

With dnssec+DANE I will accept for *any* name not just those two

Accepting any name and asking for a particular name with SNI are separate things

Right. So ask for the correct name (bob.com) and that's it. I'm not going to enumerate every possible name just because I accept them all

Ok so take what I said above, and replace "they send you a cert only valid for alice.com" with "they send you a cert who's key doesn't match what DANE says", it's the same problem, you still have to ask up to twice

You have to

You don't know how the server was configured

No I don't. And anyone who does is doing it wrong

Ask for bob.com

If the server doesn't give you the right cert the server is broken

The SRV target scenario doesn't happen because that wouldn't work with legacy PKIX clients

Exactly

We're only using SNI for fallback

So use what works with the fallback case

So no hosting delegatio n ✏

So no hosting delegation ✏

Not in a pkix world no

In a Dane only world sure, it'll just work

singpolyma, have you been following the dance wg (client-dane) btw? I'm subscribed to the mailing list but haven't hade the energy to do anything but read

No. Some new disaster we need to watch out for?

Not sure if any of the now discussed problems were in scope

My main concern is s2s since clients we could do by tofu or all kinds of other stuff if we really had to

Nah, because DANE only authenticates the server side, DANCE is about authenticating clients, I was under the impression this included server "clients" in order to bring non-hacky mutual authentication. ✏

Instead of the check-back thing you do now?

That could be nice if it turns out good

Though check-back seems fine

Who are they even working on it for? What protocol has use for this?

Too sleepy to go check now, only bit I remember is a location for a single set of TLSA records so you don't have to go chase SRV first

But there was also stuff for IoT clients.

Might have been some TLS extension, unless I misremember, which could be useful in a decade when openssl might have support for it

If the connecting party could just include its own signed DNSSEC chain in the handshake to authenticate its own ~client certificate~ public key, It Would Be Nice

So long as people don't have to go change all their dns records again, I'm in

You could go add `_xmpp-server.example.com IN CNAME _5269._tcp.example.com` for a tiny speed boost with some Prosody trunk

or add that name to your TLSA automation

singpolyma: Sounds like you are saying servers and clients have to do 1 thing in a CA world (current world) and a totally different thing in a DANE world, with no way to migrate between the two then?

moparisthebest: no. I'm saying it's exactly the same for both

Unless they want to do something Dane can do that pkix can't do

It'd be nice if there was a DANE-SNI TLS extension for saying "Hey I know DANE and I expect you to show me some credential matching this [TLSA record OR hostname]"

singpolyma: Could you name one server that you can configure to serve multiple certs with SNI where you can configure it to hand out the cert only valid for srv1.xmpphost.com when SNI contains bob.com ? I'm not aware of any

Oh indeed. Sending SNI of a cert hash or something would be Neat but not useful in a dual with pkix world

moparisthebest: yes. Prosody

I mean, don't do that it's silly. But you can easily

How? I'm 90% sure you can't

If you specify certs manually likenobody should anymore, you can make it send any certificates you want at any time. ✏

If you specify certs manually like nobody should anymore, you can make it send any certificates you want at any time. ✏

Yup

Which is all I ever do anyway since it's easier on my brain than copying all certs into prosody's magic store thing

You may need a recent Prosody for SNI stuff to be non-automatic tho

singpolyma, if you spent a decade watching everyone use the manual settings to shoot themselves in the foot, because they read a guide written by someone who shot themselves in the foot without noticing, you'd appreciate the magic too

Zash: i believe you. I have to config certs for all my other services anyway and my certs all live in a single folder already because that's where my acme puts them, so it just makes sense to me to config them in the server config like anything else. I appreciate that the feature is useful to others and that's fine

If it works for you (and you don't have holes in your feet) then carry on :)

✏