XSF Discussion - 2018-03-14

https://gultsch.de/ daniel s/in moving/is moving/

MattJ yup. But I'd also like to generalize to pretty much everything we have in XMPP

daniel: just seen that conversations enable OMEMO by default, what happens if the other client doesn't implement it?

for those of us who implement/implemented voice calls: http://oaktrust.library.tamu.edu/handle/1969.1/ETD-TAMU-2011-05-9116

jonasw: how does that compare to opus with CBR? (something the wire folks contributed back to the webrtc.org lib)?

fippo, I have no idea

someone who may work on jingle voice in jabbercat has researched that stuff

kudos to them for even thinking about timing sidechannels

(and with research I mean "looked for papers", not "written that paper")

> https://gultsch.de/ daniel s/in moving/is moving/ pep.: thanks

daniel: ^

?

[07:33][goffi] daniel: just seen that conversations enable OMEMO by default, what happens if the other client doesn't implement it?

it wont be able to decrypt the message

daniel: conversations won't send it unencrypted then?

not by default

you can of course switch to unencrypted manually

daniel: you have a warning or something obvious so people know how to do it?

nope

(unless you don't publish any keys at all)

looks like you're breaking compatibility

And keys are published by ... default ?

goffi, i'd say it impedes communication with certain clients, not really a compatiblity issue

I wonder if the situation could be improved a bit if the receiving client informs the sending that he doesn't the support the encryption mechanism, possibly based on EME

Is there a way to send outgoing messages from the bare JID to conceal the resource?

flow, well detection is not really the issue. downgrade attacks are

daniel, how do you detect it (reliable)?

flow: OMEMO is experimental, not an official standard yet. It's forcing it's use except if user change default which is not obvious to apparently. So yes it's breaking compatibility. Popular clients like Movim are not implementing it. It sounds like a terrible idea to me.

or let me repharse; we have mechanism that would allow us to detect under certain conditions; however that doesn't seem like a problem worth solving because downgrades

daniel, I can see how that way is appealing from a pragmatic pratical point of view, i'm mostly interested thinking about potential solutions how a modular/extensible federated network could deal with multiple encryption schemes with minimal interoperability issues

flow: well because of the +notify thing in the Disco features we do know if a client supports omemo

If we can access disco

Speaking from a purely technical perspective

Assuming the other one is online and has presence subscription

I was going to say that still allows a server MITM to strip that feature from disco

But then a server may also unpublish keys

MattJ, not if you always unconditional send omemo

not sure what conversation's omemo-by-default does

if you've communicated before?

MattJ, of course. that's why i'm not doing this

daniel: is there a knob to turn off omemo-by-default?

not yet. i'm still on the fence whether this is a good idea

daniel, so just to make sure I understand: If there is no such knob, I won't be able to communicate with someone using conversations if I use a client which does not support omemo?

(and you have ever published keys)

(which conversations does by default)

oh sorry. currently you can turn it off on a per conversation basis

the encryption/lock icon doesn't go away

just omemo is selected as default instead of none

daniel, if the remote has published omemo keys, or always?

there isn't a app wide button to change the default for all conversations

flow, always

what

so how do you send encrypted messages if the remote hasn’t published keys?

ahh ok, so a common flow would be that converstations send an omemo message, recipient replies "sorry, no can do", conversation user turns off omemo for that conversation

it will pop up the error dialog that it can't find keys

that flow will always be possible?

m(

> ahh ok, so a common flow would be that converstations send an omemo message, recipient replies "sorry, no can do", conversation user turns off omemo for that conversation that's how i imagine it. yes

I’m really looking forward explaining to family how to that

I think I could life with that

that class of family for whom conversations is "ohhhh, you mean that thing on my phone"

daniel: does use need to do that on each new discussion with the same user ?

user*

but on the other hand, that also allows for downgrade attacks

daniel: does user needs to do that on each new discussion with the same recipient ?

like i said; it's only about changing the defaults

not about forcing omemo

alternatively, I’ll make our MUCs non-members-only

that should do the trick too

goffi, no conversations are persistent across the life span of the app

there is no such thing as a 'new discussion'

my understanding was that omemo would only be enabled when conversations was able to discover keys for all participants, which I could agree to. but this is really, really bad.

OK, that's better than I imagined

but I'm still worried that it's not obvious to change as you said previously. And what if recipient use OX instead? I personnaly prefer OX over OMEMO

lol

lol?

we can think about that when people have implemented ox

true

I feel like I'm repeating myself. But the change is just about the default. So if previously a lot of people had to tell their contacts to _enable_ omemo for a specific conversation some other people now have to tell their contacts to disable omemo

And my argument is that outside the xmpp developer bubble a lot less people now have to ask their friends to change that

daniel, I don’t see why you would default to enabling omemo if the contact not even has keys published

The recipient may not even know that there is a message

then "you have to disable OMEMO" "How?" "I have not idea"

no*

wait. you don't implement eme? :-)

clients not implementing OMEMO may definitely not implement eme indeed (which is not more standard than OMEMO by the way).

Conversations will add a clear text body if it detects the other party has at least one client online that doesn't support omemo

i was kidding about the eme

i'm not a fan of eme

for exactly that reason

bad clients don't implement it

good clients probably have the encryption anyway

daniel: it's not a question of bad or good, it's a question of priorities, which may differs from yours.

I have not implemented eme and I'm planning to, but Pubsub and blog stuff are more important to me.

and we are not all full time devs. Thanks to avoid insulting client developers.

daniel there's no bad or good clients, Pidgin supports OMEMO, it's a good XMPP client for you ?

daniel, what is the error dialog like when there are no keys? Does give an option to disable OMEMO for that contact?

MattJ, not yet. but there will be one if you previously haven't successfully send an omemo message

That would be great

OMEMO used to be a little UX nightmare. Now it has become the doom of Conversations :>

I'm in favour of increasing security. End-to-end encryption with trivial downgrade attacks from the entity it's protecting against is... well, pointless

can't wait for Conversations to support SIMS, to make it a good client again :3

But I'm not in favour of making our lives even harder in increasing adoption of XMPP though

sims was planed for 2.0 - but it is actually a lot harder than I thought

I'm not against E2E encryption by default either, but I'm worrying about compatibility issues. And OMEMO is not a standard yet.

so it has to wait for 2.1 or 2.2

I can not implement E2EE for *ehm* Regulatory Compliance Reasons.

daniel: which OMEMO namespace is Conversations using currently?

Ge0rG, the one in the XEP :-) :-)

