-
moparisthebest
It's not used, because it's impossible to upgrade hashes
-
moparisthebest
The only people that could move to new scram are already using plain and for a reason
-
emus
It does not mean its okay to do so in other repositories...
-
Guus
Does anyone have experience with device binding?
-
flow
Guus, device binding?
-
Guus
allowing an account to be used by authorized devices only.
-
mjk
Like, authenticate with a cert?
-
Guus
I'm unsure what implementation is appropriate (which is why I'm asking).
-
mjk
Well, forcing certificate-based auth for an account and whitelisting a list of certs would be one way, I guess
-
mjk
One device = one cert
-
mjk
Or copy the key over every authorized device. Less secure, obviously :)
-
mjk
Don't have any expirience though, even client-side. Conversations is one of the clients supporting cert login
-
dwd
Guus, Do you mean "device" or "client" here?
-
Guus
dwd: device
-
Guus
(separately, 'client' make/model/version would be interesting too)
-
dwd
Guus, OK. Can this be *any* device? As in, BOYD phones can be authorised devices?
-
dwd
Guus, And if they uninstall and reinstall the client does this invalidate or maintain the authorisation?
-
Guus
dwd: none of this has been specified (yet).
-
Guus
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.
-
Guus
(I'm not sure if "produce own hardware" is more than "ship phone to factory to have its casing engraved", but alas)
-
jonas’
if we're really talking devices, then some TPM magic might do
-
dwd
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.
-
dwd
As jonas’ says, there's TPM on other platforms, which I know less about.
-
jonas’
isn't TPM a special implementation of an HSM?
-
dwd
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.
-
dwd
jonas’, Plus other bits I think? As I say, not really something I know much about.
-
jonas’
possibly
-
jonas’
I only looked into the API spec briefly
-
dwd
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.
-
Guus
Thanks guys.
-
dwd
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.
-
Guus
I guess that makes sense.
-
Guus
How would we verify that in a scenario that involves XMPP clients?
-
Guus
Does this boil down to your earlier attempts at multi-phase auth?
-
Guus
s/attempts at/work on/
-
MattJ
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
-
Kev
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.
-
Max
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.
-
MattJ
Hi Max, welcome to XMPP 🙂
-
Guus
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.
-
MattJ
You generally will need a domain, yes. Due to TLS, and the potential for IP changes, etc.
-
Guus
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.
-
MattJ
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
-
MattJ
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
-
MattJ
*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
-
Guus
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)
-
Guus
Also, Matt is a lot smarter than me so listen to him better. :)
-
jonas’
and (in addition to not federating) you're ready for rewriting all of your server side storage whenever you change the IP address
-
dwd
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.
-
MattJ
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
-
Guus
dwd: would that work? Doesn't that remove the distinction between 'device' and 'user' ?
-
dwd
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.
-
Guus
dwd (which would cause issues when one user wants to use two authorized devices)
-
Zash
authzid=user@host/device ?
-
dwd
Zash, Well, authzid=user@host still, and authcid=device, if you wanted to go that route.
-
Zash
Huh?
-
Max
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.
-
dwd
Zash, The authentication identifer would be the TLS certificate, and that identifies a specific device. The authorization identifer is always the Jid in XMPP.
-
Zash
I've seen things that put the full JID into ... one of those, e.g. in PLAIN
-
dwd
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
-
dwd
Zash, Whereas the authentication identifier is mechanism specific (and can be site specific).
-
Zash
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
-
MattJ
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.
-
Zash
I thought it was authzid \0 authcid \0 password
-
dwd
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.
-
dwd
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.
-
Zash
... Prosody just ignores the authzid 🙂
-
Guus
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.
-
Guus
'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?)
-
dwd
Zash, And that would be a violation of RFC 6120 and RFC 4422§3.6.
-
mjk
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
-
Max
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.
-
mjk
Hmmm, yea, if a client allows specifying the connection address (some do), you could use an a priori nonexistent domain for user JIDs
-
Zash
Who hasn't used xmpp:me@localhost for testing at some point?
-
mjk
But having even just a gratis domain from some dynamic DNS provider is much less hacky and hard
-
mjk
Zash: I imagine that would be more like me@real.domain.tld but connect to localhost :)
-
Guus
for local testing, using the hostname of the computer that runs the server as the XMPP domain name often 'works'. Kinda.
-
Zash
Max, but can't you say the same about that IP address as about a domain registrar?
-
Zash
You don't own the IP, your ISP does.
-
Guus
(Not in a LAN)
-
mjk
Having a name actually allows clients to verify where to they're connecting
-
mjk
(PKI)
-
dwd
mjk, Well, mumble mumble about typically available PKIX.
-
dwd
mjk, I mean, run your own CA and use IPAddress SANs, right?
-
Zash
dwd, https://1.1.1.1 suggests that you can get IPaddress SANs from somewhere ... at least if you're Cloudflare
-
Zash
Also something something DANE
-
Guus
That's probably all a lot more than what Max is shooting for, with simply trying things out.
-
mjk
Sure, if the ca allows IPs as SANs, then same difference :) Is it CA/B that forbids that, btw?✎ -
dwd
Guus, Hush with your pragmatism and sensible comments.
-
dwd
mjk, Most CAs don't offer them. (Or, more accurately, most CAs won't validate them).
-
mjk
> 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? ✏
-
mjk
At least not Let's Encrypt, I assume
-
Zash
> Error creating new order :: Cannot issue for \"<my IP>\": The ACME server can not issue a certificate for an IP address
-
pep.
Max, any specific reason you want to use XMPP for this?
-
pep.
Maybe things like retroshare might be more appropriate? (or other p2p solutions?) Not entirely sure what you're looking for though
-
Max
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...
-
mjk
I wonder if IRC is much more tolerant for "IP hosting"✎ -
mjk
I wonder if IRC is much more tolerant to "IP hosting" ✏
-
Zash
In the 80s perhaps...
-
Max
I'll have a look at RetroShare or P2P in general, sounds like a good idea!
-
Zash
Surely even IRC requires TLS these days?
-
mjk
:shrug:
-
mjk
Max: to throw some more p2p names your way: Tox, Jami
-
Guus
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.
-
Zash
Heh, ever so slowly IRC follows XMPP https://github.com/ircv3/ircv3-specifications/pull/483 😀
-
Guus
As long as you keep a throw-away mindset, you can do little harm.
-
mjk
> 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
-
Max
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! 😃
-
Zash
Will do what?
-
Guus
(you're unwittingly stealing my thunder, I think)
-
Zash
Tab completion, how does it work?!
-
Guus
or in case of new users: Tab completion, does that work?!
-
Zash
And no movement on sRVName certs either? Sadness
-
Guus
afk lunch
-
Max
Zash, sorry, I meant Guus (trying to host instead of talking about it).
-
Zash
🙂
-
dwd
Max, But keep us posted with what you try.
-
Max
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. 🙂
-
Neustradamus
Zash: https://github.com/search?q=org%3Aircv3+scram&type=code ;)
-
ralphm
@board: I'm abroad for work and will not be able to attend today's meeting.
-
arc
Morning
-
arc
Are we having a board meeting this morning?
-
Zash
Well MattJ, jcbrand, are you ?
-
arc
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
-
pep.
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
-
pep.
In MUC it's easier (or would be if it were deployed everywhere?), there's an obvious node (the MUC)
-
pep.
(Is this why some choose to do 1:1 in groupchats as well?)
-
mjk
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/889f1fa92fc54046b42a9448b53d9de0df84912c/extensions/data-transfer/portability-data-transfer-mastodon/src/main/java/org/datatransferproject/transfer/mastodon/social/MastodonActivityImport.java✎ -
mjk
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 ✏
-
mjk
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
-
pep.
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.
-
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
-
jonas’
I don't understand the question about PEP tbh, pep..
-
jonas’
which two accounts even?
-
pep.
In a 1:1 chat
-
jonas’
but truth of what?
-
pep.
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)
-
pep.
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
-
jonas’
all pep things I know "describe" the account
-
jonas’
so I know of nothing where they'd need to find a common ground
-
jonas’
> 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
-
pep.
Ok, so anything else I can use to do this? Without having to re-negociate with each device
-
jonas’
you could write down something like "take the minimum" if it is orderablee
-
jonas’
but that's still going to have problems over time if the value is changed on either side
-
pep.
Yeah the value changing is fine here
-
pep.
I do need multiple values over time..
-
jonas’
🤷
-
pep.
It's doable with PEP, but is it what one would use
-
pep.
PEP doesn't have to be only 1 item
-
emus
That is something very interesting https://blog.documentfoundation.org/blog/2022/01/27/bug-bounties-finding-and-fixing-security-holes-with-european-commission-funds/
-
mjk
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
-
pep.
Yeah that's actually what I'm thinking about changing.
-
pep.
The thing with MAM as I said is that there's a high chance somebody misses the negociation if they don't fetch enough
-
pep.
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
-
mjk
> Yeah that's actually what I'm thinking about changing. Oops, I spoiled The Reveal
-
mjk
> in each element In each <message> you mean? (Sorry, the protoxep was tl;dr)
-
pep.
Yeah in each message
-
pep.
In a weird way also, but I want to change that
-
mjk
Hmmyeah, putting the last value into pep instead seems saner
-
pep.
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)
-
pep.
Once the timer is changed, following message will take this new value. Older messages keep the old timer value
-
pep.
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
-
jonas’
the corresponding message id?
-
jonas’
how would that work with multiple parallel 1:1 chats going on, with different people?
-
pep.
"from there onwards use this timer". I mean that's how I thought about doing it with PEP, if I used PEP
-
pep.
Different timer
-
jonas’
so one pep node per contact?
-
jonas’
or item
-
pep.
yeah per contact
-
jonas’
how would a contact find its node?
-
pep.
That was my question
-
pep.
Don't steal it
-
Zash
H(bare JID) ?
-
jonas’
but contact enumeration
-
Zash
(I have 3 lines of context)
-
Zash
What are we talking about?
-
pep.
Should I check on my account first, or the contact account?
-
jonas’
... what?
-
pep.
jonas’, well who's going to hold that value
-
jonas’
... both?
-
pep.
So duplicate the data?
-
jonas’
I don't know and am too sleepy to care
-
mjk
Both?
-
Zash
H( sort([ H(me), H(you) ]) )
-
pep.
Zash, still contact enumeration? :P
-
jonas’
Zash: did you say: incentivize people to choose jid such that H(jid) small?
-
mjk
pep.: isn't it duplicated by design? Each user has a preferred value, and some consensus then computed
-
pep.
mjk, no, the last one sent out wins
-
Zash
Also, plz don't invent more schemes where you create tons of nodes. Our users complain enough about the OMEMO nodes.
-
pep.
IMO
-
pep.
Zash, well find me a reliable way to do this
-
mjk
pep.: but there's no global authority on the message ordering, unless it's a muc
-
pep.
Is putting one more tag in message just fine?
-
pep.
How many tags can we put in message until it becomes too much
-
Zash
Reliable way to do X: Don't do X. Can't fail if you don't try!
-
pep.
:)
-
mjk
Also: doing nothing is faster✎ -
mjk
Also: (doing) nothing is faster ✏
-
pep.
Let's not send messages
-
Zash
Sleep on it, let your subconscious solve the problem!
-
pep.
Sure. I'll tell it Zash told it to do that
-
Zash
The Z in Zash is for 💤️
-
mjk
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?
-
pep.
Well if I add the tag in each message I don't need PEP anymore
-
pep.
I can put the current timer value in it
-
mjk
No, not each, only the ephemeral ones
-
pep.
Sure
-
mjk
You concers seems to have been that the value might get lost in mam
-
Zash
The pingfs approach? Store it all in in-transit messages in the network?
-
mjk
So duplicate it in pep
-
pep.
mjk, when one side initiates it
-
mjk
Anyway, my brain is sleepy half the day and I'm missing half the context
-
pep.
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"
-
mjk
I actually don't see the harm in sending it with every ephemeral message, those aren't the majority of traffic, I s'pose