One unverified device is able to "verify" another, but afterwards both devices continue to appear as unverified

[DMRobertson]

Steps to reproduce

This is a report on behalf of @linneanikell of unhelpful device verification behaviour we observed last week. Apologies for a lack of detail. I've filed it in Element-web, but it's not clear to me where the root cause is, e.g. there could be

• a problem in something common to element-web and element-ios
• independent problems in both element-web and element-ios
• some kind of server-side logic problem too.

With that said...

Linnea has four physical devices, each of which had a Matrix client installed.

1. Windows 11 Laptop, using Element Desktop
2. New iPhone, using Element iOS
3. Old Laptop
4. Old Phone

Opening Element on both physical devices 1 and 2, we could see this four list of (matrix) devices. Both devices considered themselves to be unverified in the "security and privacy" sections of their settings. Linnea and myself tried several times to remedy this by verifying them as follows:

• From device 1, request verification.
• On device 2, receive a notification corresponding to the verification request. Accept it.
• Complete the verification, by either scanning device 1's QR code using device 2? Or by confirming on both devices that they had a matching emoji sequence.
• The verification flow completes. However, both devices still appear as unverified.

The same occurs if you swap the devices (requesting verification on device 2 and completing verification on device 1).

Outcome

To quote @duxovni:

If two unverified devices "verify" each other, that won't actually accomplish anything and the devices will still be unverified, because they can't actually do cross-signing; really the UI shouldn't allow that scenario to begin with
the bug is that the UI allowed that to happen at all
basically, neither device is actually in a position to convincingly vouch for the other one

It's not clear to me if the clients are able to know if they can vouch for the device requesting verification. Nor is it obvious to me if the server knows that either. I am mainly reporting this so that the failure mode is written down somewhere.

What did you expect?

I'm not sure if verification requests are targeted at one specific device. If so, clients should prevent users from making verification requests.

If not (and all devices are notified of the verification request), client 2 should display a notification dialogue explaining that it can't meaningfully vouch for client 1. (I think not acknowledging the request would make seem broken to a user.

(To be explicit: I am extremely ignorant of the cryptography involved here and don't understand the underlying machinery. This issue is all about "I have an ugly red shield/warning in the UI and I want to make it go away".)

What happened instead?

Verification procedure completed successfully, but appeared broken because both devices appeared unverified.

Operating system

Windows 11

Application version

No response

How did you install the app?

No response

Homeserver

matrix.org

Will you send logs?

No (Linnea and I tried to rageshake from her iOS device but failed. Perhaps reach out to her for logs if they're useful.)

[duxovni]

To add more detail: This is a client-side bug that, as far as I know, is present on Element Web, iOS, and Android. The correct behavior that needs to be implemented is the following:

• When client A receives a to-device message from client B requesting verification, client A should check whether it itself is cross-signed (this is easy to do, see Add method for checking whether our other devices are cross-signed, even when this device isn't matrix-org/matrix-js-sdk#2288). If client A isn't cross-signed, then it won't be able to usefully cross-sign B, so it should ignore the request and not display any notification to the user.
  • Alternatively, client A could present a message explaining that it can't verify client B, but I think a more useful behavior would be for client B to display a list of devices that can verify it, so the user won't look for the verification popup on client A in the first place. If client A does display a notification, it should also include a list of other devices to look at.
• If the user is attempting to verify client A, and none of the user's other devices are verified, then the verification dialog shouldn't present "verify with another device" as an option. This was fixed in Element Web in Fix problems with verification dialog matrix-org/matrix-react-sdk#6811 , I'm not sure what the status is on other platforms.

[duxovni]

• When client A receives a to-device message from client B requesting verification, client A should check whether it itself is cross-signed (this is easy to do, see Add method for checking whether our other devices are cross-signed, even when this device isn't matrix-org/matrix-js-sdk#2288). If client A isn't cross-signed, then it won't be able to usefully cross-sign B, so it should ignore the request and not display any notification to the user.
  • Alternatively, client A could present a message explaining that it can't verify client B, but I think a more useful behavior would be for client B to display a list of devices that can verify it, so the user won't look for the verification popup on client A in the first place.

Worth noting: this should also apply to cross-signing requests received from other users, since an unverified device can't usefully respond to those either. In that scenario, displaying a message like "Bob sent us a verification request, open one of your verified devices ("Alice's iPhone", "Element Desktop", ...) in order to verify Bob" is probably the way to go.

[richvdh]

Duplicate of #27655 I think?

[richvdh]

Duplicate of #27655