daniel oh, good news :)

> This specification defines the following XMPP namespaces: > - eu.siacs.conversations.axolotl Uhm. 🤦

Ge0rG all the cool kids in town have their own client name in XMPP namespaces now

But I want to be a cool kid too! Can I invent my own encryption protocol and have my name in the namespace? Like `pro.lukas.georg.doublerot13`?

hah

probably; if you start the marketing campaign and get people to implement it

I can start by adding this to all my messages: `<encryption xmlns='urn:xmpp:eme:0' namespace='pro.lukas.georg.doublerot13'/>

"rot13 undefined for emoji"

Let me tell you about my latest invention: ROT1114111

jonasw: double rot13 WFM

"but I don’t want to break abstraction by special-casing double-rot13!!!"

layers!

,oO(not sure thus is how double rot13 works)

, oO(who said it's "double")

🤣 🤣

regarding the multiplication of E2E standards in XMPP I'm proposing a new XEP to cover everyone's use case, XEP-xxxx: PLAIN over E2E

A Rot26 Ge0rG is rather boring and less Tr0eT'ling

edhelas: that's kind of compatible to double rot13

Need another XEP to bridge the two

In entirely unrelated news, I'm attending the MLS BOF next week.

Enjoy

That time of the 1/3year again?

which time?

IETF time

3 per year

Also, reading back, double-XOR is 8-bit clean, and has the useful property that it always results in valid UTF-8, if you're looking for a decent encryption algorithm. Just ensure the key is from a suitable random source.

Zash: Yes, from this weekend.

Heh, IETF 101 :D

Zash: If you miss it, the later sessions won't make any sense.

Anyone feel like drafting an XMPP variant of https://tools.ietf.org/html/draft-ietf-acme-email-tls-03 ?

Actually why is that one not SRV-generic?

Zash: that means SRV-ID? :u

Heh

I'd not seen that. And yes, but I don't know if we can persuade Let's Encrypt to support it - but I can put tendrils out next week.

pep.: Highly unlikely, not even email uses that.

dNSNames everywhere and only

> double-XOR is 8-bit clean, and has the useful property that it always results in valid UTF-8 Doesn't that depend on what you XOR with?

Ge0rG: no. If you xor it with 7-bit values, it will still be 8-bit clean :)

If you XOR with the same key twice...

Yup.

Really doesn't matter which bitsize your values are.

I could XOR it with 0x00.

Not sure if *wosh*

Ge0rG, everybody knows xor with 0x00 is unsafe!

intosi: "Doesn't that depend on what you XOR with?" -- "no. If you xor it with 7-bit values," -- so that actually means "yes"?

No.

Or, "yes, it doesn't depend on"

For varying interpretations of the words "no" and "yes."

Yes. We should stop that now before heads start exploding.

yes xor no

true

Zash: that's boring. The true fun starts at `yes XOR File_Not_Found_Exception`

XAND!

jonasw: XAND - Like an AND, but if both inputs are true then false?

Zash: Read through that email acme draft. I'll chat with Alexey about it on Saturday, and see if I can persuade him into knocking out an XMPP version.

dwd: Thanks.

FWIW, I think it ought to be doing sRVName in this instance.

is here any dino.im user? I'm trying to figure out if it worth it to add dino client detection in Psi.

dwd: I saw mention of SRV-ID in the text

dwd: I do wonder if it would be sensible to factor out some generic SRV verification

Oh, indeed.

And yes, generic sounds awfully good to me, but I suspectit's impossible without immediate/direct TLS in all cases.

"How internet-drafts multiply"

BTW, anyone know what the state of the art client for Mac is?

Monal, Swift 4.0rc6, …? :)

Movim maybe, if it has a Mac version. edhelas, does it?

Isn't it a web client?

i thought it had destkop wrappers :)

Zash, it has a linux version https://movim.eu/#apps

yeah but removed some of them recently, wasn't able to package Electron easily for Windows and Mac

wasn't able to package Electron? I thought that was its one purose, be able to package easily on desktop platforms ✏

ahah, you fool, you need a sh**load of dependencies and actually run scripts on MacOS (and I don't have a Mac) to package .dmg and stuff like that

ahh

I don't have time for that

I understand

https://www.npmjs.com/package/electron-packager

also I have a personnal issue with the JS ecosystem and NPM

but that's purely personnal

edhelas: you're not the only one

understandable, who doesn't have an issue with the JS ecosystem

Which JS ecosystem?

Kev: all of them, in varying degrees.

There can be only one!

Are there any Screenshots for swift 4.0?

I can make one but it's probably not the usual setup for most users

https://www.dropbox.com/s/bn6rpzjqhroebgk/Screenshot%202018-03-14%2010.23.40.png?dl=0

Actually, let me sort out a different one.

https://www.dropbox.com/s/ltp23stece5gd66/Screenshot%202018-03-14%2010.25.14.png?dl=0 That's got the chat window in. Roster is unchanged since 3.0 (on http://swift.im/ ) I think.

nice idea the avatar on the left

Kev: thanks. can I assume the security label stuff is hidden if the server doesn't support it? Because that's pretty confusing for anyone not working for a three letter agency

yes...it is

it doesn't show for me at least when logged into my servers account

I love how you can make a grid in Swift

Swift the IM client?

Yup

what's a grid, then?

Ge0rG, you can make a grid with your open tabs/windows. I cannot share a screenshot right now, I hope Kev or Tobias can help.

Ah, interesting. Is that something you need for a huge Cyber Threat Display?

Ge0rG, go back to work ;-)

Ge0rG: military users like to have lots of tabs, so they can monitor many chats at once, with keyword highlighting to draw attention to things they care about. I have been told of an operator with 64 rooms displayed

It's a feature I never thought I would see in an XMPP client (it feels super niche) but I love it

You need a big screen for that :D

i want a screenshot

I find it helpful. I run with a mere 2x2 grid, but it helps me wathc and participate in a few things at once

Yes, as I said, I'm all for that feature :)

just installing dropbx to share a screenshot

why would you need dropbox for that? :-O

So Swift doesn't do HTTP upload yet? :)

I nede a script which gives me an upload slot so that I can share it to folks

Ha

and a hack into mod_http_upload_external which allows admins to create arbitrary-size slots :)

jonasw: you share HTTP upload slots?

OK - so what is an easy way to share a file. Dropbox is not impressing me

Ge0rG, not yet :)

Steve Kille, imgur.com?

Ge0rG, but I find it an appealing idea in this case here

yup, imgur.com is pretty straightforward

https://www.dropbox.com/s/lb8f3elyxj1ym86/grid.bmp?dl=0

ignore that

hum, we can split screen in our desktop/android frontend, doesn't sound like same feature, but it's trivial to do 2x2 grid (64 is more tricky :-/)

goffi: buy more, bigger screens.

intosi: it's not the size, it that you split by hand (it's inspired from blender)

Ah.

goffi, windows desktop don't usually support that

https://www.dropbox.com/s/o0j7krbgtar7y6u/Screenshot%202018-03-14%2012.43.02.png?dl=0

that one works

Tobias: it's built in our client, not a desktop feature

ah..ok

neat, Steve Kille

And it's super easy to set them up too

Yes - Tobias did a great job with the UI

Dave Cridland, what was your RFC for making <session><optional/></session> again?

draft-cridland-something-something-session

https://tools.ietf.org/html/draft-cridland-xmpp-session-01

Thanks. :)

It’s now implemented in slixmpp. :)

Steve Kille, Grid is kinda nice actually

Would be a nice feature in gajim actually.

Haven't used swift but vertical tabs is much easier I find (I wish chrome supported this....)

Guus, friendly reminder regarding https://github.com/xsf/xeps/pull/579#issuecomment-367929778

Also could you please introduce a stream error specific error conditions so that the stream error receiving entity can disable stream management in subsequent connections, avoiding reconnection loops

(I'd assume that openfire would probably benefit from it ;))

*condition

wait, it's "stream management specific stream error condition"

flow, thanks, I will

(and Openfire already does, I think)