Follow

@vecna@www.librepunk.club forgot to mention, files won't be opened in both directions

on Conversations you can click on the link to view the file but on SiskinIM you can not decrypt it

@Muto @vecna The problem with OMEMO and files is that... it's not standardised in any way (there is proto-XEP inboxed: xmpp.org/extensions/inbox/omem but that's just about it); second problem (slightly related) is that Coversations doesn't check (it's not specified in said XEP) whether other party could handle encrypted file and sends it blindly; we should improve XEP to add discovery functionality (features) and then clients should check those before sending files blindly.

@tigase

To be fair, the difference between sending blind and not sending at all is close to zero, other than to make the recipient (as opposed to the sender) aware that their client lack support for that feature.

A bit of bandwidth and server storage wasted, but otherwise no big deal

@Muto @vecna

@0 @tigase @Muto @vecna well if there was a way for the sender to make the decision to not send or send unencrypted, that'd be strictly better than the message not being shown to the recipient, IMO.
I agree discovery could be part of the XEP.

@tigase habe you contacted Daniel about this?

@stevenroose

I don't think that's an option as it would greatly undermine the purpose of encryption in the first place, and it would add technical debt without offering a long term solution.

If anything, it's the other end that'd need to catch up and handle encrypted files.

I'm in two minds regarding discovery. You could say that you should only advertise encryption if you can handle it completely, OTOH not everyone needs to send files.

@tigase @Muto @vecna

@Muto @vecna

@stevenroose Not about this particular issue, no.

@0 we do agree that this would undermine encryption (and we are working on adding this feature) but at the same time we are in weird situation where we relay on feature discovery discovery yet in this particular case it's OK to ignore it. Would you say that sending encrypted messages without checking if the other party is also OK (not encrypting it would still undermine security)? We should either mandate it in XEP-0384 or add feature support

@tigase

I agree that XEP-0384 needs an upgrade. For a start, its discovery mechanism (§ 4.2) is non-standard. It should advertise itself via XEP-0030 instead, and then it could also inform peers of whether out of band data is also encrypted (and how) or not.

@Muto @vecna @stevenroose

@0 @Muto @vecna @stevenroose this sounds good - should we make it happen? :-)

as for other question - those are the "ups and downs" of XMPP - it gives you at times too much flexibility (more or less arbitrary set of XEPs that one can support)

@0 @tigase @Muto @vecna @stevenroose we would need something liked signed offline device capabilities.

@0 @tigase @Muto @vecna @stevenroose if you use xep-30 to do feature discovery, the other device must be online. So you cannot send messages to offline devices if you want to depend on xep-30.

@vanitasvitae

Thanks for the clarification. That is correct, you'd have to wait until a pair of devices come online concurrently at least once in order to use encryption.

I can see what the rationale might have been for doing discovery via #PEP in this case. It is basically saying that it is not the device but the JID that supports encryption or not.

In this case, XEP-0030 could be redundant.

@tigase @Muto @vecna @stevenroose

@vanitasvitae @tigase @Muto @vecna @stevenroose

So what are the options?

* Mandate that encryption MUST include both in band and out of band data.

* Specify that encryption SHOULD include IB & OOB data. Clients that don't are still conforming and it's up to the parties to arrive at a solution.

* As above but MAY. Provide discovery mechanism.

* ???

@vanitasvitae @0 @Muto @vecna @stevenroose
We should probably list all problems that we would like to solve (currently we are only pondering OOB/IB data).

(and in 2 versions more we will arrive to a final version `OMEMO:4:EVER` ? ;-) )

@tigase @0 @Muto @vecna @stevenroose I hope that an OMEMO:2 will use SCE (XEP-420) for in-band data and comes with a proper solution for out-of-band data as well.

@tigase @0 @Muto @vecna @stevenroose maybe we could create a page in the @xmpp wiki for things to keep track of? I know there are some unofficial lists already, but collecting points in a central place would surely be helpful.

@vanitasvitae @tigase @0 @Muto @vecna @xmpp Sure! Another thing that would be cool if addressed in the spec is some kind of old-key-signs-new-key procedure. Where if you have a new device, your old device can notice and ask you to verify the new key and then provide a signature on it, so that any client that trusts the old key also trusts the new key.
I believe that would make OMEMO a lot more easy to use.

@stevenroose @tigase @0 @Muto @vecna @xmpp the would be nice, indeed. Although I'm not sure how to implement a reliable revocation mechanism.

Also, I'm not sure if this would belong into the base specification, or in an extension thereof.

@vanitasvitae @tigase @0 @Muto @vecna @xmpp Revocation can be done by removing the PEP node, no?
Yeah about extension/base spec, I don't have experience with XEP structuring etc. But given that a user should accept keys that are signed by a key they trust and other users expect that, things wouldn't work if this was an opt-in extension of OMEMO.

@stevenroose @tigase @0 @Muto @vecna @xmpp well, that would mean that the server could do revocation for you. 😶

@vanitasvitae @tigase @0 @Muto @vecna @xmpp Sure. IMO, if your server does that, you probably want to move out ASAP anyhow.

@tigase

> Would you say that sending encrypted messages without checking if the other party [supports encryption] is also OK

I'm not sure if I understood your question. Is my interpretation above correct?

It's not ideal from a bandwidth point of view, but AFAICT it's not a security issue and is effectively what already happens when you add a new device to an existing conversation: you receive data that you cannot decipher.

@Muto @vecna @stevenroose

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!