jdev - 2022-07-27

is a type error presence, always generated as a response? Meaning is there a situation where the server would route a error presence to my client, without the client first sending out some presence?

You might get error responses from your contacts after sending initial presence, which is somewhat similar

Specifically, in this case you might receive multiple errors in response to a single presence

I suspect that *may* also happen in some circumstances the event that another client on your account comes online and triggers presence probes

Now that leaves me with the problem of what happens when someone does recycle an old JID.

Would it be useful to have some kind of unique (opaque) registration identifier to distinguish between two uses of the same JID?

Something like an UUID that is associated with a JID for the lifetime of the account. When a JID gets recycled a new UUID is associated with it.

Then other services can query for the UUID to establish whether it is the same registration.

I think the basic solution is 'never allow re-use'.

I think that's for the best. Otherwise every single slot where we currently have a JID, we would need to replace with JID and UUID

Kev: It's one solution, but not always feasible. For instance because of a catastrophic server failure with loss of data or even GDPR considerations.

Even sending a message. What if you send a message to someone, and it was delayed for a few minutes, but they deleted their account and somebody recreated it?

The logical conclusion is to replace JIDs with UUIDs :)

MattJ: I was thinking more of an as-needed approach, where the onus is on the receiving entity to validate, if they want to, that they're dealing with the same registration.

But more feasible would be: treat usernames as human-readable UUIDs

that problem is fun, if you have a UUID you can also move servers

For instance, via a disco#info query returning the UUID.

if you disallow reuse you might have users that you cannot use for *some* instances because they know your hostname and users that used to be on it, but can use it for other instances that don't know about it... might be a problem if you get a dns name that had a previous owner beforehand

Sure. For Snikket I disallow hostname reuse for this reason, too.

Of course, it doesn't cover the case where someone recycles JIDs mid-conversation. ☺

i'm enviromentally friendly, reuse before recycling! :D better to steal the account mid-conversation

nephele: I wasn't considering active attacks. If that is a concern, then you'd want to be using encryption.

well, the dns entry expiring and beeing re-registered mid conversation seems quite unlikely to me?

It's an extreme example of course, but certainly I could send a delayed reply to someone whose domain expires and was reregistered by someone else

I mean, what exactly would a UUID *reasonably* protect against that a JID does not? if it does not have any crpytographic gurantees it could also be recycled mid conversation

say, if a caching entity is not told that it was recycled and maintains a wrong association of jid<->uuid

Actually, I wonder if using encryption would be a viable approach. In theory that would allow both endpoints to authenticate each other.

nephele: Yes, good point.

nav, you mean like SASL EXTERNAL, which validates against TLS certificates? :p

I personally like the aproach of "your public key *is* your adress"

i am not sure if that is viable, but it would be quite neat ;)

Link Mauve: Possibly, but how do you get say your external component to ask the user connecting to it to authenticate himself that way?

nephele: Yeah PKA makes sense.

I'll need to have a read of the relevant XEPs see how much hassle it is to implement something like OX on something like a component.

Bit of a problem. Encryption support appears to be largely limited to message stanzas but not IQ or commands.

It's not encryption per se that I'm concerned about but a way of verifying that you're dealing with the same identity you were dealing with at some unspecified point back in time. Maybe signed presence stanzas will fill the gap.

nav, that was a thing in XEP-0027 fyi.

Link Mauve: Presence signing?

Yes.

Yup, at least Blabber supports it.

Kind of out of the box if you've configured an OpenPGP key for the account.

Which is nice because that means the component is getting the signed message essentially for free.

If the component can be bothered to discover the user's public keys and cache them, then a change in the advertised fingerprints may mean that the user could be someone else (or has replaced his keys). That the advertised fingerprints are valid can be checked by verifying the signed presence message.

And in principle, this can be done transparently and in a way that's compatible with no OpenPGP use. ☺

nav: i am not confinced that presence signing is a good idea

message signing, of course, but presence probably not

