XSF Discussion - 2017-10-05

moparisthebest, a change from SHOULD to MAY is a technical change. However, given that there has no advancement been made to the XEP yet, that’ll be fine

I guess this is what the CFE is for

Well, it's for Council to decide whether it's fine or not, no?

Kev, yes

you’re right about that

what I meant is: it is not absolutely not fine

and also council members brought that change I assume moparisthebest will do up in the discussion, so ... ;-)

Kev (others): please elevate me from member to owner on our github repo, add me to the team on dockerhub, and provide me with the twitter credentials. It'd be good to have someone else be available to help people out with requests in order to speed up things (and as I'm currently the requestee most of the time, who's also in iteam, I'd be a logical candidate).

What's your name on the docker hub?

You've got ownership of the github org now, I'll sort out docker at some point later when I know your account, and Twitter I need to sort out password changing and distribution of the password.

Please don't change things without discussion.

Thanks, I won't

I'm guusdk on dockerhub

when establishing (direct) ssl, is more than one socket connection involved (is a connection re-established?)

Guus, no

you start TLS over the existing TCP connection

Just like STARTTLS, except without the negotiation

sounds like it's time to shout at apache mina again then

Zash, s/without \(.*\)/with \1 done by the TLS library instead of by the XMPP one/

That hurt my head

Depends on how your libraries work I guess

It's a great way to shave off some round-trips, though

Kev: "undesirable"... I love your choice of words!

undesirable in that context might be the XMPP-related understatement of the decade :-)

Kev: killing GC1 was brought up to the council, but without a well worded motivation. I also agree we need to kill it, but it is to some degree a better resync mechanism than nothing at all.

It is definitely better than nothing at all.

I've long held that opinion. But if we're providing something better now, maybe it can retire.

Kev: except when you end up seeing ghosts in the MUC.

You see ghosts in the MUC with or without gc1 joins, without another mechanism.

Without gc1, everyone you see (as a client) is a ghost :)

Kev: yes, but then you realize that as soon as you send a message.

That is true.

Kev: my point is that it's not always better than nothing.

If we get rid of gc1, isn't a normal presence the same as <presence><I-expect-to-still-be-in-the-room/></p>

If you're referring to (3), then no.

Zash, yes, but we can’t simply get rid of GC1, can we?

Can we?

jonasw: Can't we? :)

Kev, council was against it.

I mean, we can re-try, but ...

speaking of council, still no (re-)applications?

Council may have been against it when there wasn't a better option, they may not be after this.

Only Joe Demo, by the look of it.

I hear good things about that guy.

like Boaty McBoatface?

Again, I want to propose Boardy McBoardface for Council.

not Council McCouncilface?

jonasw: no. C McC should apply for Board instead.

for maximum confusion, I see

I wonder if I should apply for Council, and then try to aggressively push the XMPP 2.0 / Easy Jabber agenda.

Killing GC1.0 would be my major campain promise.

hm, one can’t really make promises, can one?

when running for council

(well, one can... but in the end it all depends on who else gets elected. then again, that’s the same for all elections)

I kinda think that what xmpp2/easyjabber needs most, in some ways, is implementation and deployment experience.

you can’t really do implementation without some specification

Of course you can.

Just type code into your thing!

You try something and see if it works.

well, you shouldn’t

hm

Also, completely untrue.

So you are a specification before implementation person?

Protocol documents based on people actually trying things is a jolly good thing.

Some are the other way around. Some think both at the same time!

yeah, I see where you’re coming from

Everything has its place. Except the things that don't.

I’m not necessarily, but Session 2.0 is a thing where many parties need to play together, so there needs some kind of coordination, that is, specification, on what the parties implement each

jonasw: Nothing says that has to happen in advance.

Kev: I could implement Session 2.0, but then it would only work for IM.

e.g. if I had spare person-hours, I'd have something that worked implemented in M-Link and the Swifts, and we could use that experience to feed into the specs.

Ge0rG: Sure. But 'try stuff and see if it works' doesn't mean 'specify what was implemented and treat it as set in stone because you coded some prototype'.

Kev: I also need to read up what I have "proclaimed" in the last two years under the "MUC-subscription" label. I think it's all the same basic idea, and maybe I forgot something important in the last iteration

itym MAM-subcsription

jonasw: right. Sorry. I won't LMC that now.

