XSF Discussion - 2022-01-27

It's not used, because it's impossible to upgrade hashes

The only people that could move to new scram are already using plain and for a reason

It does not mean its okay to do so in other repositories...

Does anyone have experience with device binding?

Guus, device binding?

allowing an account to be used by authorized devices only.

Like, authenticate with a cert?

I'm unsure what implementation is appropriate (which is why I'm asking).

Well, forcing certificate-based auth for an account and whitelisting a list of certs would be one way, I guess

One device = one cert

Or copy the key over every authorized device. Less secure, obviously :)

Don't have any expirience though, even client-side. Conversations is one of the clients supporting cert login

Guus, Do you mean "device" or "client" here?

dwd: device

(separately, 'client' make/model/version would be interesting too)

Guus, OK. Can this be *any* device? As in, BOYD phones can be authorised devices?

Guus, And if they uninstall and reinstall the client does this invalidate or maintain the authorisation?

dwd: none of this has been specified (yet).

I know that my client/customer is producing it's own hardware, so I can make guestimates - but on the other hand, I'd like to gain understanding of how such a feature could work in a broarder sense.

(I'm not sure if "produce own hardware" is more than "ship phone to factory to have its casing engraved", but alas)

if we're really talking devices, then some TPM magic might do

Well, if we're talking Android custom spec devices, then many of those have the capability for an HSM on them, so you've got a device private key you can then authorize via an X.509 route.

As jonas’ says, there's TPM on other platforms, which I know less about.

isn't TPM a special implementation of an HSM?

Guus, FWIW, Apple devices have the same HSM capability, and some Apple services authorize via presenting an X.509 cert signed by Apple's CA.

jonas’, Plus other bits I think? As I say, not really something I know much about.

possibly

I only looked into the API spec briefly

jonas’, But yeah, having a private key feels likely there too. In which case the manufacturer can sign it with a CA (doesn't need to be a public one), and then authorize the device that way.

Thanks guys.

Guus, Whichever, I think I'm right in saying that any sane implementation of this is going to end up with X.509 certs on the device. Even if it has to be fully software, and you're just relying on the device not being badly jailbroken.

I guess that makes sense.

How would we verify that in a scenario that involves XMPP clients?

Does this boil down to your earlier attempts at multi-phase auth?

s/attempts at/work on/

I'm planning to work on that stuff in Prosody in the coming months, but I'm pretty sure this use-case doesn't even need any of that

We've done something in M-Link for a customer where they would issue certs to devices and then we'd autocreate accounts on the server based on presenting a trusted cert, IIRC, but it was some years ago.

Hello, I'm new to XMPP and think about setting up an own server. I've set up a Mumble server before, which was quite easy, but I haven't found any information about whether I need a domain for an XMPP server or not. I prefer to host a server on demand without a domain but IP address (like Mumble). Is that possible? Sorry, if this isn't the right place to ask.

Hi Max, welcome to XMPP 🙂

I'm unfamiliar with Mumble. Technically, it's possible to run an XMPP domain that is an IP address, but it'll be challenging to establish any kind of publicly trusted TLS connectivity.

You generally will need a domain, yes. Due to TLS, and the potential for IP changes, etc.

also, "on demand" suggests that you're thinking of turning it on and off continuously? If your IP address will be your XMPP domain name, then that changes to your IP will cause issues.

XMPP is more like email, so if you set up your server on an IP address then your users would get XMPP addresses like max@203.0.113.123 instead of max@example.com

and if you ever need to move the server to a different IP, your user addresses have to change and that will break many things

*unless* you decide you don't want federation, and you can find clients that allow you to override TLS certificate checking, and supply custom connection information

You can easily experiment with such a setup (IP-based, maybe mimicing domain names in hosts-files), but I'd not recommend using that "in production". It will probably also be challenging/impossible to turn such an experimental setup to one that is usable in the long term (you'll have to start over)

Also, Matt is a lot smarter than me so listen to him better. :)

and (in addition to not federating) you're ready for rewriting all of your server side storage whenever you change the IP address

Guus, Answering your previous - no, you can just mandate a known certificate from "your" CA on C2S TLS. I think the right settings on Openfire's C2S TLS config will actually do this all for you without additional code required.

Max, you might also find the Snikket FAQ on this topic helpful: https://snikket.org/faq/#q-do-i-need-to-register-a-domain-name-to-use-snikket