for starters, presence signing probably significantly increases the time your OpenPGP signing key is unencrypted

flow: The same consideration applies whether you're signing and/or encrypting messages as it does to presence. In any case, at least Blabber automatically signs presence stanzas if you have a PGP key associated with your account.

nav, the thing is, sending a message is a conscious action, whereas presences are mostly send without the user being aware

granted, the problem was more severe in the days where whe shove everything into presence, like "the current song you are listening to"

XEP-0027 signed presences are *huge* and get broadcast to all your contacts every now and then

Doesn't feel efficient

in those situations, your pgp key practically never got re-locked, and it always stayed unlocked, which wouldn't be the case if only messages are signed

Zash, I think that modern cipher woulds produce smaller signed presences

XMPP is hardly efficient to start with. As for presence stanzas, they're not being sent all the time but only when your presence status changes.

OpenPGP?

Zash: ?

nav, depending on the used extension protocols, your presence status changes quite often

flow: For instance?

auto-away etc

xep256

but shoving stuff into presence is now largely considered an anti-pattern, rightfully, if I may add ✏

flow: Why would 0256 increase the rate at which <presence/> is being sent?

flow, XEP-0319 too!

It's, as you say, just adding some more stuff into it.

Conversations for example has a feature where it sends presence every time you focus or unfocus it.

Disabled by default IIRC

In any case, it was agreed in the XMPP community long long ago not to shove so much stuff in presence, instead use PEP

XEP-0319 is a better example, but as long as it's under control of the user I still don't see the problem

xep256 isn't the best example, but it was the best I could dig up in short time

Yup, PEP is a good idea.

nav, but as I wrote, we had previously XEPs that put the last user tune in presence

OX!

so every 3 minutes or so, you would emit a new presence

furthermore presence gets amplified by MUCs

imagine you are in 3 MUCs with the same people

flow: Yeah, I remember that fad!

every time someone emits a new presence, you get it 4 times

(assuming you are also subscribed to the presence0

and finally, I am not sure what a signed presence gets you

I think it might vary a bit actually, some clients don't send presence updates to MUC

like what do you do with that information?

how would you behave if it wasn't signed

how do you behave differently if it was signed?

Zash, hmm isn't the server doing that?

but you are the expert on that topic :)

Prosody doesn't. Maybe it should? But you get problems.

I assumed that MUC presence is based on RFC 6121 § 4.6 Directed Presence

Like, it gets weird if you change nickname. Should the server broadcast your presence to both nicks?

flow: "how do you behave differently if it was signed?" Well, that's what I was getting at. I could make certain assumptions as to whether the JID is under control of the same user.

nav, your phone gets stolen. now what?

nav, I am not sure if this answers my question

could you give a concrete example?

don't get me wrong, 20 years ago I also believed that signed presence is cool

but today, I see only drawbacks and no advantages of presence signing

flow: See the discussion around 1130Z today for background to the discussion.

kk

and fwiw, I believe signed presences should include a timestamp, for hopefully obvious reasons

but then you need to define a time-to-live for those

1h, 3h, 24h, 7d?

It all comes from the fact that yesterday I accidentally deleted my account 🙄

in any case you now inveted a new mechanism that causes presences updates

Wasn't that one of the problems with XEP-0027, no replay protection?

nav, probably the better solution would be a signed pep item in a well-defined pep node

But the component I was testing at the time still kept all the information associated with my JID.

It dawned on me that the component will wipe out your info if you unregister with it, but not if you unregister from your own server and someone else takes over your JID.

flow: That sounds sensible.

I get that point, and I think the solution lies in PEP, not in Presence :)

you basically want to place a proof of ownership in the PEP node

My first thought was some kind of UUID but as was pointed out above that was kind of daft and then someone brought up crypo, and here we are.

Indeed that sounds like a good solution! ✔

I could get people to register a password with the component but the usability is not quite as good.

What about discovering and remembering OMEMO nodes?

