From d34a2ed9dba681b6b4dca9703125fc69d1626dd6 Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Tue, 2 Dec 2025 18:08:04 -0500 Subject: [PATCH 1/3] initial version of sending unsolicited secret shares --- .../xxxx-secret-send-without-requestid.md | 74 +++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 proposals/xxxx-secret-send-without-requestid.md diff --git a/proposals/xxxx-secret-send-without-requestid.md b/proposals/xxxx-secret-send-without-requestid.md new file mode 100644 index 00000000000..eada5c850b8 --- /dev/null +++ b/proposals/xxxx-secret-send-without-requestid.md @@ -0,0 +1,74 @@ +# MSCxxx: Allowing `m.secret.send` without a prior `m.secret.request` + +[MSC1946](https://github.com/matrix-org/matrix-spec-proposals/pull/1946) +introduced the `m.secret.request` and `m.secret.send` events, which allow a +device to request a secret from another device, and for the other device to send +the secret to the first device. In that MSC, an `m.secret.send` must only be +sent as a response to `m.secret.request`; unsolicited `m.secret.send` events +were to be ignored. + +However, there are situations in which a device may want to send a secret to +other devices, without the secret being requested. For example, if a device +changes the private key for key backup, it can share the key with other devices +so that they can access the key backup. + +## Proposal + +The `request_id` property of an `m.secret.send` event is optional. +`m.secret.send` events may be sent without a corresponding `m.secret.request` +event, and if so, MUST be sent without an `request_id` property, but MUST +include a `name` property, which contains the name of the secret being shared. +`m.secret.send` events with a `request_id` property are handled as before. + +`m.secret.send` events without a `request_id` must only be accepted from +cross-signed devices belonging to the same user. In addition, the client MAY +prompt the user before accepting the `m.secret.send` event. The client MAY also +only accept certain secrets. For example, the client could accept the key +backup secret, but could require re-verification rather than accepting the +cross-signing secrets. + +## Potential issues + +Clients that do not implement this proposal will not accept `m.secret.send` +events without the `request_id` property, and so the event will have been sent +needlessly. However, having such events sent to old clients should not cause +any issues for the clients, as they should simply discard them as invalid, so it +will be as if the events were not sent at all. + +If a client is offline while a secret is changed multiple times, it will receive +multiple `m.secret.send` events, and will have to determine which one is the +current one. For the existing secrets, there are easy ways of determining which +secret "works". + +## Alternatives + +Rather than preemptively sending out a secret when it is changed, the user's +other clients could try to notice when a secret is changed, and then broadcast +an `m.secret.request` to all the user's other devices. However, this could +result in delays in obtaining the secret if the device that changed the secret +is not online when the request is sent out. As well, it could result in many +extra events being sent, since the requesting device does not know which device +it needs to request from, and so must broadcast `m.secret.request` events to all +the user's other devices. + +## Security considerations + +An attacker who takes control of a device could send out a secret that is +controlled by the attacker. For example, the attacker could create a new key +backup and send out the private key so that other clients will use the new +backup, allowing the attacker to read new keys uploaded to the key backup. +However, if the attacker has taken control of a device, it is likely that they +would have access to the existing secret, and so would not gain anything by +sending out a new secret. For this reason, `m.secret.send` events without a +`request_id` property MUST only be accepted from cross-signed devices, so that +the attacker cannot just create a new device and send out secrets. Clients can +also apply other mitigations such as prompting the user when a new secret is +received. + +## Unstable prefix + +None, since no new names are introduced. + +## Dependencies + +None. From 09e16f6e797db38926306fe4c8e5b94d1a193004 Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Wed, 3 Dec 2025 12:45:24 -0500 Subject: [PATCH 2/3] use MSC number --- ...thout-requestid.md => 4385-secret-send-without-requestid.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename proposals/{xxxx-secret-send-without-requestid.md => 4385-secret-send-without-requestid.md} (98%) diff --git a/proposals/xxxx-secret-send-without-requestid.md b/proposals/4385-secret-send-without-requestid.md similarity index 98% rename from proposals/xxxx-secret-send-without-requestid.md rename to proposals/4385-secret-send-without-requestid.md index eada5c850b8..847b2cc42a7 100644 --- a/proposals/xxxx-secret-send-without-requestid.md +++ b/proposals/4385-secret-send-without-requestid.md @@ -1,4 +1,4 @@ -# MSCxxx: Allowing `m.secret.send` without a prior `m.secret.request` +# MSC4385: Allowing `m.secret.send` without a prior `m.secret.request` [MSC1946](https://github.com/matrix-org/matrix-spec-proposals/pull/1946) introduced the `m.secret.request` and `m.secret.send` events, which allow a From 70c36f8949896eb0ecb4011b872f750cfec4466c Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Mon, 8 Dec 2025 10:07:53 -0500 Subject: [PATCH 3/3] use a different event name --- .../4385-secret-send-without-requestid.md | 70 ++++++++++--------- 1 file changed, 37 insertions(+), 33 deletions(-) diff --git a/proposals/4385-secret-send-without-requestid.md b/proposals/4385-secret-send-without-requestid.md index 847b2cc42a7..efae58d6afa 100644 --- a/proposals/4385-secret-send-without-requestid.md +++ b/proposals/4385-secret-send-without-requestid.md @@ -1,11 +1,11 @@ -# MSC4385: Allowing `m.secret.send` without a prior `m.secret.request` +# MSC4385: Pushing secrets to other devices [MSC1946](https://github.com/matrix-org/matrix-spec-proposals/pull/1946) introduced the `m.secret.request` and `m.secret.send` events, which allow a device to request a secret from another device, and for the other device to send the secret to the first device. In that MSC, an `m.secret.send` must only be -sent as a response to `m.secret.request`; unsolicited `m.secret.send` events -were to be ignored. +sent as a response to `m.secret.request`; a device has no way of sharing a +secret without it being requested. However, there are situations in which a device may want to send a secret to other devices, without the secret being requested. For example, if a device @@ -14,41 +14,45 @@ so that they can access the key backup. ## Proposal -The `request_id` property of an `m.secret.send` event is optional. -`m.secret.send` events may be sent without a corresponding `m.secret.request` -event, and if so, MUST be sent without an `request_id` property, but MUST -include a `name` property, which contains the name of the secret being shared. -`m.secret.send` events with a `request_id` property are handled as before. +We introduce a new event type, `m.secret.push`, which is used to sharing a +secret with other devices without waiting for a request. It MUST always be sent +encrypted. It contains the properties: -`m.secret.send` events without a `request_id` must only be accepted from -cross-signed devices belonging to the same user. In addition, the client MAY -prompt the user before accepting the `m.secret.send` event. The client MAY also -only accept certain secrets. For example, the client could accept the key -backup secret, but could require re-verification rather than accepting the -cross-signing secrets. +- `secret` (required): the contents of the secret (this is the same as the + `secret` property of the [`m.secret.send` + event](https://spec.matrix.org/v1.16/client-server-api/#msecretsend) event) +- `name` (required): the name of the secret (this is the same as the name + property of the + [`m.secret.request`](https://spec.matrix.org/v1.16/client-server-api/#msecretrequest) + event). + +`m.secret.push` events MUST only be accepted from cross-signed devices belonging +to the same user. In addition, the client MAY prompt the user before accepting +the `m.secret.push` event. The client MAY also only accept certain secrets. +For example, the client could accept the key backup secret, but could require +re-verification rather than accepting the cross-signing secrets. ## Potential issues -Clients that do not implement this proposal will not accept `m.secret.send` -events without the `request_id` property, and so the event will have been sent -needlessly. However, having such events sent to old clients should not cause -any issues for the clients, as they should simply discard them as invalid, so it -will be as if the events were not sent at all. +Clients that do not implement this proposal will not accept `m.secret.push`, and +so the event will have been sent needlessly. However, clients that do not +implement this proposal should ignore such events, so they will not cause any +problems for these clients. If a client is offline while a secret is changed multiple times, it will receive -multiple `m.secret.send` events, and will have to determine which one is the +multiple `m.secret.push` events, and will have to determine which one is the current one. For the existing secrets, there are easy ways of determining which secret "works". ## Alternatives -Rather than preemptively sending out a secret when it is changed, the user's -other clients could try to notice when a secret is changed, and then broadcast -an `m.secret.request` to all the user's other devices. However, this could -result in delays in obtaining the secret if the device that changed the secret -is not online when the request is sent out. As well, it could result in many -extra events being sent, since the requesting device does not know which device -it needs to request from, and so must broadcast `m.secret.request` events to all +Rather than pushing out a secret when it is changed, the user's other clients +could try to notice when a secret is changed, and then broadcast an +`m.secret.request` to all the user's other devices. However, this could result +in delays in obtaining the secret if the device that changed the secret is not +online when the request is sent out. As well, it could result in many extra +events being sent, since the requesting device does not know which device it +needs to request from, and so must broadcast `m.secret.request` events to all the user's other devices. ## Security considerations @@ -59,15 +63,15 @@ backup and send out the private key so that other clients will use the new backup, allowing the attacker to read new keys uploaded to the key backup. However, if the attacker has taken control of a device, it is likely that they would have access to the existing secret, and so would not gain anything by -sending out a new secret. For this reason, `m.secret.send` events without a -`request_id` property MUST only be accepted from cross-signed devices, so that -the attacker cannot just create a new device and send out secrets. Clients can -also apply other mitigations such as prompting the user when a new secret is -received. +sending out a new secret. For this reason, `m.secret.push` events MUST only be +accepted from cross-signed devices, so that the attacker cannot just create a +new device and push out secrets. Clients can also apply other mitigations such +as prompting the user when a new secret is received. ## Unstable prefix -None, since no new names are introduced. +Until this proposal is accepted, the name `io.element.msc4385.secret.push` +should be used rather than `m.secret.push` for the event name. ## Dependencies