Ge0rG: I *think* the important thing there is simply that everything that's chat-related you want both in your archive and on all your devices.

So all we need to do is achieve that :D

So how do we determine if a message is "chat-related"?

I did the hard work of coming up with the high-level direction. Someone else can work on the details.

type=chat would have been nice

Kev: you are a genius! Why didn't anyone else think of that before? :D

Zash: 0184 and CSNs happen to be type=random.

also, what about type=normal? :)

Aren't those chat related?

Zash: maybe they are.

that certainly has messaging use-cases too, and wouldn’t you want to sync them, too?

jonasw: chat is the new normal.

that’s your opinio.n

;-)

jonasw: that's what implementations do

because no implemntation has a UI for type=normal

except pidgins "let’s show this in a separate window focus stealingly" counts as UI

jonasw: I think many client authors don't care about "normal" vs. "chat", and end up sending non-body messages with "normal"

meh.

Like for example ACKs.

-xep 304

Zash: XEP-0304: Whitespace Keepalive Negotiation (Standards Track, Deferred, 2011-08-18) See: https://xmpp.org/extensions/xep-0304.html

jonasw: also guess which message type is mandated by [xep 0184]

"whatever works"?

Ge0rG: {}

Zash: -ETOOMANYDIFFERENTBOTS

Bots bots bots

can't we just have all bot react to all patterns, instead of putting the cognitive load onto people?

Wasn't both 184 and csn using the standard reply pattern? Ie same type

-xep standard reply pattern

Ge0rG: XEP-0068: Field Standardization for Data Forms (Informational, Active, 2012-05-28) See: https://xmpp.org/extensions/xep-0068.html

Copy attributes, swap to/from. If it's an error, set type=error.

Zash: There is no such primitive in the XMPP lib I'm using.

Ge0rG, switch XMPP libs then!

Zash, also, you shouldn’t be copying the @id for anything except IQ, I think

Zash: I'm not even convinced this is a good thing, generally. Maybe type=headline would be more appropriate for ACKs and CSNs?

I think acks you probably want stored in your archive, while CSNs you certainly don't.

Kev: Are you sure?

Right. ACKs need to be archived.

Actually, I'm fairly sure you want something more sophisticated than just putting acks in your archive, but I'm not sure how revolutionary I should be today.

Kev, as much as possible, of course.

Kev: it's all about synchronizing a chat database.

Kev: yes please. Make the most revolutionary proposal you can imagine.

Have your server handle your acks for you. Also have the server archive read receipt status for your messages.

Have the ability to collate messages that operate on each other in the archive, so they can be returned as state on the MAM results.

Kev: I think MAM would be indeed a good place to send 0184 acks, from the bare JID

Delivered, Read, LMC. Store them, but on the message they affect, not on their own.

Kev: that message collation would work much better if we had properly-generated UUIDs

Does "unique" also mean that there should be only one UUID per message?

Kev: I object to anything that makes it impossible to do MAM in an append-only log store thing.

Kev: BTW that almost sounds like a multi-table relational database

I object to anything that requires a relational database.

Zash: better apply for Council now, then

I think the most sensible way to implement MAM is with a database of some description. But clearly it's not needed.

Kev: how would clients synchronize? Atomic replacement of [Message, Delivered, Read, [LMCs], [Reactions]] n-tuples? Or do we need a separate chronological history?

Synchronise in which sense?

This is again the fully-synchronized fat client vs. load-on-demand thin client debate I think

Possibly.

For load-on-demand it makes sense to initially query for n-tuples, and then to receive a stream of deltas.

For fat clients it makes sense to receive a stream of stored deltas, followed by live deltas.

That is possibly true.

Now this is another thing I had in MAM-sync: push of MAM-IDs for sent messages.

isn’t that already a thing in {XEP 0280}?

damnit

-xep carbons

jonasw: no

Zash: XEP-0280: Message Carbons (Standards Track, Proposed, 2017-02-16) See: https://xmpp.org/extensions/xep-0280.html

no, I misremember

jonasw: I tried to bring that up a year ago or two, and there were very loud voices arguing against that, because of sysload

I think someone (mattj?) suggested a carbons extension/change where you'd get your own messages reflected back

what

syswhat

I'm not entirely convinced that just mirroring the entire (annotated) stanza back isn't sensible.

If I were redoing XMPP, I'd glue together session, MAM ID reflection and 0198

Kev: maybe except for https://xmpp.org/extensions/xep-0047.html#message

what’s session in this context?

jonasw: that thing you bind.

ah

jonasw: what I mean is: have a separate session type (XMPP2, MAM-sub or whatever you name it), which replaces carbons and 0198 with a logic that feeds back MAM IDs for sent messages and either Carbons or direct messages of all incoming data

I'm not opposed to the Carbons wire format, just the current processing logic is insane.

sounds reasonable

still possible to do that even without redoing xmpp

Everything's possible without redoing xmpp :)

jonasw: still doesn't solve the persistency/urgency problem.

Ge0rG, that needs fixes to MAM, Carbons, CSI and Push. All of which aren’t final yet, right?

jonasw: are there any final XEPs at all? I thought Draft is the new Final.

XEP-0030 :)

(for example)

I'm pushing to make 368 final

but also considering I nor any current editors have ever seen a move to final

no

moparisthebest, no worries :)

just prepare your PR and see what council says.

yea I'm just agreeing with Ge0rG here, final isn't a thing, draft is final

I think that might have something to do with our habit of getting something 'good enough' but not quite right, and so not being willing to advance it further.

isn't the question what the benefit of final XEPs is, over draft XEPs?

as far as I can tell, final only has disadvantages

Flow, what advantages does Draft have over Experimental? :)

jonasw: another review round at least by the council and probably by the xmpp community

okay

then final probably doesn’t bring you anything :)

plus at least so und so many implementations IIRC

that’s only with Final IIRC

ahh right

ok, so after reading xep1 once more and to sum up: final has the disadvantage that no namespace bumps can be made, which is probably not an issue (see ecaps2). And the advantage that feedback was given and there are multiple interoperable implementations required

(I was thinking that this was for draft)

There is no technical difference between a namespace bump and a new namespace, so why are we forbidding them?

Ge0rG: they are not treated differently, changing the namespace is forbidden in final.

SamWhited: yes, so we end up with a new XEP with a new namespace instead.

Ge0rG: Yes, that's the point, after something has reached final if you want to replace it you need to create a new XEP.

SamWhited: yes, I'm merely questioning the wisdom of that

I don't even know where to begin with that… you want XEPs to never stabalize? We have enough problems with people not wanting to implement experimental XEPs because they're a moving target without saying that all XEPs have the potential to change and break compatibility and fragment the ecosystem at any time.

I'm all for going to final slowly, it's nice to have the flexibility to change things, but at some point when things are widely implemented we need to stop breaking compatibility and call it "good enough".

SamWhited: I'm just some random smartass, questioning everything. But I also wondered if other parts of our process might be improvable.

I definitely think there's room for improvement, but never stabalizing anything probably isn't it.

yeah

I’m already not happy with XEPs changing at all

Except when they are made better?

even draft xeps sometimes undergo massive changes, see Bookmarks.

I'm not implementing Bookmarks. Because the RECOMMENDED way doesn't work, and the working way is Historical.

same with omemo?

no, OMEMO has a XEP reflecting the current state now

I'm not implementing OMEMO because the deployed protocol is not specified, the specified protocol is not deployed, because it adds major UX bumps and because I don't believe in E2EE.

jonasw: oh, it does?

it uses the siacs namespace at least

the problem with namespaces bump is that I need to maintain all the code for previous namespaces, blowing the codebase, this is annoying

another issue I have with that is that old versions are barely discoverable

you could see a XEP for the first time a day after the last namespace bump, implement it, and see that nobody implements that version in the wild yet

zinid: we can't bump the namespace on MUC, fortunately.

Ge0rG: and we resorted to replace this monster with another monster?

zinid: MUC is not a monster. It's ugly, but it's not too large.

I have 4000 LOC of mod_muc* modules, isn't this a monster?

if it's not a monster, then what it is? I can recall pubsub only

Huh

zinid: you know, bad specification is not the only cause of bloated software.

Sometimes the problem is in front of the terminal, actually.

‎[02:06:51 PM] ‎Ge0rG‎: *snip* I don't believe in E2EE.

what

what possible reason could you not believe in E2EE, and in what way

It's not the golden saviour of humanity as some would have you believe

moparisthebest: E2EE is often advertised as the solution to dragnet surveillance, but it doesn't fix the biggest problem: three-letter agencies are interested in meta-data more than in actual content.

Also it invalidates a bunch of the assumptions XMPP is built on

moparisthebest: just the fact that Facebook-WhatsApp rolled out E2EE should make you think.

moparisthebest: if you really want to prevent meta-data collection, you must run your own server for family&friends. And then you don't need E2EE any more.

(I find that argument rather convincing, by the way. And I belong to the group of people who’re still using OTR, because reasons)

so I agree, it doesn't solve everything, nothing does, it also doesn't harm anything either though

it does

I run my own server but still use E2E, what if the mam database is compromised or otherwise exposed?

take a look at the number of people complaining about issues with OMEMO and blaming it on XMPP

like losing messages in groupchats

they don’t think the issue might be the experimental E2EE implementation they’re using.

(or, maybe worse, blaming it on the server)

moparisthebest: OMEMO failed to address the device migration use case, among others.

moparisthebest: my position is: XMPP is already f***ing complicated and has too many corner cases that break the UX. We shouldn't be adding yet another one.

uh Ge0rG droped the E2EE bomb

where is my popcorn? ☺

Ge0rG: you have a point here. But I'm not sure if E2EE couldn't be made user friendly

Flow: what bomb? I'm making this points for years now.

Ge0rG: well I know, but obviously there are still people who act a little bit shocked when you say that

your arguments all apply to OTR

not at all to PGP

and only a little bit to OMEMO

so

Flow: I'm sure it's possible to make E2EE more user-friendly than it is now. However, it won't be as polished as WhatsApp E2EE any time soon, and we (as the Jabber community) already lack the resource to make XMPP more user-friendly.

moparisthebest: my arguments apply to all E2EE on top of XMPP

also Ge0rG your argument was if you want privacy have all your friends have an account on your server? kind of kills federation no?

moparisthebest: surely the problem isn't E2EE *on* XMPP

moparisthebest: no, he (and I) want you to run your own XMPP service

and federate with your the XMPP server that is run by your friends

so every user runs their own server?

moparisthebest: "not at all to PGP" -- no matter what E2EE you're using, you either don't verify keys or break communication by insisting on verified keys.

We need to go away from big centralized XMPP services like jabber.ccc.de or jabber.at

moparisthebest: No matter what E2EE you're using, you can't do server-side search on your archive.

moparisthebest: No matter what E2EE you're using, you can't do server-side spam filtering.

And to achieve that, we need to enable non-tech savy users to run their XMPP server on a vServer or on their home router

under their own domain

Holger, incorrect, WhatsApp does server-side spam filtering only with metadata.

Holger: Now that you said it: I never received OpenPGP encrypted spam. wonder when that is going to start

Holger, as Ge0rG said you have metadata, most filtering is on that anyhow?

moparisthebest, it doesn’t work with XMPP, you need to have control over all servers to effectively filter spam on metadata

in fact all the current 'must be on roster' filtering works with e2e

(well, it’s not exactly like that, but federation makes it so much more difficult)

must-be-on-roster is a very very bad spam filter

yep, bad idea

I agree

jonasw, moparisthebest: I doubt that filtering purely on metadata can get you an accuracy anywhere near to filters that also take the body into account.

saying e2e is a bit hard so we shouldn't support it is dumb though, it's perfectly legitimate and if done right basically free

Flow: It'll start once OX is ubiquitous of course :-)

hehe

