MSC3013: Encrypted Push by Sorunome · Pull Request #3013 · matrix-org/matrix-spec-proposals

Sorunome · 2021-02-17T12:15:33Z

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

proposals/3013-encrypted-push.md

flumeware · 2021-02-19T23:36:56Z

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

proposals/3013-encrypted-push.md

kegsay · 2021-04-03T20:00:39Z

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 · 2021-04-06T08:46:41Z

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 · 2021-04-07T11:40:49Z

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.

proposals/3013-encrypted-push.md

a flag to the http pusher kind

anoadragon453 · 2021-12-07T10:20:35Z

Removing the needs-implementation label given the linked PRs.

anoadragon453 · 2021-12-07T10:21:48Z

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?

proposals/3013-encrypted-push.md

dbkr · 2021-12-07T11:40:43Z

proposals/3013-encrypted-push.md

+This is the same algorithm used currently in the unstable spec for megolm backup, as such it is
+comptible with libolms PkEncryption / PkDecryption methods.


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).

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.

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

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

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

Which will be used in MSC4388.

BillCarsonFr · 2023-08-31T12:13:41Z

proposals/3013-encrypted-push.md

@@ -0,0 +1,209 @@
+# MSC3013: Encrypted Push


Can these details (seen in other comments) be written somewhere in the MSC?
For non-e2ee room it would allow to put content of the notification and then avoid additional http call.
But for e2e room it might not help as anyhow the client might need to sync (additional http call) the to_devices to get the megolm key.
On the benefit side it could allow to encrypt room_id/event_id metada, but one could arg that we could just remove them from the payload given that most client will sync on push anyhow.
Some potential problems: Not all push do a notification; clients have to process the push rules locally to know if it should notify.

p1gp1g · 2024-07-12T13:59:04Z

Posting here, I commented on a resolved comment..

A (robust IMO) alternative would be to add a webpush pusher kind directly.

The advantage of using web push directly:

This is E2EE
It supports VAPID
This is a standard:
- Libraries are already available
- Has been reviewed and acknowledged by experts
- Webpush to APNS/FCM/HMS gateways already exist
- The ecosystem should tend to use this instead of other custom protocols
This can provide push notifications without gateway to
- Web app and desktop app
- Android apps using UnifiedPush
- Maybe other ? We have seen apple moving a lot into web push support
This doesn't have a requirement on the path (making https://github.com/matrix-org/matrix-spec-proposals/pull/2970/files obsolete)

Edit:

To add a bit more context, the specifications already need to be updated:

hydrogen, and sygnal (and very probably element web, not searched yet) goes over the specifications because it misses informations required by webpush:
- They use endpoint, and auth in the PusherData (hydrogen, sygnal), and the specs let understand that only url and format are allowed (specs)

PS: I'm OK to write an MSC for webpush pushkind.

anoadragon453 · 2024-07-17T14:05:48Z

I think an MSC for a web push pusher would be useful down the road. Feel free to write it up while you're thinking about it @p1gp1g.

p1gp1g · 2024-08-01T15:56:10Z

Here it is: #4174

richvdh · 2026-03-17T17:03:01Z

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

mscbot · 2026-03-17T17:03:05Z

tulir · 2026-03-17T17:09:50Z

MSC4174 doesn't replace this properly due to #4174 (comment). Web push only supports P-256, but if we want to actually send message contents over push, we should use better crypto than that (although I'm not sure if the crypto suggested in this MSC is good either)

p1gp1g · 2026-03-17T19:03:35Z

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 · 2026-03-17T19:20:28Z

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

p1gp1g · 2026-03-17T19:22:46Z

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

Johennes · 2026-03-18T06:49:49Z

proposals/3013-encrypted-push.md

+# MSC3013: Encrypted Push
+
+Push notifications have the problem that they typically go through third-party gateways in order to
+be delivered, e.g. FCM (Google) or APNs (Apple) and an app-specific gateway (sygnal). In order to


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 · 2026-03-18T07:07:42Z

proposals/3013-encrypted-push.md

+}
+```
+
+Now, when the homeserver pushes out the message, it is to perform the `notification` dict as with the


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 · 2026-03-18T07:18:45Z

proposals/3013-encrypted-push.md

+proper way to go here, as, in the case of the server being compromised, there is no need to re-negotiate
+a new key to encrypt the push message.
+
+## Unstable prefix


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

Johennes · 2026-03-18T07:22:52Z

proposals/3013-encrypted-push.md

+}
+```
+
+## Potential issues


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 · 2026-03-18T07:24:07Z

proposals/3013-encrypted-push.md

+The field `public_key` is required. This key is an unpadded base64-encoded curve25519
+public key. This new field is not to be added to the actual push payload being sent to push gateways.
+
+The field `counts_only_type` is an optional enum which denotes how push frames should handle counts-only


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 · 2026-03-24T17:30:33Z

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 · 2026-03-24T19:40:05Z

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.

add MSC

e835d5e

Cadair reviewed Feb 17, 2021

View reviewed changes

proposals/3013-encrypted-push.md Outdated Show resolved Hide resolved

proposals/3013-encrypted-push.md Outdated Show resolved Hide resolved

