XSF Discussion - 2018-01-12

> going by this page: http://search.wensley.org.uk/chat/ > do rooms about clients count? :) > if not, IT-MSE probbaly counts, whatever that is > GNU/Linux is second (30) This is sad :(

OTOH, I would probably bridge my room to IRC if is I had a room here for some random project

moparisthebest, now I can refer to your article! :D https://github.com/processone/ejabberd/blob/master/ejabberd.yml.example#L191

https://nl.movim.eu/?blog/arie@movim.eu/0d590c16-75f9-4683-835b-c4003dcebc44

yeah

I also wonder why Signal is considered more secure than Whatsapp?

same proprietary silo

hm no?

signal isn’t controled by facebook

and?

and iirc the server can do less things in signal

like requesting private key?

Signal is controlled by moxie, who used to be an anarchist crypto nerd before he got bought.

so this is a question of trust? which is very personal

for example, why would I trust moxie?

don't

but we all know the position of moxie on federation/decentralisation

Ge0rG: are anarchist crypto nerds those assassination market people?

All pretty legit and trustworthy

daniel: I'm pretty sure there are different sub-groups.

edhelas, "all"? I knew about moxie from this conference (or conversations@, don't remember), I know jack shit about moxie actually 🙂

Holger zinid should we clarify 0060 for this one ? https://github.com/processone/ejabberd/issues/2129

edhelas, I'm no pubsub expert, sorry, I barely can understand the problem

Yes this should be clarified if you ask me.

I don't see what there is to clarify

Someone might think that deleting their account allows their pubsub nodes to be modified by others?

MattJ: Both you and me have write access to a node. Does that mean you can override items published by me?

MattJ: That's not clear (to me) from reading 0060. See that issue.

Ok, I see

It didn't see clear to me that that's what the issue was about

Item ownership?

Opens a can of worms

there is a similar problem with MUCs (if I understand it correctly): account deletion doesn't trigger deletion of ownership in remote MUCs

so you can re-register the account and become an owner 😉

Yeah. Or just become member of a members-only group.

Now I can't delete accounts any more? I need to convert them all into tombstones?

Ge0rG, welcome to federation

a client probably needs to clean up everything carefully, but that's PITA

zinid: you can't have a client clean up everything if you ban a user.

That's not always feasible

Also not all clients of a user know their remote MUC ownerships

More or less you can never delete accounts safely in XMPP, you must always tombstone.

At least for federated systems you don't control.

yeah, so just don't delete your account 🙂

Anyway those are separate problems. The user who created that ejabberd issue is indeed fighting with deleted accounts (and I see the problem), but he stumbled over that PubSub question which is just as unclear if the accounts in question still exist.

however, server admins can do that 🙂

I clearly see the use case for giving multiple JIDs write access to a node without allowing them to delete/override each others items. So if 0060 doesn't make this possible that's bad.

I think this should be the default behavior, just needs some clarification.

Holger: you mean publish-only?

If there's also a use case for allowing to delete/override each others items then 0060 needs additional magic.

Although that precludes reading items.

intosi: You're always able to edit/delete items you published yourself.

(Which can also be a problem.)

This is just about messing with stuff published by others.

That sounds like an Enterprise Feature.

I think people like goffi and edhelas are having a hard time trying to use 0060 for very basic features ...

just a bit :-)

It's because XEP-0060 is too generic

Which means for most practical applications, it doesn't suffice, or has to be made more complex

It lacks proper turning completeness though…

Small change to the notification transformation settings so you can make it send iq stanzas, and then do pubsub that way

> And federation is possible over XMPP with Signal: https://signal.org/blog/the-ecosystem-is-moving/ Heh. I'm pretty sure that link conveys the absolute opposite of the stated message.

Wait what

From https://news.ycombinator.com/item?id=16127570

XMPP over Signal?? Why would you even

I by the love how their method for 'private contact discovery' is basically we just send everything to an Intel black box because Intel knows their shit, right

But that's unrelated to random guy on HN not knowing the fuck he is talking about

Yeah.

Recently I had some time on my hands and read through moxie's old stories, about train riding through the US and home squatting. And that's so absolutely different from the "stop calling your product like our product" moxie, it's hard to grasp

The ones under https://moxie.org/stories.html

"This is your brain. This is your brain on capitalism."

Isn't there one where he was almost raped while hitch hiking or something?

I think I read those stories some years ago as well

daniel: yeah, and he almost died while sailing. And some others.

zinid: ah excellent (about ejabberd config pointer)

On a related note, does ejabberd TLS support SNI for cert selection?

moparisthebest: Sure, zinid added that ages ago.

(Last month IIRC.)

Nice

Model changes :/

SNI is shockingly absent outside https it seems, I had to add it to 2 IRC clients and K-9 mail on Android when I started this whole multiplexing business

It's been around for what 14 years at this point?

Does anything but HTTPS actually need it?

IRC has no STARTTLS I guess :-)

But yes mail doesn't need it.

For weird reasons tho

everything that uses TLS really

imap and smtp over TLS need it

not STARTTLS, but TLS that is

the funny thing is, as IPv4 gets harder and harder to get, SNI will become more and more needed by everything

and then as IPv4 is replaced by IPv6, SNI will no longer be needed at all essentially 🙂

moparisthebest: Sure if you don't use the alternative solution available for email, then you need it :-)

starttls should just die everywhere

nooooooo

I think there is even such an RFC for all the email protocols right?

Pretty sure all email protocols have starttls

Pretty sure I've never seen SMTP over TLS

all of them have starttls options and direct-tls options, and an old RFC deprecated direct-tls, and a new one I think re-instates it and deprecates starttls

over port 465 is the standard for that Zash

for client submission port over direct tls

Never seen or heard about anyone ever using that