if you work out a protcol with one crypto scheme it is easy to apply to the same to another crypto scheme which is able to sign bytes

On second thought, that probably would not work.

the main issue is that OMEMO, unlike OpenPGP, has no concept of a primary key

at least IIRC

Exactly

I like the signed PEP node approach. The disadvantage is that it requires explicit client support.

how could something like that *not* require explicit support from implementations?

I should have said explicit client support which is not there at the moment. ☺

Deploying new things 🤷️

That's why I was hoping to piggyback on signed <presence/> stanzas, as some clients already do those.

isn't that always the issue: that we imagine those kewl new protocol extensions, but then suddenly realize that someone needs to implement them? :)

The cool thing about the signed PEP is that it could be used by people wanting to prove control over a JID *or a group of JIDs*

open standards go brrr

For instance people who have accounts on different servers.

what's it proving? that someone with that private key at some point had access to that account and/or server ?

moparisthebest: Yup

No more and no less.

what's the intended way to use that info ?

moparisthebest: https://logs.xmpp.org/jdev/2022-07-26?p=h#2022-07-26-8255b4655df233bd

With reference to the red warning on XEP-0086 (https://xmpp.org/extensions/xep-0086.html)…

…considering that I am dealing with handling error conditions in the context of XEP-0030 (https://xmpp.org/extensions/xep-0030.html), I guess I should ignore that warning, right?

https://xmpp.org/rfcs/rfc6120.html#stanzas-error is where you should look for syntax of errors.

Thanks!

And service-unavailable is the error you must return for any iq-get or set that you do not understand.

Roger that.

Is that specified somewhere, off the top of your head?

Or just customary practice?

In the RFC I just linked

Yup, just found it, ta. https://xmpp.org/rfcs/rfc6120.html#stanzas-error-conditions-service-unavailable

10.3.3. IQ > If the IQ stanza is of type "get" or "set" and the server does not understand the namespace that qualifies the payload, the server MUST return an error to the sending entity, which MUST be <service-unavailable/>.

Cool, that makes life easier. ☺

There should also be text to the effect that every iq-get and iq-set must have a matching iq-result or iq-error

hi

how would you implement multiple nicknames in a vcard

Zash: True

the DTD says that multiple <NICKNAME> elements can exist, but multiple nicknames must be a comma-seperated list

(talking about vcard-temp)

My personal advice: Ignore vcard-temp.

All the cool kids use vcard4

how much servers do you think support vcard4

Also https://xmpp.org/extensions/xep-0172.html

All of them!

All Modern XMPP servers support PEP, and that is all you need for vcard4

Zash: i mean multiple nicknames in a vcard-temp

also the vcard4 xep is deferred

vcard-temp is Historical

aka ugly things from before there was a standards process

... but still active?

deferred just means it hasn't moved forward in the standards process for a year

if you could just please answer my question

with how slow the standards process is, one year doesn't really mean much

i'll try to send a hand-crafted vcard4 retrival request

and see if it works

all I can say is that the Prosody module handling vcard-temp simply takes the XML and saves it as-is

disroot's server errored out with "No module handling this query"

so i'm gonna assume, that this isn't as widely implemented as it might seem

now anyway, my question was

how do you implement multiple nicknames in a vcard

i'm gonna assume multiple elements

techmetx11: I've just tested and multiple elements does not work with ejabberd.

In theory, according to the DTD on XEP-0054 it should be allowed, but also the XEP does not prescribe what to do with multiple instances of the same tag. Ejabberd just keeps the last received.

The DTD does say, in a comment, that "Multiple nicknames must be specified as a comma separated list value" (I guess you've already seen that), and that is also how RFC 6350 specifies it: NICKNAME-param = "VALUE=text" / type-param / language-param / altid-param / pid-param / pref-param / any-param NICKNAME-value = text-list (https://datatracker.ietf.org/doc/html/rfc6350#section-6.2.3)

yeah

i was a bit confused