finish unfinished sentence

c57fd71

anoadragon453 added kind:feature MSC for not-core and not-maintenance stuff proposal A matrix spec change proposal proposal-in-review push labels Feb 17, 2021

dbkr reviewed Feb 17, 2021

View reviewed changes

proposals/3013-encrypted-push.md Outdated Show resolved Hide resolved

dbkr reviewed Feb 17, 2021

View reviewed changes

proposals/3013-encrypted-push.md Outdated Show resolved Hide resolved

Sorunome added 2 commits February 17, 2021 14:53

fix typo

9677a5b

update example

24686ca

dbkr reviewed Feb 17, 2021

View reviewed changes

proposals/3013-encrypted-push.md Show resolved Hide resolved

add alternative suggestion

c46a21c

Sorunome mentioned this pull request Feb 18, 2021

MSC3014: HTTP Pushers for the full event with extra rooms information #3014

Open

specify correct public key

7b45e05

Sorunome commented Feb 23, 2021

View reviewed changes

proposals/3013-encrypted-push.md Show resolved Hide resolved

kevincox reviewed Apr 9, 2021

View reviewed changes

proposals/3013-encrypted-push.md Outdated Show resolved Hide resolved

proposals/3013-encrypted-push.md Show resolved Hide resolved

turt2live added the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label Jun 8, 2021

turt2live force-pushed the old_master branch from e895827 to dca99ee Compare August 30, 2021 22:34

Sorunome added 2 commits October 25, 2021 15:33

change the encrypted stuff to not be a new pusher kind, but instead

d43e5ff

a flag to the http pusher kind

add advertisement in /versions endpoint

0fe441f

Sorunome mentioned this pull request Dec 6, 2021

Add encrypted http pusher (MSC3013) matrix-org/synapse#11512

Open

4 tasks

anoadragon453 removed the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label Dec 7, 2021

dbkr reviewed Dec 7, 2021

View reviewed changes

BillCarsonFr requested changes Aug 31, 2023

View reviewed changes

clokep mentioned this pull request Sep 21, 2023

MSC4028: Push all encrypted events except for muted rooms #4028

Open

matrixbot mentioned this pull request Dec 21, 2023

Add encrypted http pusher (MSC3013) element-hq/synapse#11512

Open

4 tasks

p1gp1g mentioned this pull request Jul 12, 2024

Use matrix.org's push gateway by default with UnifiedPush element-hq/element-x-android#3185

Open

tulir removed the proposal-in-review label Sep 9, 2025

MadLittleMods mentioned this pull request Jan 12, 2026

MSC4174: add support for WebPush pusher kind element-hq/synapse#17987

Open

3 tasks

mscbot added proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the final comment period. disposition-close labels Mar 17, 2026

turt2live added this to Spec Core Team Workflow Mar 17, 2026

github-project-automation bot moved this to Tracking for review in Spec Core Team Workflow Mar 17, 2026

turt2live added the 00-weekly-pings Tracking for weekly pings in the SCT office. 00 to make it first in the labels list. label Mar 17, 2026

turt2live moved this from Tracking for review to Ready for FCP ticks in Spec Core Team Workflow Mar 17, 2026

richvdh mentioned this pull request Mar 17, 2026

MSC4174: Web push #4174

Open

Johennes reviewed Mar 18, 2026

View reviewed changes

turt2live removed the unresolved-concerns This proposal has at least one outstanding concern label Mar 23, 2026

		This is the same algorithm used currently in the unstable spec for megolm backup, as such it is
		comptible with libolms PkEncryption / PkDecryption methods.

	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

	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

Conversation

Sorunome commented Feb 17, 2021 • edited by turt2live Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

flumeware commented Feb 19, 2021

Uh oh!

Uh oh!

kegsay commented Apr 3, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Cadair commented Apr 6, 2021

Uh oh!

kegsay commented Apr 7, 2021

Uh oh!

Uh oh!

Uh oh!

anoadragon453 commented Dec 7, 2021

Uh oh!

anoadragon453 commented Dec 7, 2021

Uh oh!

dbkr left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BillCarsonFr Aug 31, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

p1gp1g commented Jul 12, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

anoadragon453 commented Jul 17, 2024

Uh oh!

p1gp1g commented Aug 1, 2024

Uh oh!

richvdh commented Mar 17, 2026

Uh oh!

mscbot commented Mar 17, 2026 • edited by uhoreg Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tulir commented Mar 17, 2026

Uh oh!

p1gp1g commented Mar 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tulir commented Mar 17, 2026

Uh oh!

p1gp1g commented Mar 17, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

richvdh commented Mar 24, 2026

Uh oh!

uhoreg commented Mar 24, 2026

Uh oh!

Sorunome commented Feb 17, 2021 •

edited by turt2live

Loading

kegsay commented Apr 3, 2021 •

edited

Loading

BillCarsonFr Aug 31, 2023 •

edited

Loading

p1gp1g commented Jul 12, 2024 •

edited

Loading

mscbot commented Mar 17, 2026 •

edited by uhoreg

Loading

p1gp1g commented Mar 17, 2026 •

edited

Loading