[API] Message layer security for end to end encryption

[erkinalp]

Mesage Layer Security is a cryptography protocol by IETF that is designed to transport end to end encrypted messages over untrusted intermediaries. This is going to be the basis of end-to-end encrypted channels (#322).

Protocol: https://datatracker.ietf.org/doc/html/draft-ietf-mls-protocol Architecture: https://datatracker.ietf.org/doc/html/draft-ietf-mls-architecture Independent analysis: https://eprint.iacr.org/2021/1083.pdf

[TheArcaneBrony]

1) its a draft 2) its expired

if you can link to an actual RFC thatd be cool

AKA: its non-standard and it wouldnt make any sense due to discord client compatibility, with no way of implementing it there

[SamuelScheit]

Fosscord is backwards not forwards compatible, we will add features that will not work with the discord client, but we'll not break it

[TheArcaneBrony]

Well yes, but what I was trying to say is that if they use the discord endpoints, it'd essentially bypass it anyways

[erkinalp]

and it wouldnt make any sense due to discord client compatibility, with no way of implementing it there

I have already figured out a way to send E2EE messages that would not break the unsupported clients, but would make skip over them.

Well yes, but what I was trying to say is that if they use the discord endpoints, it'd essentially bypass it anyways

E2EE we are going to do is over the message content, embeds, attachments, and components, and channel description if present, not over the other metadata.

[TheArcaneBrony]

and then youll be dealing with broken conversation flow, as discord clients wouldnt be able to see messages sent from non-discord clients

[SamuelScheit]

we could send the encrypted data as additional field

[SamuelScheit]

@TheArcaneBrony yes thats how E2EE works, if you enable it

[TheArcaneBrony]

and set the message text to "[Content unavailable]" i guess?

[erkinalp]

We thought we would set a pointer to encrypted content (in order to be able to combine E2EE and edit histories together) in the content field, and the client would send the content as a form data during posting.

and then youll be dealing with broken conversation flow, as discord clients wouldnt be able to see messages sent from non-discord clients

That is the point of E2EE though, if you cannot retrieve the decryption key, you are supposed to be unable to decrypt it. And mixed E2EE/plaintext is going to be dealt with by setting a channel type that unsupported clients would not treat as a viewable channel, and making it ill-formed to send a plaintext message to an E2EE channel.

[DiegoMagdaleno]

Please explain and provide examples on how this would be used, where it would be implemented, and how it would be implemented on Discord.

While your RFCs and PDFs are helpful for theory, you're leaving all the work to the FOSScord maintainers to implement this feature, while not being clear on how this would work.

Please be more clear about how this EE2E would work, provide diagrams, examples, or even a proof of concept.

Else this might be discussed with the FOSScord team, to decide which EE2E method works best for us, and implemented by the FOSScord team.

[erkinalp]

Please explain and provide examples on how this would be used, where it would be implemented, and how it would be implemented on Discord.

The client will send the message as a multipart form data, just like it does with attachments, and will provide the ciphertext of the content fields (content, components, attachments, embeds) as form fields. Such messages are purposefully incompatible with Discord's own clients (because discord.com does not have E2EE) but third party clients and bots could add support for them easily. Bots and third party clients could also use encryption broker libraries in case they do not want to handle encrypted messages by themselves, like ones existing for Jitsi, XMPP, Signal, Telegram and Matrix. More details, such as key establishment, key rotation and forward/future secrecy considerations, to come later.