sadly new clients still implement xep27 ;(

moparisthebest: Yeah, dumb. In practice people just give up this XMPP shit due to the E2EE breakage we introduce.

(I've seen *two* people saying just that *today*.)

it's better than nothing (xep27)

moparisthebest: I don't think so. OpenPGP without a replay mitigation is worser than no verification at all

for example

replay is a type of attack, sometimes it doesn't matter

?

Holger, whatsapp apperently does it quite well

but I only heard that second- or third-hand

Flow, sometimes you just need to protect content and don't care about replay

moparisthebest, I don’t say we shouldn’t support e2ee at all. but Jabber as an IM system has much worse problems than not supporting E2EE currently.

we need to solve those firts

it's always going to have problems, everything does

*especially* with security systems you can’t simply handwave problems away

moparisthebest: but especially in IM you want to know that the "I aggree" from the other side was a current response, and not from days ago

people don’t expect replay attacks to work

jonasw: Yes much better than we do, mostly because they hide verification very well and don't have MAM/multi-device support. (And of course because they avoid implementation issues by controlling the clients.)

and you can’t expect people to understand that

Holger, they don’t have multi-device support?

I thought they did.

but how does that relate to spam filtering?

jonasw: No, they just have a web client that talks to your phone.

eww

Flow, yes the "I agree" replay is potentially a problem, the "here is your report for 2017-01-01 08:32 bla bla bla" is not

but uh, "replay" is also a huge problem without e2e, so

Holger: and because they have millions of dev budget.

moparisthebest: "the "here is your report for 2017-01-01 08:32 bla bla bla" is not"?

Flow, if I get a dated report from last month I'll be pretty sure it's a replay I guess

Ge0rG: RIght.

what is the argument here? xep27 is bad because it's vulnerable to replay so use no encryption? (which is also vulnerable to replay)

That's not my argument, no. I use 0027 with the two-and-a-half geeks that manage to cope with key deployment in my roster myself.

anecdote of course but I switched to xmpp specifically so I could use PGP, then omemo came along and I use it sometimes, PGP still has a place

now I'd much rather use OX than 27, but 27 is better than nothing

moparisthebest: The point is that xep27 is badly designed, allowing for replay attacks because the recipient (and a timestamp) is not part of the secured data

moparisthebest [21:22]: > Flow, if I get a dated report from last month I'll be pretty sure it's a replay I guess And if the report author gets a "the report is okay, publish it", you can't know for sure

moparisthebest: Yes, "no forward secrecy" and "one key per contact rather than per device" are clearly features I appreciate compared to OTR/OMEMO.

right I completely agree OX is better Flow , but 27 is better than nothing

OpenPGP certainly has it's place

moparisthebest; And that is where I disagree with you ☺

I find it most handy for where I used to send cronjob output as pgp encrypted email from my servers

a sendxmpp that does OMEMO seems, hard

true

Flow, how could 27 possibly be worse than no encryption exactly

it doesn't prevent replay or spoofing, neither does no encryption

Wrong sense of security.

moparisthebest: what holger said

it does protect content

that's all it does, I know that, I'm fine with that

it may be sufficently secure for the use case you described

but not for the gernal IM use case

100% agree OX should be pushed forward and I will drop 27 first :P but until then

OX would be able to prevent spoofing, xep27 is not

It's such a pitty that there is no high level OpenPGP library for java

you could do android first :)

in fact there was a WIP OX pull request for conversations

(Java/Android that is)

android has an excellent openpgp implementation/app

I know, OX was born because I meet the OpenKeychain dev's at the GSOC mentor's sumimt 2015

*met

I've been begging them to factor out the OpenPGP part of OpenKeychain into a library for Java and Android

on android at least it's better as-is isn't it?

as a PGP app that's usable by other apps

I'm sorry, I don't know how to parse that

Ahh yes, that was our idea for the conversations OX implemenation

I don't want to import my key into conversations, and k9mail, and oandbackup

I instead import it into OpenKeychain, and it does all the lifting, and the other apps just talk to it

OK (OpenKeychain) was missing a few additional exposed APIs for OX in conversations

but the effort stalled

moparisthebest: I don't want to import any keys anywhere.

> incorrect, WhatsApp does server-side spam filtering only with metadata. No surprise, for centralized servers it's much easier to fight against spam when you control *every* user

moparisthebest: The key should silently be created by the app I'm using and auto-deployed to any other devices. Anything else will end up being completely unusable.

oh well that's a different thing, yea I'm sure they'd add additional apis

Holger, omemo?

moparisthebest: OX, maybe.

moparisthebest: https://xmpp.org/extensions/xep-0373.html#synchro-pep

hmm I'm not sure 1 key being automagically distributed is better than one key per device

yea I remember reading it, I'm not convinced I want my encrypted key on my server

moparisthebest: IMO it makes the difference between "completely unusable" and "maybe somewhat usable" by non-geeks.

moparisthebest: Do you have a single non-geek in your roster you're talking PGP to?

I think you are right actually

in that the normal case it should do that

but should also allow me to use my already-set-up-not-on-server key

Holger, uh yes, but you didn't ask if I had to set up their pgp key for them or not :)

Yah I'm not discussing Advanced -> Expert -> Special options.

do I have anyone in my roster I talk to with PGP that I didn't fully set up their key manually for them for? no :'(

I had like five and am down to three I think.

Of my ~150 contacts.

If which 100+ are geeks :-)

s/If/Of

what client(s) do you use?

MCabber and Conversations.

ah ok, I started with gajim and it didn't actually do carbons+pgp right, I got the impression no one else had tried

I heard of various issues with Gajim's PGP support but never tried myself.

Works just fine with my two clients.

I put in a patch to fix that and it worked great for years until new gpg broke the python gpg lib, and I haven't looked at it

Ah right gpg2 is a PITA for MCabber as well. The fix is sticking to gpg1.

(Though McKael is somehow using gpg2 I think ...)

iirc it worked fine with gpg 2 but 2.1 broke it

I think the python lib is hardcoded to treat unknown errors fatally instead of a generic error and that breaks everything

I need to look into it one day

I'm not a security expert, but what is a problem to keep private key securely on a server?

Holger: Yes I'm using GPG2 but it's painful, indeed.

McKael, have any patches laying about or a terrible wrapper script or what? :)