yea the standard smtp ports are 25 (for s2s you could say), 587 for submission (starttls), and 465 for smtps (direct tls), 465 pre-dated 587 and then was deprecated and assigned to some protocol no one uses...

Zash: We've been offering SMTPS and IMAPS next to STARTTLS for ages and I've seen many other providers doing so.

found it https://datatracker.ietf.org/doc/draft-ietf-uta-email-deep/

Cleartext Considered Obsolete: Use of TLS for Email Submission and Access

ie starttls must die

on an XMPP related note, they chose the terminology 'Implicit TLS' vs what we chose of 'Direct TLS' so it might make sense to update 368 that way

yay, finally got a vacation to attend the summit

ha they chose _submissions._tcp vs my initial preference of _submission._tls too

Anyone seen stpeter recently?

moparisthebest: is the last "s" for "secure" or for plural?

same as xmpps, secure

or ssl ? 😛

ss-what?

it's not like anyone is going to change https to httpt

did you mean: htttp? :P

htls://

hpkp:// where every site has a pinned public key? now that's something I could get behind

ipfs?

moparisthebest: and the host part is replaced by the key fingerprint. key fingerprint dot onion.

more like cjdns

“17:33:12 moparisthebest> Cleartext Considered Obsolete: Use of TLS for Email Submission and Access 17:33:20 moparisthebest> ie starttls must die”, you’ve said that a few times already, but that’s plain wrong, there is nothing more plaintext in StartTLS than in legacy TLS in XMPP.

Link Mauve: but then why keep it

Because a huge lot of software and deployments support it, and because there is no downside.

There is a downside to the change though.

Changing security stuff for what amounts to a small round trip optimization is kinda scary.

And the thing about getting through firewalls will just further that arms race

Way more software supports direct TLS

More popular != better

But in this case it does

moparisthebest, I just had a look at our server, we have a 1:10 ratio of users of legacy TLS vs. StartTLS.

Link Mauve: do you have xep368 DNS records, and what preference order

Yes, and same as the normal one.

Wait same? What is the weight of each then

Ah no, 8 0 for _xmpp-client and 10 0 for _xmpps-client.

I remembered wrong.

Ah ok well that's why then

You can dig _xmpps?-client._tcp.jabberfr.org.

You should test with them switched

But why? I thought the only reason to have those was to bypass firewalls that intercept the plain text version and only allow TLS-looking ones.

If a client fails to connect in StartTLS, but supports legacy TLS, it will just check again once the connection failed.

I thought the primary reason was to get through corporate firewalls that only allow http/https

Yeah.

That’s the only reason we have legacy TLS in the first place.

We also have XEP-0156 deployed, which is another big one for those.

Isn't 368 way easier and more efficient than 156

If getting around firewalls is your goal that is

Until your firewall starts blocking anything which doesn’t announce it is HTTP.

Bottom line though if xmpp was being designed today do you doubt it would only support direct TLS?

Because 0156 describes how to use this very HTTP everyone loves so much.

Weren't you the one who said "we'll still have websockets"?

moparisthebest, that doesn’t matter, it has been invented twenty years ago, you can’t erase that.

But you can move towards the ideal situation

It’s not more ideal than the rest.

If you are redesigning other parts might as well improve it all

I don't see how moving host and service multiplexing around the layers is an improvement.

Link Mauve: wait you said 10% of your users are using the xep368 srv record? That seems huge if it's a lower priority

Link Mauve: Is it set up so you can detect connections that ignored or failed to get SRV records?

Like yax.im is, iirc.

Zash, yes.

And, iirc, also produces depressing numbers.

Like how 90% of all users on a thing I used to run were using DIGEST-MD5 and the rest were using PLAIN

That seems like a huge number of users that otherwise wouldn't be able to connect

so looks like Movim is having a "okay" working solution to do video-conferencing with pure WebRTC and Jingle :)

Also considering only a couple clients support it

moparisthebest, or plain ignore the settings and connect to 5223 anyway.

or got SRV sorting wrong

edhelas, did you try out cross-browser?

Conversations does it right mixing and all, it would connect to 5222 if it could

yup, working between chrome and firefox

disabled on mobile for now

edhelas: would be great to get interop working with conversations too :)

ping daniel :3

edhelas: what about safari? (I worked with WebRTC for another project and it sucks to get it cross-browser)

Did that xep work as is or did you find rough edges?

I don't know if there's a WebRTC implementation in Java for Android

la|r|ma don't know, don't have Macs at home :D

you can use chromes libwebrtc on android

edhelas: actually a conversations fork has webrtc support

moparisthebest well I basically had everything in the XEPs to do the conversion between SDP and Jingle

Just signaling doesn't use xmpp

https://github.com/movim/movim/blob/master/lib/SDPtoJingle.php

So take some code from there, implement signaling part with jingle, done

moparisthebest, which fork?

la|r|ma: uuuhhhhh author responded in that issue

Spreedbox or something?

edhelas, I’d really like to interoperate between the desktop and the web, I just sent an email to the Jitsi guys about that.

sure, would love to try interroperability with Jitsi, and why not Dino one day :)

moparisthebest I've also anotated the XEP numbers in the file :)

I build a PoC for Jingle with Dino half a year back (only basic unencrypted audio via ice-udp)

I'm really impatient to show all those nice features interroperable between Dino, Conversations, Movim and others :)

SàT also for the social part

Would that part of movim work with prosody?

eheh, nothing relies on the servers :D

it's a pure client implementation

well I still have to implement TURN/STUN if the XMPP server offers it

edhelas: will I meant movim in general

not yet

still waiting for proper pubsub support

I know it needs pep stuff prosody doesn't have yet

But does plain chat and that webrtc stuff work

yup

I'll have to try it :)