dwd: would that work? Doesn't that remove the distinction between 'device' and 'user' ?

Guus, Yes/yes. If you want to explicitly have a 1:1 user:device relationship then you'll also need SASL EXTERNAL and things though.

dwd (which would cause issues when one user wants to use two authorized devices)

authzid=user@host/device ?

Zash, Well, authzid=user@host still, and authcid=device, if you wanted to go that route.

Huh?

Thanks Matt and Guus for the welcome! 🙂 That sounds interesting. I didn't expect that you can "simply" have an IP address as domain. My server would be a private one for very few people (2 to 3 maybe). I would create accounts for those users. I already experienced IP changes in the past, I then had to tell the others the new IP address to reconnect to Mumble and all was fine. The XMPP server would run on my laptop and therefore only as long as that laptop is running.

Zash, The authentication identifer would be the TLS certificate, and that identifies a specific device. The authorization identifer is always the Jid in XMPP.

I've seen things that put the full JID into ... one of those, e.g. in PLAIN

Zash, In the authentication identifier field or the authorization identifier field? The authzid is a bare Jid by standard (though we're all slack and allow just local parts and assume the domain). See: https://datatracker.ietf.org/doc/html/rfc6120#section-6.3.8

Zash, Whereas the authentication identifier is mechanism specific (and can be site specific).

Uh, which one is the first (usually zero-length) field in PLAIN? That's the one usually ignored and sometimes observed to contain the full JID from weird clients

Max, if your users are technical folk, it's probably possible. Give it a try if you want, but just be aware that you'll likely encounter a lot of limitations and hurdles compared to using a domain.

I thought it was authzid \0 authcid \0 password

Max, If you're using an XMPP server with only an IP address, the IP address becomes part of the account name, so if your IP address changes then the accounts become invalid. What you *can* do, though, is use a dummy (non-existent) domain name for the server and tell people to connect with the IP address. That's not supported on all clients, though, and still leaves you with TLS problems.

Zash, I think you're right. [authzid]\0authcid\0password in PLAIN. But if authzid is provided the server must validate it and either honour it or reject the authentication with invalid-authzid.

... Prosody just ignores the authzid 🙂

Max, if you're in control of the network, you might be able to 'fake' a domain name, by ensuring that lookups of a particular name (eg: `example.org` always end up with the IP address for your laptop). Again, this is very limiting, as you won't have any communication except for with devices directly in your network.

'faking' domain names can be done in a couple of different ways: running a local lookup service, modifying /etc/hosts/ files (and the Windows equivalent that I always forget the location of) on each device, or maybe using something like DynDNS (do they still exist?)

Zash, And that would be a violation of RFC 6120 and RFC 4422§3.6.

Max: to give an example of "rewriting the whole server storage" jonas mentioned, a user's contact list will contain entries like alice@1.2.3.4 and bob@1.2.3.4, message archive (if you need that server-side) and offline messages will also be adressed at such IP-based JIDs, etc. It's possible to rewrite all of that when the IP addr chganges, but I don't know if there's any tooling that would allow doing that seamlessly. It's practically a database migration to a new domain, which, I believe, is only partially covered by MattJ's tools

Thanks all for the feedback! 🙂 I see that it's not that easy to use an IP address directly, though I'm tempted to at least try it once. I'm kind of reluctant to register a domain, because that makes me dependet from someone I don't know/trust.

Hmmm, yea, if a client allows specifying the connection address (some do), you could use an a priori nonexistent domain for user JIDs

Who hasn't used xmpp:me@localhost for testing at some point?

But having even just a gratis domain from some dynamic DNS provider is much less hacky and hard

Zash: I imagine that would be more like me@real.domain.tld but connect to localhost :)

for local testing, using the hostname of the computer that runs the server as the XMPP domain name often 'works'. Kinda.

Max, but can't you say the same about that IP address as about a domain registrar?

You don't own the IP, your ISP does.

(Not in a LAN)

Having a name actually allows clients to verify where to they're connecting

(PKI)

mjk, Well, mumble mumble about typically available PKIX.

mjk, I mean, run your own CA and use IPAddress SANs, right?

dwd, https://1.1.1.1 suggests that you can get IPaddress SANs from somewhere ... at least if you're Cloudflare

Also something something DANE

