XSF Discussion - 2023-06-15

In a server-to-server context where both have dialback enabled, both require encryption, if the receiving server sends a valid certificate and the initiating server responds with an invalid certificate, should the connection be allowed to go ahead encrypted via TLS but authenticated via dialback?

That's up to you

If you're willing to use dialback for authentication, and it succeeds, why would you do anything different? ✏

https://datatracker.ietf.org/doc/html/rfc6120#section-13.7.2 specifies: > If any of those validation attempts fail, the validating entity MUST unilaterally terminate the session.

It is likely OK for the initiating server to 'start over', this time not providing the invalid TLS certificate, taking SASL EXTERNAL off the table - but I was wondering if it would be permissible to allow Dialback on a pre-existing connection on which SASL EXTERNAL has already failed because of the invalid certificate.

Guus, does openfire implement occupant-id (https://xmpp.org/extensions/xep-0421.html) ?

Guus, that section is about how to authenticate a connection using TLS

If you're happy to not authenticate using TLS, you're already not following the RFC

or depending on your perspective, you're following it but you just don't consider invalid certificates as invalid :)

(but not sufficient to authenticate, either)

lovetox: Openfire does currently not support XEP-0421

Out with Dialback! In with SASL EXTRRNAL and BIDI!

MattJ: thanks. I'm wondering if there is some (maybe implicit) security issue with using a TLS session in which a 'client' cert has been provided, but is not being used.

No more than there is an implicit security issue with using unencrypted connections

MattJ: the connection would still be encrypted though?

it's just not _authenticated_ through TLS, right?

Yes

I'm saying that's better than e.g. dialback over unencrypted connections, which would be the alternative

I'm not sure if that's the only alternative. There's something to be said for a 'kill the connection, let the initiator try again without providing a client cert'. Thus forcing encryption, using dialback for authentication.

I'm not sure what there is to be said for that flow, actually

You'd not have a connection on which a TLS certificate was provided that you have judged to be 'insufficient for auth'.

Which is arguably more in line with section 13.7.2.

I'm pretty sure if you implement it that way, nobody will ever be able to connect to you

Because servers just always provide certificates

given that no server implements that 'try again without client cert' routine?

That is probably a very valid point.

(I could start a trend though ;) )

How would they even know, if you just terminate the connection?

They'd not, I guess. Blindly retrying with TLS but without a certificate, and eventually without TLS and only dialback?

it's messy and verbose.

(and should all be very much based on configuration that defines acceptability of having dialback and/or non-encrypted connections)

This sounds messy

(Thanks for the ticket, lovetox - sadly, I can't make promises on the turn-around time)

That's what I was leading with, Zash :)

but connectivity > messy ?

Guus, no worries, we play the long game with xmpp, but if there is no issue, chances are even lower of someone doing something :)

absolutely. Also, we have clients/customers that occasionally go through our issue tracker and ask us to 'fix that'. So having a ticket is a good start.

(paid work tends to get done quicker than unpaid work)

does anyone know whats the usage state of https://xmpp.org/extensions/xep-0258.html Is this something worth keeping/implementing in clients like Gajim? We currently support it, but i tend to remove it. Its hard to test, because not supported by some servers, and its hard to find users who want to use this in a serious manner and not just to play around.

lovetox: The one who need it can definitely pay :)

We use 258 extensively, but I don't think removing it from a typical consumer client is at all daft - it's pretty niche.

I wonder to what extend developers make use of typical consumer clients that happen to support it, to test their 258 implementions - but hey, you'll probably hear them complain soon enough :)

its tempting because its pretty easy to implement, you simply display the labels you get on the message, and let the user attach one when sending

but yeah, maintaining this without real use feedback is pretty mäh

im sure someone complains if i remove it :/

Guaranteed

Every change breaks _someones_ workflow!

... but somehow it feels like people are explicitly targeting mine. ;)

https://jabbers.one:5281/file_share/Sv0PUaqDSlGvUgjJy4V633q4/20230615_163850231_bfc5..jpg

Goodies <3

Yes, not just for that, but also for the upcoming sprint: https://wiki.xmpp.org/web/Sprints/2023-06_Elbe-Sprint_Hamburg Please sign up uf you are interested to join

I worked on a project for a customer a couple of years back where we added 258 support to Converse. They refused to permit it to be contributed to the project, instead preferring a fork. I'd wager that many orgs that like 258 also like private forks :(

What the opinion on add reactions to your own messages

The XEP says nothing on this

sounds stupid to me, but who knows maybe someone has a use for this

I don't see why not

because its stupid :D

Has that ever stopped users from doing something? :P

the reaction XEP doesnt even limit the amount of Reactions you can give, if self reactions are allowed, i could give my own messages 100 thumbsup

So lets do sensible clients

true, one can simply ignore that in the client

though not allowing self reactions, would enable us to use the stanza-id as reference, which would be nicer

looking at our gitlab I see many people reacting to their own issues :D

..to no avail :)

Reactions on own message are normal, especially for voting situations

I frequently use reactions on my own messages in other IM solutions

ok, why not ..

Probably same with replies ;)