mirror of
https://github.com/matrix-org/matrix-spec
synced 2026-03-23 19:44:09 +01:00
e2ee/device verification: move general error handling under framework
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:
parent
49765e0e0a
commit
0872ec788a
|
|
@ -597,6 +597,30 @@ package naming convention.
|
||||||
|
|
||||||
{{% event event="m.key.verification.cancel" %}}
|
{{% 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
|
##### Short Authentication String (SAS) verification
|
||||||
|
|
||||||
SAS verification is a user-friendly key verification process built off
|
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
|
At any point the interactive verification can go wrong. The following
|
||||||
describes what to do when an error happens:
|
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
|
- 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
|
SAS method then the device should notify the other device with an
|
||||||
appropriate `m.key.verification.cancel` message.
|
appropriate `m.key.verification.cancel` message.
|
||||||
- If the user claims the Short Authentication Strings do not match,
|
- If the user claims the Short Authentication Strings do not match,
|
||||||
the device should send an appropriate `m.key.verification.cancel`
|
the device should send an appropriate `m.key.verification.cancel`
|
||||||
message to the other device.
|
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
|
###### Verification messages specific to SAS
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue