XSF Discussion - 2022-12-22

When reading https://xmpp.org/extensions/xep-0178.html#s2s I am surprised that there is no mention of Server1 validating the certificate of Server2. Am I misreading or misunderstanding things? RFC 6120 13.7.2 seems to suggest that this is a MUST.

Orthogonal from EXTERNAL I suppose

What do you mean?

EXTERNAL is about authenticating with a client certificate.

Uh, "server1" and "server2" is confusing.

Server1 is the initiator.

EXTERNAL implies server2 validates the client certificate sent by server1. The validation in the other direction is not part of EXTERNAL, so I guess it's left out here.

RFC 6120 wording on the matter still applies, right? MUST validate the certificate, but there's no negotiation involved. You're supposed to just abort the connection if it doesn't validate, altho Prosody will send a stream error with the reason before it closes the connection.

Although it's not part of the SASL authentication bit, leaving out that validation probably makes it really easy to miss that, if someone is following a 'best practices' document.

True

What does 178 add over just reading the RFC?

"Best Practices" suggests that there are other approaches to doing SASL EXTERNAL?

Are there?

I made my last comment a question, as I am not sure if that's the case.

Is it not something of a relic from the times when Dialback was the only thing used?

SASL EXTERNAL basically means: anything goes. If you can authenticate based on the phase of the moon, you could. XEP-0178 explains that you can use the TLS certificate as a means to derive authentication. ✏

Well, sure, you could authenticate with "your IP address looks cool" ala SMTP and SPF

Guus, you don't happen to be interested in authoring an informational XEP on modern mutual authentication for s2s? :)

Oh nice

(please don't actually implement SPF for XMPP)

Zash, indeed, I don't happen to be interested. :)

Aaaw

Something something Direct TLS, SASL EXTERNAL, mTLS, XEP-0288

SPF would work better for XMPP than it does for SMTP, since we don't do relaying or bouncing

But probably not r good idea still

One step down from Dialback?

Yeah

Note to self: Do not give bad ideas as examples, people keep deploying them.

Dialback can't really be beat

Because it works without certificates, in the horrible world where everything is behind seven layers of reverse proxies?

Because it's vulnerable only to BGP type spoofing (assuming DNSSEC obvz) and verifies bidirectional connectivity

I guess strictly speaking dialback+DANE would be even better

:sob:

Can haz DANCE?