can't I just encrypt it using my password which is supposedly stored hashed as well?

moparisthebest: No, lately I've been using the default pinentry and it messes things up

Not sure how I got rid of that before, I forgot :/

zinid: defense in depth, one can tell that your server is already protected by password so no need for PGP private key passwords, but you use it anyway to have layers of protection

I don't understand, according to e2e proponents, they don't trust server admins

zinid: Yes that's how I'd do it. Not sure how to survive forgotton/restored passwords though. Maybe each client needs an unencrypted copy of the key to re-encrypt it on password change or something ...

zinid: you don't store the private key even encrypted because loss of password would compromise the key

I'm not using PGP with xmpp though

But usually you don't even store the private key in software but use hardware token

To further protect the key

but you can also lose private key

"usually" :-)

Holger: lol :)

Holger, I would separate the account's PW from the key's encryption PW, then the server also stores the latest modif of the encryption PW, when the user connects, the client checks if its stored PW is the latest, and if not prompt the user for the new one

and typically you lose private key with losing phone for example

still not clear

I cannot believe there is no solutions for this problem, key servers? kerberos? just to mention, I know jack shit about these :)

matlag: The server has a clear-text copy of the key encryption PW??

no, only the date of the latest change

Ah.

So simply a separate passphrase?

yep

"Hello User, please type your password! ... thanks, now please type your other password!"

which will be the same for the majority of users :)

They'll love you.

zinid: truly paranoid store their private key copies only on offline, airgapped machines, then load it on OpenPGP smart card

Note I'm not advocating for that

Wiktor: are we building a network for trully paranoid?

Wiktor: can we just have non-paranoid mode/

?

well, currently the risk is "Hello User, please type your password! ... now please type your entire private key"

I'm not building anything just saying there are various threat models in existence

zinid, you need to fit all the needs! so paranoid should be an option

matlag: sure, don't store private keys on server, keep them on hardwared device

I mean it's totally opaque for the server where you keep your keys

matlag: My point was about increasing the usablity of E2EE, not about increasing it's security. The latter is easier, the problem is just that you end up with zero users of your secure solution.

but still a problem with password restoration indeed

matlag: As a well-hidden *option* you can make it as secure and unusable as you like. The interesting part to achieve is to implement a default behavior that doesn't break day-to-day communication.

I agreed

I admit it's not so friendly, but on the other hand, you can store the key PW on the client and then you don't need to change it as long as you don't change the key PW

currently users are trying to use OMEMO, they fail and resort not to using OMEMO at all

so probably better to use less secure option?

I mean: is that so much more cumbersome than changing your home's wifi password?

zinid: They resort to ditching the non-working XMPP crap.

matlag: The point is it's so much more cumbersome than just using WhatsApp/Signal/whatever.

matlag: did you really contact with a regular user? my wife's mother cannot configure wifi for example, but she loves whatsapp, so a potential user

Yeah, ok, point taken

what if you make them have 16 character passwords and take the first 8 for the key password and send the second 8 to the server for login

either way yea I want to decrypt my pgp key with a seperate password, normal users probably don't need it encrypted on the device at all

but all 16 characters will be lost?

moparisthebest: Won't help much if you're trying to protect against the case where the password is lost.

because they are stored in a single place, no?

moparisthebest, They end up typing the 16 characters and that's the same as having hte same PW for both

(zinid was faster.)

What would be great is an xmpp server that encrypts everything for a user with a key pair where the private key is only unlocked while the user is logged in.

