MSC3013: Encrypted Push

[Sorunome]

Rendered

Signed-off-by: Sorunome mail@sorunome.de
Signed-off-by: Sorunome sorunome@famedly.com

Synapse PR: matrix-org/synapse#11512
FamedlySDK PR: https://gitlab.com/famedly/company/frontend/famedlysdk/-/merge_requests/868
Hedwig PR: https://gitlab.com/famedly/company/backend/services/hedwig/-/merge_requests/41

---

SCT Stuff:

FCP call

FCP close tickyboxes

[flumeware]

Hi

1. Generate an ephemeral curve25519 key, and perform an ECDH with the ephemeral key and the backup's
   public key to generate a shared secret. The public half of the ephemeral key, encoded using unpadded
   base64, becomes the `ephemeral` property of the new payload.

Should backup's public key be pusher's public key?

Thanks

[kegsay]

MSC 3079: Low Bandwidth CS API may be an alternative to this as it makes it viable to rely on /sync for push notifications directly as it is made bandwidth efficient.

[Cadair]

I think this and #3079 are likely to be complementary. If you are already using your platforms push provider running a permanent background process is still going to be more expensive than using the push provider, no matter how well optimised it is. #3979 with the extra work to add sync filters just for events which trigger push is a good solution to if you don't have (or don't want) and untrusted push provider.

[kegsay]

Indeed, they can be complementary but at the cost of an increased API surface. If you don't trust your push provider, that has knock on concerns though. Malicious push providers can do more subtle attacks than just sniff the message (e.g delay the delivery) so the point the provider is untrusted then really you shouldn't be using it at all.

[anoadragon453]

Removing the needs-implementation label given the linked PRs.

[anoadragon453]

Have put this in the "initial review" column on the SCT Backlog board to get eyes on it, though it may already be under the watchful purview of @dbkr. Feel free to take it off the board if you want to re-claim it Dave.

[dbkr]

This does add significant complexity (especially because it means Homeservers now have to do elliptic curve crypto too) but it does slot nicely into the gap for more secure (and/or more efficient) push in non-e2e rooms.

Would suggest the next step here is for someone with a crypto hat on to review the crypto side of it. It sounds like it would be quite heavyweight, equivalent to establishing a new megolm session per message?

[dbkr]

Note that we're now moving away from this though, towards symmetric encryption for key backup. It would also be good to have some words on why this encryption scheme was chosen & what cryptographic properties it gives (and doesn't give).

[Sorunome]

as far as soru is aware the PkEncryption / PkDecryption was also used for asymmetric SSSS, and it seems like a good idea to have some go-to symmetric / asymmetric algorithms to use for the matrix world, though that is obviously beyond the scope of this PR.

[Sorunome]

If you meant symmetric vs asymmetric cryptography, there is a paragraph on that under "Security considerations"

[Sorunome]

Another thing to note is that libolms PkEncryption / PkDecryption actually has a bug where it calculates the mac wrong (which soru discovered while working on encrypted push, uhoreg is aware about and said it is ok to talk about publicly as it only affects data integrity and not security itself), so until libolm gets fixed in that regard implementations need to do their own PkDecryption anyways

[poljar]

See my comment about HPKE here: #3013 (comment).

Which will be used in MSC4388.

[p1gp1g]

if we want to actually send message contents over push

To clarify a bit: the content of E2EE encrypted messages are E2EE with the protocol supported by matrix (Olm/Megolm/MLS potentially), we are talking about metadata only here

[tulir]

The goal of this MSC appears to be combining with #2782 to send full event content in pushes, not only metadata.

[p1gp1g]

In E2EE communications, the full content send via push notification is encrypted content and we only encrypt its metadata on top of that

[Johennes]

Suggested change

	be delivered, e.g. FCM (Google) or APNs (Apple) and an app-specific gateway (sygnal). In order to
	be delivered, e.g. FCM (Google) or APNs (Apple) and an app-specific gateway (such as [Sygnal](https://github.com/element-hq/sygnal)). In order to

[Johennes]

Maybe it's just me but "perform" strikes me as slightly confusing here.

Suggested change

	Now, when the homeserver pushes out the message, it is to perform the `notification` dict as with the
	Now, when the homeserver pushes out the message, it is to construct the [`notification`](https://spec.matrix.org/v1.17/push-gateway-api/#post_matrixpushv1notify_request_notification) dict as with the

[Johennes]

I think you also need vendor prefixes for the various new properties such as public_key?

[Johennes]

The maximum payload size on both APNS and FCM seems to be 4096 bytes which might be exceeded based on the size of the event contained in the notification. This is already a problem today when not using event_id_only but I assume it's somewhat aggravated here since encryption will increase the overall payload size?

[Johennes]

It's possibly just me but I'm finding the term "push frame" slightly irritating and I haven't met this terminology elsewhere yet. Can we not just say "push notification"?

[richvdh]

Proposing this for closure, since MSC4174 claims to replace it and is proposed for FCP. If anyone feels like this shouldn't be closed once MSC4174 is merged, please say so.

@mscbot fcp close

It's unclear that MSC4174 does fully replace this MSC; however this MSC appears to be without an owner and has some substantial concerns. So I'm going to leave the FCP close proposal in place.

[uhoreg]

I do not believe that MSC4174 replaces this, as we do not want to use the encryption scheme presented there with other push methods (which we are only accepting in MSC4174 because it comes as part of the Web Push bundle of standards and implementations). However, we also will want to use a different encryption scheme than what is currently presented here, and at this point, it's probably better to start with a new MSC when we're ready to define how to do that, so I agree with FCP closing at this point.

[ara4n]

I believe that Gematik's TI-Messenger spec may use this (at least in the past): https://www.google.com/search?q=site%3Agematik.de+msc3013

Meanwhile, the actual concept (speed up sync by putting event payloads over APNS/FCM - but encrypt the payload to stop Apple/Google being able to see it) doesn't feel unreasonable.

As others have said, MSC4174 is not a direct replacement for this.

So, instead, I suggest we talk to Gematik first before unintentionally rugpulling stuff they consider important. I suggest we cancel the FCP close meanwhile.

[ara4n]

@mscbot concern does TI-Messenger still depend on this? We don't want to close MSCs without a future plan for direction if folks have been building on them.

[richvdh]

Gematik have confirmed out-of-band that TI-Messenger does not depend on this.

@mscbot resolve does TI-Messenger still depend on this? We don't want to close MSCs without a future plan for direction if folks have been building on them.

[mscbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[mscbot]

The final comment period, with a disposition to close, as per the review above, is now complete.