jdev - 2022-02-24

does anyone know of a live server I can find a /.well-known/posh/xmpp-client.json or /.well-known/posh/xmpp-server.json on ?

moparisthebest, anything hosted by conversations.im, I think

though apparently not *anything*

but some things

the one (private) domain I knew of did not have it

moparisthebest, https://badxmpp.eu/ to the rescue

Specifically posh.badxmpp.eu

MattJ: thanks! Praise zash as usual :)

🙂

jonas’: that was my first stop, but none on conversations.im itself and I don't know anything hosted by it offhand

Also note that you probably won't find xmpp-server.json anywhere in the wild

We've discussed just using xmpp-client for s2s :)

MattJ: like just combining them both and allowing any match?

Probably

I honestly can't think of a problem with that

I think we should ensure implementations never let POSH override DANE or better mechanisms. In particular, there really ought to be a secure way to opt out of POSH, but I can't think of anything except that

e.g. I would rather if my web hosting provider didn't have the ability to compromise my XMPP service with the presence of a file or two

That makes sense, the downside of course is that hardly anyone does DNSSEC

MattJ: DANE obviously ranks above all, where does POSH rank against CAs though?

Though... Now that I'm thinking about it, I'm not positive it's more common for people to host their own DNSSEC than HTTPS ?

As in it'd be more likely for your DNS host to compromise your XMPP server than your web hosting provider? Maybe?

POSH is roughly equivalent to CA (if LE) isn't it?

Kev: I can't immediately come up with a convincing argument as to how they are different yea

I guess if your DNS host is compromised it's game over anyway, as they can not only set DANE but also get certificates and host your https and XMPP... So "evil web host" is an additional attack vector on top of that existing one

Ah, you're right. CA is better than POSH even when LE.

Better or the same?

Will if you can get a ca cert there's no need to do posh I guess? So posh is an additional attack vector on top of an existing one? *Unless* your web host that hosts posh is protected with Dane??????

My head hurts

If you use POSH there's one extra machine (potentially) that compromising would affect the trust chain.

(And if it's not an extra machine, you may as well not use POSH)

Yea, unless DANE

Even if DANE, no?

Hmm... Need more coffee

Assuming you mean DANE of the POSH host (because if you DANE on XMPP you don't need it on the POSH host).

Because if the POSH host is compromised (host itself, not DNS), it's an extra point that can lie, despite having valid certs.

Thinking about it, if you can do Dane why have POSH

If you can DANE on the XMPP host, yes, POSH doesn't seem to do anything (to me).

A Dane capable client wouldn't check Dane on posh because it would never get there

So absent Dane, you basically have to trust CA *or* POSH

There's no secure way to say "please don't trust POSH" other than DANE

And POSH isn't the only way your https host can compromise your XMPP server, websockets/Bosh can do it too

If you expose those, yes.

No, even if you don't expose them right?

No, an attacker who has access to your web server can advertise any BOSH/WS URLs and intercept your XMPP traffic using those mechanisms (and that discovery mechanism)

^

DANE > (POSH if some conditions else PKIX) or somesuch

would any of you care to provide feedback on my very related adding things to xep-156 host-meta proposal in council@ ? :)

actually I'm not sure order really matters, I mean, you can apply the order for outbound connections, but for incoming s2s you basically just have to apply "any of DANE or CA or POSH goes" right ?

the end result being your webhost can make outgoing S2S connections on your behalf 100% of the time ?