XSF Discussion - 2018-06-17

I have update Ephemeral Messages XEP: https://github.com/xsf/xeps/pull/666

labdsf, if you find the time, then maybe present an htmldiff

for example by using https://github.com/cygri/htmldiff

Ok

I am afk now, will make a diff later

I have mostly removed support for plaintext ephemeral messages, but the ability to implement them is left for "controlled environments", where servers only federate with servers that support ephemeral messages and only accept messages from clients that support ephemeral messages.

That seems like a premature optimization for a very niche use case; unless you know of a service that does this?

Maybe remove it completely

It may be useful for MUC on a non-federated server

When you don't want to setup OMEMO MUC (which requires members-only chat)

ah sorry, I see; I misunderstood what you were saying anyways

Going to re-read this with your new changes now to make sure; but tying this to OMEMO or OTR at all feels wrong to me. I don't understand why there is a distinction between plaintext and OMEMO or whatever in a XEP about something that has nothing to do with encryption

Ephemeral messages feel completely orthogonal to what goes in the body or to the wire format of the message to me.

In an open environment, where messages you send to bare JID or MUC may be delivered to clients that don't support ephemeral messages, OTR and OMEMO can be used to only encrypt messages for clients that have explicitly indicated support for them, as with OTR and OMEMO each device has its own private key (in contrast to OpenPGP, for example).

With OTR, chats are full JID to full JID only, so you can ask the client whether it supports ephemeral messages or not.

With OMEMO I add a PubSub item to show that device supports ephemeral messages.

OTR and OMEMO are the only ways to have E2E forward secrecy in XMPP now. Using OpenPGP with ephemeral messages is a bad idea, because if the device is lost (the only considered scenario), the key is also compromised in most cases (unless you set a passphrase on it).

So there are two use cases.

One is the open network, where you use ephemeral messages only over OTR and OMEMO with contacts that have installed

..clients with ephemeral message support.

The second use case is when there is a trusted "corporate" server network, all servers have forward secrecy on transport level and all clients enable plaintext ephemeral messages.

Sorry, what is the issue with gpg and ephemeral messages in the device loss scenario?

Clearly losing your key is a Bad Thing, but I don't see how that's related to ephemeral messages particularly.

Message copies are left on the server, so they can be downloaded again and decrypted with the key.

In the "open network" use case no server is trusted, so forward secrecy is required to have truly ephemeral messages.

That all seems like unnecessary complexity that's just going to make people think this is a security feature; you can't enforce this sort of thing so adding security theater on top of it doesn't seem helpful to me.

It is a security feature as long as you trust your contact.

hmm, trust and security..

pep.: when you use OMEMO, you trust your contact not to leak the message contents by publishing it on twitter

I don't use OMEMO

labdsf, do you?

It's not though, if you trust clients not to ignore your pep feature advertisement you have to do that regardless of whether there's encryption or not

labdsf, and mostly no I don't ✏

labdsf, encryption and recipient behaviour are two orthogonal concepts, one is technical while the other is social.

SamWhited: I trust clients that specifically indicate that they support the feature, the problem is legacy clients

When a contact has two clients, one is, lets say, Gajim with ephemeral message support added, and the other is Conversations, I want only Gajim to receive ephemeral message.

I remember when people from a MUC I used to frequent started using Snapchat, soon enough someone started using a way to save the dickpics^Wfiles exchanged permanently, despite that being the main “feature” of the service.

Snapchat is not my usecase, I think I stated it at the beginning of the first discussion in standards ML.

Because in MUC that is not members-only users are not trusted.

That was an example on social behaviour

Ok, threat model for "open network" use case: contact is trusted, server is not.

Note that you are in any case trusting remote entities, e.g., I'd find it desirable to force logs in my client even if the remote party doesn't want them. GPG is about trust, while you are focusing on deniability.

But contact has a legacy client.

waqas: if you want to log all messages, just disable ephemeral messages

Or still log them, despite what the other party may want.

But what happens when your contact sends you an ephemeral message

Yep, it's more fun to log them while having you think that we are not logging them

At the end of the day, you are trusting remote entities to not lie

pep.: if you have not indicated that you support it, the message is not ephemeral

labdsf, that's the thing

pep.: your contact knows it

So you won't send this kind of message if your contact doesn't support it? Or will you do it either way?