If your target user is a mother in law you shouldn't be talking about encryption because she probably doesn't care if whatsapp is encrypted but of easy contact discovery and on boarding process

Wiktor: but usually I'm not talking about e2e :)

I think it's still just a toy

Ge0rG, meh that's still just fully trusting the server

I mean you already have full disk encryption and such on the server

Wiktor: Agreed! I'd just disable encryption by default. But everyone is telling me it MUST be enabled by default, or even always.

Ge0rG: Wanna the crypto design and audit?

zinid: agreed, but for me it's a toy for power users, like PGP itself

So let's assume most users don't care about encryption but you want a default encryption for them: most can use the same PW for account and private key, others can have them separated?

or just don't have a password on the local pgp key

Wiktor: So I'm getting to think about how to enable E2EE in order to make the geek marketing department happy without breaking stuff for the mother in law :-)

Wiktor: then nothing should be changed, everything is great

it's storing full conversations in plain text anyway, most likely

Holger: on my client it's disabled by defiant and I use it with one contact for 239 unencrypted

For me that's a good ratio

Wiktor: The Conversations tracker is full of people complaining how OMEMO is optional and non-default.

zinid: w.r.t. To omemo just add support for key migration / rotation and easier adding of new devices

I did a prototype of a thing where some data is encrypted using a key derived from a SCRAM thing that you only have during login

Zash: maybe one day I'll find a corporate customer that will pay for it

because default is how it stays 99% of the time

Zash: I remember that, yeah

and if we've learned anything over the past 5 years or whatever, encryption should always be default

at least, most people have learned that

Wiktor: ^ see?

:D

Hshshw

Wiktor: So how to deal with all the moparisthebests in the community? :-)

Hahaha*

moparisthebest: I'm not convinced that XMPP is the right thing if you wanna have a protocol where everything is encrypted.

:)

Great point Holger

Zash, do you know of better ones that don't eat battery due to p2p ?

XMPP is a giant compromise. Compromise between p2p and centralized.

> encryption should always be default Define "encryption"? Are you still talking about e2e encryption like most of this conversation (I've just been passively following)

all of it, imho

I mean, TLS/transport encryption should be mandatory with no cut-off

moparisthebest: well it is on xmpp since 2014?

e2e should be default, with the ideal of no cut-off

moparisthebest: Apart from that, I should be rich!

that's the ideal isn't it? :P

moparisthebest: what is your threat model? Why do you want e2e6by default? Do you understand that without face to face fingerprint comparisons e2e does not provide any significant advantages?

I tend to agree current pgp/omemo isn't quite ready for default enforced prime-time, that's just where we should be aiming

Wiktor, it still defeats passive surveillance which is ubiquitous

Tls defeats passive surveillance

also all the server hack leaks everywhere

Why? What is the actual thing you are trying to accomplish by making e2e encryption the default?

moparisthebest: By whom? e2e protects against some cases of evil server, but in XMPP, if your server is evil, you are screwed

you don't have to trust your server, so why trust your server

and, your chat partner's server if not the same

Zash: the point I'm told is that the remote server can be evil and you can do nothing with it

Zash: exactly. moparisthebest If your server lies about your keys and you don't compare them live then the security model has been broken

also define 'screwed', it can block your messages, it can't do anything else with e2e

Wiktor, again an active attack that you can detect before, during, or after

zinid: Sure, you have to trust that your chat partner picked a trustworthy server too.

vs you having no idea who has your messages when

Well usually only your server and your friend's has messages, in xmpp they are directly connected.

Zash: I agree you cannot build security without trust, the question is how paranoid we should be

It sounds like "encryption" is being equated with "security" here, and that's always dangerous. If you ignore the user aspect (you're making all sorts of trade offs by forcing everything to be e2e encrypted) they'll just go somewhere else or develop bad habits that make things worse. If you can't clearly articulate a reason other than "why not?" you may want to think about it more. That's never an okay way to approach thinking about security.

Wiktor, do I know if they are connected securely

do I know if the other users server mandates encryption on c2s

tls in this case

Well your server should mandate your security standards

but if you sign up for newhotserver.im

you think key verification is the problem

but the solution is to personally trust your server operator?

seems suspicious

Then do you know if your friends computer is not compromised by malware?

it's about minimizing risk, that's a risk either way

you have to trust your friend's endpoint

you don't have to trust everything in between