That's probably all a lot more than what Max is shooting for, with simply trying things out.

Guus, Hush with your pragmatism and sensible comments.

mjk, Most CAs don't offer them. (Or, more accurately, most CAs won't validate them).

> I mean, run your own CA and use IPAddress SANs, right? Sure, if the ca allows IPs as SANs, then same difference :) Is it CA/B that forbids that, btw? ✏

At least not Let's Encrypt, I assume

> Error creating new order :: Cannot issue for \"<my IP>\": The ACME server can not issue a certificate for an IP address

Max, any specific reason you want to use XMPP for this?

Maybe things like retroshare might be more appropriate? (or other p2p solutions?) Not entirely sure what you're looking for though

Zash, you're right, I don't own the IP address, though I feel less dependent on someone else when I can just look up my external IP address and pass it to my friends. My ISP could change the address everyday, I wouldn't really care. I might have a strange point of view, but my knowledge about how the internet works is very limited (I don't really get why TLS or certificates are so important. Shame on me). pep, Mumble is awesome for VoIP, but it lacks some chat features. It would be cool to have an XMPP server running alongside the Mumble server, that's all. Maybe XMPP is overkill for this use case, I don't know...

I wonder if IRC is much more tolerant to "IP hosting" ✏

In the 80s perhaps...

I'll have a look at RetroShare or P2P in general, sounds like a good idea!

Surely even IRC requires TLS these days?

:shrug:

Max: to throw some more p2p names your way: Tox, Jami

Max: pragmatically: just install one of the servers and see how far you get. You've probably spent more time talking to us here than what it'd take to setup a quick test server.

Heh, ever so slowly IRC follows XMPP https://github.com/ircv3/ircv3-specifications/pull/483 😀

As long as you keep a throw-away mindset, you can do little harm.

> Error creating new order :: Cannot issue for \"<my IP>\": The ACME server can not issue a certificate for an IP address It's a conspiracy to make us buy names!11

Well, I think IRC compared to Mumble chat doesn't make a noticable difference, feature wise. mjk, thanks for the suggestions! Zash, will do, thanks! 😃

Will do what?