waqas: lying contacts is not a part of the threat model

labdsf: lying servers aren't either?

waqas: in "open network" use case the server is malicious

The server can always log without telling you

waqas: that is why I say OTR and OMEMO must be used

labdsf, I highly disagree on this point, in my open network use case, servers are often controlled by their user, if someone would lie they would have control over both their client and their server.

Link Mauve: lying client is not a part of threat model

I do not consider lying clients

The server and the client can be considered a same entity in this model.

I do see labdsf's point though. It's largely a case of protecting against current server and future client compromise, if I understand the argument correctly.

labdsf, how do you not consider lying clients, I'm not sure I see it

If a contact tells me it's supporting ephemeral, I might send what I consider a bit more private messages, assuming they're going to be deleted.

Where is that not an issue

pep.: It's protecting against a future search warrant, where clients currently are considered uncompromised

It's not a security feature. It's a friendly reminder to maybe to some house cleaning after you read the message

daniel, yeah I know it's not a security feature

So what does it bring to me as a user, really

pep.: it is ok to send more private messages if you trust your contact not to install malicious client

UX fun?

labdsf, my contact might not know

pep.: what your contact might not know? Thst it installed a malicious client?

Yes?

Took the first client, "hah it looks like conversations, it's green like conversations, must be conversations"

pep., as the recipient you know that a certain messages is worth deleting at some point

for example the sender slaps the delete hint on a password or something

See, all your arguments that it is not a security feature because a trusted contact may install a malicious client also make OMEMO, OpenPGP and OTR useless.

labdsf, oh I agree

And then, the server admin may be malicious and so on

yes

I agree OMEMO is just smoke and mirrors for most people

Lets switch to twitter/mastodon and exchange messages in public only?

daniel: I don't think "It's not a security feature" is consistent with what labdsf is saying here.

If you're saying only omemo and otr as good enough, because gpg doesn't offer PFS, that sounds a lot like you're talking about security features.

Kev, i’m not agreeing with labdsf

It is a security feature that protects messages against future device compromise.

i think the hint should be agnostic of what kind of messages you send

daniel: ok.

The problem here is that plausible deniability/ephemeral messages is not compatible with message authentication.

I also see that just as a UI/UX thing

Definitely no security involved here

GPG is mostly about trust/authentication.

waqas: it is not about deniability. Though deniability and authentication are compatible, OTR does this.

Trusting end clients in the present (but not the future!) is a reasonable position to have, because you really can't do better if there is to be any trust/auth.

i haven’t seen a compeling argument against a simple `<you-might-want-to-delete-me seconds="60"/>`

daniel: consider legacy clients.

I want to be able to avoid sending ephemeral messages to legacy clients.

so check if they support it and if so send to the full jid

i don’t think you can be reasonably sure that the recipient will obey that hint no matter what you do

That is the reason for OTR/OMEMO requirement and encrypting only for clients that indicate feature support.

daniel: the recipient is trusted in my threat model.

Either way, with OMEMO or without, you have to check for support and send only to that client. You can do that with or without OMEMO.

But it has a legacy client

Then it won't advertise support

SamWhited: that is what I do for OTR

I know, I'm saying you have to do it either way, OTR doesn't add anything.

With OMEMO, I can't map device keys to resources

And full JID may be offline

labdsf> With OMEMO, I can't map device keys to resources Yeah that's something I'd like

pep.: it is impossible, device may connect with another resource next time

hmm, wait, no actually I don't need this

SamWhited: do you propose to ask all full JIDd for support of ephemeral messages and send them plaintext ephemeral messages directly if they indicate support?

I think we are mostly moving to sending to bare JID only in chat clients. OTR is an exception, but is is mostly obsolete now.

Not really; I propose just making it a hint and letting clients and services deal with legacy clients however they see fit and maybe documenting some of these ideas

I'd just do like daniel says, send to all resources <please-delete-me seconds="60"/>, and if some support it, cool

But yes, checking for support and only sending to full JIDs that support it is one way of doing that

But yah, mostly I think clients should just do what daniel and pep. just said.

pep.: and some will not support it, so it will be no more useful than snapchat

labdsf, sure

Define "useful"?

"Can work reliably in at least on use case"

Good, then what pep. just said works reliably in the use case where this is not a security feature, it's just a fun convenience that lets you clear up messages that don't have any long term benefit if the users haven on-legacy clients.

