XSF Discussion - 2022-01-30

pep.: I don't understand how clients negotiate it. I think it should be users negotiating it. Maybe like OTR in Pidgin worked, where you got a message "user x wants to start an OTR session" and if you also wanted to use OTR you started the session.

OTR plugin exists in Psi/Psi+

Neustradamus, I'm sure you mean well, but this is not the point.

mdosch, I don't have an answer right now. I don't think I'm really fond of exposing it this way to the user. Also that doesn't solve my problem anyway. A user/client can still miss the negotiation message

flow, All domains of a server *can* use the same s2s connection via multiplexing (aka piggybacking), but it's broken in several servers. Openfire, I think, gets it right, as does Metre. But Metre has to have an explicit switch to turn it off for some/all peers because some servers just get confused.

Read: Yes, but actually no.

Zash, Well, I was being diplomatic. I only know of one popular server that can't do it properly.

dwd, you sure have a pointer where this behavior is specified :)

care to share?

flow, Well, XEP-0220 covers it in https://xmpp.org/extensions/xep-0220.html#multiplex

thanks!

... but never found actual implementations that used it.

So hard to know if there're any related bugs to it.

The only one using it was gmail (and it worked), but that's long gone.

Maranda, Openfire always has, and sometimes quite aggressively multiplexes. Metre, equally, agressively multiplexes if the option's enabled. ejabberd appears to handle inbound multiplexing fine, but I can't actually recall if it does outbound, and if so whether it's doing source or target or both.

Maranda, But Prosody can't handle some cases of inbound multiplexing because of the assumptions around routing of some responses - so unless you've rewritten that part I'd expect Metronome to be similarly affected.

dwd: don't recall any Openfire actually ever multiplexing but good to know

dwd: I rewrote most of dialback code, and multiplexing case handling in s2s.

I don't recall ever seeing multiplexing used by anything or anyone other than dwd, so all the multiplexing code is mostly dead and likely full of bugs by now.

(Also for BIDI handling of dialback verification)

The intersection of bidi and dialback ... I don't even know

The reason Metre actively tries to multiplex if possible (and as a general reason I think it's valuable) is not only that it saves some resource on the servers but also that it makes association of network traffic with specific domains harder to a passive observer.

How many virtual hosts really share the same physical host? Plz can haz research 🙂

I suspect it also helps if you've got unusual transports in play, like XEP-0365.

Zash, Well, for hosts that have both popular MUCs and lots of users, I think that's significant, as well as the mass hosting providers like conversations.im.

As I may have said before, I think XEP-0288 gives more benefit for less complexity than full on multiplexing.

dwd: I brought this up in here the other day, do you have any thoughts on multiplexing with certificate auth instead of dialback?

moparisthebest: Are you aware of the thing called "dialback-without-dialback" (dwd for short)

And a different but related question, do you know of any implementations of mux

Zash: yep which is ideal but requires all domains under 1 certificate

Which makes it equivalent to an SASL EXTERNAL exchange, except not limited to the start of the session.

Yes, but can't handle multiple certs

Praise TLS 1.3 and the removal of renegotiation (which could let you show a different cert)!

Again I would have thought something like this already existed, but if not... Couldn't server A say "hey I'm bob.com and I'd like to multiplex" and server B could say "ok here's a random value, sign it with your private key and send it back to me with your certificate" ?

moparisthebest, fwiw what you ask for does not exist because of the web, where application servers rarely have access to the tls certificate keys. instead they often use what amounts to dialback, or some other key that you need to fetch (whops, dialback with extra steps)

Seems plausible

WebSub (formerly PubSubHubbub - federated push for RSS and Atom which OStatus used) does Dialback over HTTP (but it seems they purged the XEP-0220 reference) I'm unable to navigate the ActivityPub specification so I can't find where it was I saw PEM certificates embedded in JSON. Matrix has https://spec.matrix.org/v1.1/server-server-api/#retrieving-server-keys

moparisthebest, What Zash says, plus DANE. I did wonder about having Metre try the same endpoint to get a different cert, and then if the cert passed to try something clever with dialback, but the problem is I couldn't work out a something clever, and in any case the bulk of the time (CPU and wall-clock) is in the session start anyway. By the time you've identified that the new session is OK, you may as well just use it.

This^

moparisthebest, But yes, you could just exchange signed nonces with a certificate chain to do the same. I think TLSv1.3 would ordinarily encrypt the certificate exchange anyway, otherwise it might even offer some advantages.

Not sure what you mean, I'm saying a method where you could use existing connections instead of start new ones would be preferable, no?

It would.

This does mean you need access to the key outside of the code that initializes the TLS stack.

Right, is there a problem with that?

Not a problem, but friction.

Yea, I tend to think it'd be simpler overall though

In Prosody, we don't really have much crypto stuff beyond simple hash functions. The TLS stack is fairly self-contained, we just figure out which cert and key files to use and hand those off to OpenSSL and off it goes.

The API we use doesn't really let us sign arbitrary blobs or use the keys or certs for anything other than name checks.

This is why the crypto stuff that the Tigase push extensions needs is provided by a different OpenSSL wrapper 🙂