(you're unwittingly stealing my thunder, I think)

Tab completion, how does it work?!

or in case of new users: Tab completion, does that work?!

And no movement on sRVName certs either? Sadness

afk lunch

Zash, sorry, I meant Guus (trying to host instead of talking about it).

🙂

Max, But keep us posted with what you try.

I will, I probably need help here and there. I'll try on the weekend, then I'll have more time to focus on it. 🙂

Zash: https://github.com/search?q=org%3Aircv3+scram&type=code ;)

@board: I'm abroad for work and will not be able to attend today's meeting.

Morning

Are we having a board meeting this morning?

Well MattJ, jcbrand, are you ?

It doesn't look like it. I think at this point we've failed to meet so many times so far this year that we kind of expect the meeting to fail

How does one use PEP in 1:1 to be the source of truth for a feature. What node should the data go in? More specifically, which of the two accounts, and how does a new client knows which account to check/which is the source of truth. Or is it better to just not use PEP in this case

In MUC it's easier (or would be if it were deployed everywhere?), there's an obvious node (the MUC)

(Is this why some choose to do 1:1 in groupchats as well?)

For anyone interested in (intra-)xmpp data portability, there's a googlerrific blob of java called Data Transfer Project, that's supposed to perform cross-multinational data transfer through a common data format, which might be interesting for importing tweets 'n' hangouts 'n' stuff as xmpp micro-/macroblogging posts, mam history, etc. Here's, for example, the code importing posts into a Mastodon account: https://github.com/google/data-transfer-project/blob/master/extensions/data-transfer/portability-data-transfer-mastodon/src/main/java/org/datatransferproject/transfer/mastodon/social/MastodonActivityImport.java ✏

The data formats seem to be here: https://github.com/google/data-transfer-project/tree/master/portability-types-common/src/main/java/org/datatransferproject/types/common/models

Is there any "common ways to do X" guide anywhere, that is not feature but building blocks for features, such as the question I asked above re PEP.

I'm thinking it's either that or I use MAM to do negociation and there's a significant chance the other side doesn't see it because they fetched too little. And I'm not entirely sure I want iq either for this. I'd need to iq every single device of the recipient right? each time I see a new one that is

I don't understand the question about PEP tbh, pep..

which two accounts even?

In a 1:1 chat

but truth of what?

Of some random feature that would be used in this chat. I can go into specifics but I'm not sure that's required? Also I would like the answer to this question if there is one anyway, before anyone tells me "for this use Y rather" (and never know how to use PEP this way)

Say there's a value that is to be used by both parties in the chat, and the value needs to be usable by all devices taking part in the chat, even those not present when it was agreed upon

all pep things I know "describe" the account

so I know of nothing where they'd need to find a common ground

> Say there's a value that is to be used by both parties in the chat, and the value needs to be usable by all devices taking part in the chat, even those not present when it was agreed upon sounds tricky especially because that value could change in the meantime and you don't have access to historic values for PEP in general

Ok, so anything else I can use to do this? Without having to re-negociate with each device

you could write down something like "take the minimum" if it is orderablee

but that's still going to have problems over time if the value is changed on either side

Yeah the value changing is fine here

I do need multiple values over time..

🤷

It's doable with PEP, but is it what one would use

PEP doesn't have to be only 1 item

That is something very interesting https://blog.documentfoundation.org/blog/2022/01/27/bug-bounties-finding-and-fixing-security-holes-with-european-commission-funds/

pep.: negotiating a timeout value for ephemeral messages comes to mind: https://xmpp.org/extensions/inbox/ephemeral-messages.html I didn't read the how, but it seems to be specified

Yeah that's actually what I'm thinking about changing.

The thing with MAM as I said is that there's a high chance somebody misses the negociation if they don't fetch enough

This protoXEP though adds a tag in each element which gives more chance for other devices to see it. I'm wondering if this is required

> Yeah that's actually what I'm thinking about changing. Oops, I spoiled The Reveal

> in each element In each <message> you mean? (Sorry, the protoxep was tl;dr)

Yeah in each message

In a weird way also, but I want to change that

Hmmyeah, putting the last value into pep instead seems saner

It's not jus the last value you want, it's every single value change and the corresponding message id (hoping they're all in order)

Once the timer is changed, following message will take this new value. Older messages keep the old timer value

But well, I've asked 4-5 people today and all I got was different requirements. So there's work to be done here first

the corresponding message id?

how would that work with multiple parallel 1:1 chats going on, with different people?

"from there onwards use this timer". I mean that's how I thought about doing it with PEP, if I used PEP

Different timer

so one pep node per contact?

or item

yeah per contact

how would a contact find its node?

That was my question

Don't steal it

H(bare JID) ?

but contact enumeration

(I have 3 lines of context)

What are we talking about?

Should I check on my account first, or the contact account?

... what?

jonas’, well who's going to hold that value

... both?

So duplicate the data?

I don't know and am too sleepy to care

Both?

H( sort([ H(me), H(you) ]) )

Zash, still contact enumeration? :P

Zash: did you say: incentivize people to choose jid such that H(jid) small?

pep.: isn't it duplicated by design? Each user has a preferred value, and some consensus then computed

mjk, no, the last one sent out wins

Also, plz don't invent more schemes where you create tons of nodes. Our users complain enough about the OMEMO nodes.

IMO

Zash, well find me a reliable way to do this

pep.: but there's no global authority on the message ordering, unless it's a muc

Is putting one more tag in message just fine?

How many tags can we put in message until it becomes too much

Reliable way to do X: Don't do X. Can't fail if you don't try!

:)

Also: (doing) nothing is faster ✏

Let's not send messages

Sleep on it, let your subconscious solve the problem!

Sure. I'll tell it Zash told it to do that

The Z in Zash is for 💤️

pep.: wouldn't it suffice to only attach the tag to an ephemeral message, and store that value in pep, together with the same timestamp as that message?

Well if I add the tag in each message I don't need PEP anymore

I can put the current timer value in it

No, not each, only the ephemeral ones

Sure

You concers seems to have been that the value might get lost in mam

The pingfs approach? Store it all in in-transit messages in the network?

So duplicate it in pep

mjk, when one side initiates it

Anyway, my brain is sleepy half the day and I'm missing half the context

The other needs to see it's been initiated. That is, if we only say "from now on we do ephemeral message with timer t", and not each time "I'm an ephemeral message with timer t"

I actually don't see the harm in sending it with every ephemeral message, those aren't the majority of traffic, I s'pose