non-legacy, even.

SamWhited: but some will always have legacy clients

I'm not sure why you worry about those here

labdsf: yes, and that will be fine since it's not a security feature.

Because I want a security feature, not funny snapchat-like feature

Good luck :x

That is the problem I have with this. This is not a security feature and never can be; at best it's security theater.

there are two use cases here. a) people building walled gardens on top of xmpp. b) jabber as the federated public ecosystem. in a) you are fine with a hint since you control all clients and servers anyways b) i expect only a tiny fraction of client implementing that. so if you limit this to clients that advertise support you probably wont be able to use that feature very often

SamWhited: it is in a scenario where you have two users that trust each other.

labdsf: if you have two users that trust each other you don't need OMEMO because they can just trust that both are using clients that will support it.

Or you don't need this at all because you can just trust that they'll clear their history afterwards.

daniel: i have defined these two use cases above. My XEP supports both. Your proposal is for walled gardens.

If it is a walled garden, server advertises thst it supports ephemeral messages.

It only federates with such servers.

And only accepts clients that support this feature.

That is a way to create a corporate network or snapchat.

Then you can exchange plaintext messages with a hint.

If you connect to the federated open network, this feature is enabled for OTR and OMEMO only.

SamWhited: you need OMEMO in this case, because servers are not trusted.

Why? I trust my server because I'm running it, and my mom is on my server.

labdsf: that's fine; if servers are not trusted individual users can use OMEMO. If they are trusted, they don't. Just like normal messages.

That doesn't really have anything to do with ephemeral messages.

SamWhited: we can extend the spec with the ability to send plaintext ephemeral messages to full JIDs, but it will only work for online clients and require trusted servers.

Ok, maybe you trust the servers and want to send ephemeral message protected with TLS only. Maybe if the user sees timer but no padlock, it is clear enough and nobody makes wrong assumptions. But what about offline clients?

what about them

Just let the server store it in MAM like normal. If you trust the client to do what's right then when it comes back online and fetches them it sees that it's expired and doesn't show it.

pep.: they will not receive message

labdsf, they'll receive it when they reconnect

pep.: no, if you sent to full JIDs

SamWhited: MAM will not store them if you send to full JID

on prosody atm if you send to an offline fulljid, it'll be sent to other resources iirc

And if you send to bare JID legacy clients receive it

labdsf, you really can't avoid legacy clients

One way or another they'll get the messages

pep.: no if I use OMEMO

So.. legacy clientA suports OMEMO, you send to clientB that supports OMEMO and ephemeral, clientB goes offline, gets to clientA, oops. ✏

pep.: clientA and clientB have different keys

clientA will not be able to decrypt

When you encrypt with OMEMO you encrypt for every devices right

and since you can't associate deviceid to resource atm, you don't have a choice

pep.: in my proposal you encrypt ephemeral messages only for devices that support them

So you also need changes in 0384?

No

It is published in a separate item

What is?

The indication of ephemeral message support

How do you associate deviceid to resource

pep., I don't. I publish an item that says "the device 12345 supports ephemeral messages"

:/

just like XEP 0384 publishes a Bundle

well, the problem with XMPP is that offline clients are not registered in any way and you can't ask their capabilities and so on

that is why OMEMO added its own devices that register in PEP

that is why I have to build on top of OMEMO

OTR is possible to support only because it already requires both clients to be offline, but I would say it is pretty much unusable

So you'll never want to support OX

pep., yes

only in "walled garden" scenario

meh

But well I don't think there's a big use-case for this feature anyway

The way you want it

I'm a bit late to the party, but my take on this is simple: ephemeral messages are a joke, I'd want an option to keep them even if remote party thinks not, e2ee has nothing to do with ephemeral messages and PFS is also silly and not needed

Andrew Nenakhov, yes, do read above for more context

Glanced it briefly.

Andrew Nenakhov, just don't implement it in Xabber and no valid client will send ephemeral messages to it

Remote party should not dictate me how I use my archive and device history.

labdsf, if it comes to that I'll probably implement it to show support and let user choose to keep it anyway. 😈

Andrew Nenakhov, just to prove a point that's dumb :/

Even if I agree it's useless in the first place

Andrew Nenakhov, ok, malicious clients are not part of my threat model

