jdev - 2022-04-05

Hey there, I have some questions for anybody who can help. I'm having a really hard time figuring out how to have E2EE voice and video calls in XMPP. (If this is not the place to discuss such things, let me know, as I have just joined the group.) Anytime you have a call, is it just transport layer encryption or is end to end encryption baked into the base XEP that allows for calls? Or is the "XEP-0320: Use of DTLS-SRTP in Jingle Sessions" needed? Or is this XEP being implemented? "Verify encrypted A/V calls with OMEMO" https://gist.github.com/iNPUTmice/aa4fc0aeea6ce5fb0e0fe04baca842cd Also how does ZRTP factor into this? I have only found one client (ATalk on F-Droid) that explicitly states supporting ZRTP and only one (Conversations) that supports SRTP. My understanding is that these two protocols provide E2EE, not just transport layer. Is this correct? What is the advantage of ZRTP over SRTP? And is there any XMPP iOS client that supports any kind of end to end encryption for calls? I have not seen one, at least with clear documentation of that. I also do not see much clear documentation of which XEP's are implemented on servers that relate to a/v calls. Any information would be helpful, especially from those with links to documentation, sources of information, or server admins.

Have you seen https://gist.github.com/iNPUTmice/a28c438d9bbf3f4a3d4c663ffaa224d9#notes-for-developers too? ✏

Not the standard, but it explains how they all fit together in an implementation

Servers do nothing more than XEP-0215

As for iOS, yes: Siskin supports encrypted calls

when a server offers scram1, 256, 512

is it his job to have the password hash for all of them?

meaning if the server had previously only 1 and 256, he can just add 512

because he does not have the hash for 512

You wouldn't be able to just add 512 if you don't have the hash; there is no good upgrade mechanism for scram

Sam believe me people definitly wood

because they have no clue what it is

but thats my point, its not my problem as a client dev

because someone bugged me about adding 512

oh, I'm sorry, I thought you were asking, maybe I'm missing context.

and that means gajim now chooses 512 if available

512 isn't even a standardized thing yet, hopefully nothing changes before/if it ever becomes a standard

yes i know, but the one guy we all know about bugged all projects about it

so they started adding it

Neustradamus bugged everyone with a client, i think safe to ignore

Yes, I blocked him and didn't add it for that reason :)

then users installed servers, without knowing what they did and activated it everywhere

Anyways, it's not likely to change, I'd just be worried that the working group would decide to add an upgrade mechanism or something then it would be incompatible with all the already deployed made up versions

But it will probably be okay.

server manuals should put a big red sign on that setting

describing in detail what it does to users

like default is SCRAM-1

and then a big red warning, dont activate anything else except you know what you are doing

Yah, probably so

did we even document that?

hm

but there is a upgrade mechanism that comes to mind

switch the server to PLAIN, receive the pass, simulate the client hasing it and find the hash, afterwards rehash?

That will be seen as a downgrade attack by some clients

(Conversations in particular pins the mechanism and won't allow downgrade to an insecure one)

but thats easily solved

user deletes acc from C and readds it

but yeah thats bothersome

That seems like extremely bad UX for the user

then the user can just change the pass :D

Yah, forcing a passsword reset is annoying but is one way

(assuming they have a client that can do that)

hm

but i can still get around C

ah no

it just will not send the pass damn

SASL2? SASL2!

Honestly, while I do encourage the support for SCRAM which has applications where it's extremely useful, for general chat servers I'd just only allow PLAIN. It's probably safer against the kinds of real attacks that matter just because it's got hash agility, which is an *extremely* important property to have.

[citation needed]

feels bad man

Sam, storing passwords in plain text is a really bad idea in my book.

And if you store them hashed and do the PLAIN → SCRAM dance on the server it’ll take a huge lot of CPU power.

yeah and there is no benefit or?

you can just store them hashed

But then you can only upgrade them on connection, which might not happen in a decade (or ever) for some users.

ok, after a decade, i return an error text that says: you didnt loggin for a decade, call me if you want your acc back

Link Mauve: Obviously you should not store passwords in plain text, you should hash them. PLAIN says nothing about how it's stored.

It's not perfect, it's better than SCRAM. Most of the time hashes aren't broken completely right away, instead you get things like SHA-1 showing weaknesses for a while. At that point you can start the upgrade process for users as they log in. Eventually if it is broken entirely, then you issue a password reset email or whatever to any remaining users and disable the old hashes.

(Not a reply to you, but) SHA-1 being broken means nothing to SCRAM-SHA-1, which is still perfectly fine.

It’s a common misconception though, which might have prompted Neustradamus to go on his crusade.

Oh yah, definitely, sorry, bad example

Sam, we don’t have any mechanism for prompting a password reset atm, if we don’t know the email of a specific user they just get locked out. :(

Yah, that's also a huge problem

It's something I'll be working on this year

Extensible IBR was originally going to cover this sort of thing, but I never saw much interest in adoption so maybe something else is needed that's simpler

Didn't Dave's SASL2 stuff cover this? Or was that only in principle?

It does, I'm planning to implement it

Someone with motivation and free time really ought to look at {IBR,SASL,BIND}2 :tm:

You have no idea how much I want to have the time (and/or one of the team's time) to properly look at stream startup things.

MattJ: Thank you, just read that Github page. So if I understand you right, servers implement XEP-0215 and SRTP encryption is handled on the client side? Is there a way to know if a specific call I'm having is encrypted with SRTP? I know ATalk does this but I would love to see it in Conversations or Blabber.im. And where did you find out that Siskin supports encrypted calls? Do you have a link? Thanks so much for the info.

Conversations only supports encrypted calls, so anything that can successfully call with Conversations is using encryption

I think Dino might have a thing showing some encryption details?

I guess that's also why Conversations doesn't show encryption status - there is only one possibility :)

Can't you do calls without OMEMO then?

Yes, the call encryption is unrelated to OMEMO, it uses temporary keys

So I mean, "no, you can do calls without OMEMO"

Conversations also created a mechanism for reusing an OMEMO session to validate the DTLS-SRTP key exchange IIRC.

If you have an OMEMO session with the contact, it also signs them via that so they can be verified

Right, that.

Where things (ZRTP things?) might show some fingerprints for manual verification otherwise

Okay that's really good to know. Do you know if Blabber.im as it is a fork of Conversations, does the same forcing encryption thing? And just to be sure, you are talking about E2EE calls right?