Key verification is always the biggest problems :)

Yes it's about minimizing risk but if the advantage is small enough then it's not ok to mandate e2e everywhere

Or if it actually makes things worse…

what if it doesn't have any disadvantages

Yes, exactly. There are always trade offs

moparisthebest: but it does

you mean some current systems do

yes

> what if it doesn't have any disadvantages I've never seen a solution to anything without disadvantages. There are always constraints.

and security is always inversly proportional to usability

whatever encryption you suggest, you lower the usability part

so users should clearyl understand why they suffer

that's not true though

do you have your laptop hard drive encrypted?

moparisthebest: that's not even my words, Schneier said that :)

moparisthebest: no, I don't

even great guys can be wrong sometimes haha

ok well that's just inexcusable why? :P

I guess if it never leaves your house it's probably fine

moparisthebest: I don't know how to do this

HD encrypted can be a usability nightmare if you have your keys only in TPM and TPM died :)

is it ok answer? :)

moparisthebest, In this case, for example, the only way to have a solution that guarantees no user intervention is to have the private key stored on server and encrypted with the user's account PW: no degradation of usability, BUT: not nearly as safe as the blows and whistle you hear for great E2E

the point I was going to make was it's the same either way, you type a password to get into it regardless, and nowadays it doesn't even run slower

I have two laptops, one has the disk encrypted and one doesn't. The one with the disk encrypted I have to type a password in every time I boot and if the sector that contains the key gets corrupt the whole harddrive is lost instead of just that one sector.

That is a trade off.

I only chose to make it on one laptop because I have a very specific threat I am trying to protect against with that specific machine.

if you increase security, then you need the user intervention, and as you increase it, more and more user intervention

a few sectors include the key normally SamWhited

Doesn't matter, it is more likely that I lose all the data (I do actually have it in two key slots, I also keep an offsite backup, another tradeoff I made)

The point is there are tradeoffs to the thing you used as an example too. If you don't even know what threat you're trying to protect against, there's little point in making some of these trade offs.

really that's a bad example anyway, the users I see generally expect chat to be ephemeral anyway

so if they forget their password and don't have logs from yesterday, oh well

I guess it's a trade off but also maybe what they expect?

a good example is probably how PKIX is used currently in browsers

(I'm basing this on all the users that want to be able to delete shared pictures from http upload)

I expect IM history to be eternal. Maybe I'm different.

very little inconvenience

Ge0rG, then you already have backups and such and will get that with e2e also

moparisthebest: e2ee is more complicated than not having it.

moparisthebest: the people who are the loudest to demand e2ee have the least understanding of it, usually.

And I'm on the road for almost eight hours now. German public transportation has been severely impacted by some storm.

I guess everything is more complicated than not having it

moparisthebest: Easy XMPP is an exception

xmpp2 !!!111

still more code

Ge0rG: btw, your subject about message routing didn't route further in the standards@ :)

Ge0rG: my guess is that nobody knows how to fix stuff, lol

can we make direct tls the only way to connect in xmpp2 ? :P

adding more xeps => sucks breaking compatiblity => sucks

moparisthebest: is it the major problem? :)

no just another nice-to-have

also I don't see any trade-offs with this one haha

the trade-off is more implementation

poor library support

for direct TLS ?

surely it's the opposite

yes

every TLS lib ever vs xmpp-specific-libs ?

you need to support SNI in server, that's some work if you use openssl ;)

ejabberd doesn't support it for this reason, the API is ugly as hell

you are already doing far more work for everything else in xmpp2 surely

I need to be a man and implement it

anyway it gives you tons of other advantages

0-rtt, false start, everything fancy https gets

isn't this the trade-off we're talking about? :)

you get all these goods, but need to put more code, at least server side

and ALPN is only supported in openssl 1.0.2, some systems still don't have it yet

you are talking about xmpp2 though, it's all more code

I think I'd rather rewrite everything XMPP from scratch than spend time near OpenSSL's API again

moparisthebest: that was a joke actually :) obviously transition to xmpp2 will bring lots of pain

also zinid 1.0.1 is already dead so I don't think anyone should care, hopefully :(

yea openssl is the perfect example of a footgun api

moparisthebest: surprisingly, we get complains from time to time about cutting edge version requirement (1.0.1), lol :)

"zinid 1.0.1 is already dead"

ah

context, it's all about context :P

but still I think direct tls is a great idea