labdsf, I'm still not sure how you'll distinguish between malicious and not

I trust my contacts not to install malicious clients

Yeah, that's a bit far fetched, but ok

Such features make no sense in an open environment.

Andrew Nenakhov, that is why I changed the XEP to only work over OTR and OMEMO

it makes it a "closed environment", because XMPP is just a transport in this case

it does not store message contents etc.

If you trust your contacts, why run the hoops with e2ee pfs and all other fancy buzzwords?

If you make something a XEP you are no longer talking about something you can use with your trusted contacts.

because I want to be able to tick the "keep messages in this conversation for 1 week", and if my contact agrees and does not revert it, then we are sure that messages are removed after one week

no need to agree verbally and delete manually

And if you are pushing it to become a standard, you can't protect yourself from 'malicios clients'.

Andrew Nenakhov, malicious clients are *not part of the threat model*, I don't want to protect against them

feel free to implement one

this feature already works in Wire, Signal and telegram "secret chats", everyone is free to modify the client to keep messages

telegram even has multiple alternative clients in Google Play, maybe some of them have this option to keep messages

Why push it as standard then? Just use some form of custom made client and be happy with it

Andrew Nenakhov, I think it may be useful to someone else

Daniel has said he did such forks several times

Andrew Nenakhov, I think he did it for "walled gardens"

Also, if nobody noticed, I have modified XEP to have a simple <ephemeral timer="..."/> element without contents.

So it is not really different from what Daniel proposes

(for the walled garden use case)

If you want it to me useful for someone else then you can't dismiss security threats by simply saying 'they are not part of a threat model'

*to be useful

malicious clients are not part of the threat model of GPG, for example

encryption is not broken because someone implements a client that twits every encrypted email it receives

Because gpg does what it does and nothing else.

You are trying to mix two things of different nature into one flawed protocol.

Also, from XEP: "An XMPP client SHOULD NOT try to restrict the ability of the user to copy and forward ephemeral messages. Any such measures will give the user a false sense of security, but can be easily circumvented by using a modified XMPP client."

no need to implement an option to log messages, everyone can just copy all messages into text file

Andrew Nenakhov, how is it flawed?

It is flawed because it mixes ephemeral messages with e2ee

Andrew Nenakhov, that is the way to avoid sending messages to legacy clients

They are orthogonal, and has been said

In walled-garden use case plaintext messages are allowed

Andrew Nenakhov, they are, but OMEMO is the only possible way to send messages to a subset of offline clients supporting this feature

labdsf, just say 'legacy clients are not part of a threat model' and 'i trust my contacts not to send messages to legacy clients' :)

i can't trust my contacts not to send messages to legacy clients because it is not implementable

XMPP has no way to send messages to a subset of offline clients

Signal has, for example

Signal is a centralized proprietary shit and they can do whatever they please

it may be, I just say protocol-wise

You can do same within your own domain and own client

> it may be, I just say protocol-wise It is only possible because it is centralized proprietary shit )

XMPP has no way to ask remote bare JID to get a list of devices

it has nothing to do with it being centralized or decentralized

Andrew Nenakhov, also, Signal is not proprietary

It is.

in what sense?

all clients and the server are actually open source and source code is even updated frequently

it is just centralized

https://github.com/signalapp/Signal-Server <- server

https://github.com/signalapp <- everything else

AGPLv3 everything

daniel, > i haven’t seen a compeling argument against a simple `<you-might-want-to-delete-me seconds="60"/>` I have modified it in https://github.com/xsf/xeps/pull/666 to be basically a simple <ephemeral timer="..."/>

Can you build signal server and send messages to signal users? No?

The only question is how to avoid sending ephemeral messages to legacy (not actively malicious) clients

Andrew Nenakhov, no, because it is centralized

*build from source

but not proprietary

labdsf, and is owned by Signal. That makes it proprietary.

:/

not sure what is your definition of proprietary, the software is free

You can license code under AGPL or whatever, but your own installation remains your own

the infrastructure is "proprietary", ok

Signal messenger is proprietary.

ok ok

Because it does not work without central infrastructure.

it is federated inside btw

Ok, almost 4am here

Bye

I should probably remove "plaintext/encrypted" distinction where possible and make it more clear that OMEMO is just a way to avoid sending to legacy clients