Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-03-23 19:44:09 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

e2ee/device verification: move general error handling under framework

Browse source 
Most of the "Error and exception handling" section is generally
applicable to other verification methods besides SAS, so I moved those
bullet points under "Key verification framework".

Signed-off-by: Sumner Evans <sumner.evans@automattic.com>
This commit is contained in:
Sumner Evans 2024-05-27 18:03:05 -06:00
parent 49765e0e0a
commit 0872ec788a
No known key found for this signature in database
1 changed files with 25 additions and 19 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

44
content/client-server-api/modules/end_to_end_encryption.md
View file

@ -597,6 +597,30 @@ package naming convention.
{{% event event="m.key.verification.cancel" %}}
###### General key verification error handling
At any point the interactive verification can go wrong. The following describes
what to do when an error happens:
- Alice or Bob can cancel the verification at any time. An
`m.key.verification.cancel` message must be sent to signify the
cancellation.
- The verification can time out. Clients should time out a verification that
does not complete within 10 minutes. Additionally, clients should expire a
`transaction_id` which goes unused for 10 minutes after having last
sent/received it. The client should inform the user that the verification
timed out, and send an appropriate `m.key.verification.cancel` message to
the other device.
- When the same device attempts to initiate multiple verification attempts,
the recipient should cancel all attempts with that device.
- When a device receives an unknown `transaction_id`, it should send an
appropriate `m.key.verification.cancel` message to the other device
indicating as such. This does not apply for inbound
`m.key.verification.start` or `m.key.verification.cancel` messages.
- If the device receives a message out of sequence or that it was not
expecting, it should notify the other device with an appropriate
`m.key.verification.cancel` message.
##### Short Authentication String (SAS) verification
SAS verification is a user-friendly key verification process built off
@ -720,35 +744,17 @@ devices:
| |
```
###### Error and exception handling
###### SAS error handling
At any point the interactive verification can go wrong. The following
describes what to do when an error happens:
- Alice or Bob can cancel the verification at any time. An
`m.key.verification.cancel` message must be sent to signify the
cancellation.
- The verification can time out. Clients should time out a
verification that does not complete within 10 minutes. Additionally,
clients should expire a `transaction_id` which goes unused for 10
minutes after having last sent/received it. The client should inform
the user that the verification timed out, and send an appropriate
`m.key.verification.cancel` message to the other device.
- When the same device attempts to initiate multiple verification
attempts, the recipient should cancel all attempts with that device.
- When a device receives an unknown `transaction_id`, it should send
an appropriate `m.key.verification.cancel` message to the other
device indicating as such. This does not apply for inbound
`m.key.verification.start` or `m.key.verification.cancel` messages.
- If the two devices do not share a common key share, hash, HMAC, or
SAS method then the device should notify the other device with an
appropriate `m.key.verification.cancel` message.
- If the user claims the Short Authentication Strings do not match,
the device should send an appropriate `m.key.verification.cancel`
message to the other device.
- If the device receives a message out of sequence or that it was not
expecting, it should notify the other device with an appropriate
`m.key.verification.cancel` message.
###### Verification messages specific to SAS