MSC2241: Key verification in DMs

[uhoreg]

Rendered

Fixes element-hq/element-web#10493

[uhoreg]

@mscbot fcp merge

[mscbot]

Team member @uhoreg has proposed to merge this. The next step is review by the rest of the tagged people:

• @KitsuneRal
• @anoadragon453
• @ara4n
• @dbkr
• @erikjohnston
• @richvdh
• @turt2live
• @uhoreg

Concerns:

• I'd like to see this working in a client. resolved by MSC2241: Key verification in DMs #2241 (comment)
• The question of m.relationship vs m.relates_to in MSC1849 should be resolved. resolved by MSC2241: Key verification in DMs #2241 (comment)

Once at least 75% of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[erikjohnston]

Presumably this works fine if a client gets a key verification method via a non-DM room? One of the things with the current canonical DM proposal is that it doesn't actually guarantee there will be a single DM room at any given point (given glare and upgrading rooms and servers not agreeing etc)

[uhoreg]

Yes, nothing here actually requires the room to be a DM, but clients should use a DM to avoid cluttering unrelated rooms.

[turt2live]

One of the things with the current canonical DM proposal is that it doesn't actually guarantee there will be a single DM room at any given point (given glare and upgrading rooms and servers not agreeing etc)

This is a bug in the proposal intending to be fixed. There will only ever be one DM by the time the proposal gets merged.

[erikjohnston]

Does this mean that clients have to be careful to ignore key verification messages not "directed" at them? Is there a situation where the DMness of a room is inconsistent between servers? E.g. you are in a 3-way room that the one of the other participants thinks is a DM room, but you don't, what happens?

[uhoreg]

I think that clients should be able to respond to requests in non-DM rooms. So if clients don't agree on which rooms are DM, it should still work. If you try to do a verification in Matrix HQ, you'll just annoy everyone and someone will tell you to do it elsewhere.

[KitsuneRal]

I very much like the idea of the MSC, but the chosen event definition looks unnecessarily heavy to me.

[richvdh]

well, as @deepbluev7 pointed out, I was being a massive crank, so

@mscbot fcp merge

[mscbot]

An FCP proposal is already in progress.

[richvdh]

oh I'm still being a crank. The outstanding concern is:

The question of m.relationship vs m.relates_to in MSC1849 should be resolved.

it feels like we've resolved this by doing nothing about it. Changing the decision now is going to be a major upheaval. @uhoreg can we resolve this?

[kevincox]

Why do we need a three-way handshake? Once Alice starts that verification why does Bob need a m.key.verification.ready? Can he not just jump to m.key.verification.start?

[deepbluev7]

It allows negotiating a common set of methods and then picking your preferred one. A client needs to send all methods it supports in start, but it may prefer a specific one, if supported. Then the other client can reply with the ones it prefers in "ready" and then the first client can choose its preferred method. If you reduce that to 2 steps, Either the first client sends it preferred methods instead of all of them, which may lead to no matching methods or it the second client picks one that is suboptimal for the first clients screen. Having 3 steps avoids that pretty much.

[kevincox]

I see. Would it make sense to make that a bit more clear? It may be helpful to prove a high-level overview of the flow somewhere. Maybe the following can be inserted:

At a high level a successful verification looks like this:

1. Alice sends a m.room.message event to the room specifying the target and includes supported methods and a fallback message for clients lacking support.
2. Bob accepts the verification request with a m.key.verification.ready event and includes their supported methods.
3. Either Alice or Bob selects a method and initiates the verification with a m.key.verification.start event.
4. Verification proceeds according to the selected method.
5. Both Alice and Bob send a m.key.verification.done event.

I think this gives a quick overview and can help speeding up the rest of the concrete details.

[uhoreg]

The reasoning for m.key.verification.ready is given in #2366 so I don't think we need to repeat it here.

[uhoreg]

I've decoupled this MSC from the aggregations MSC by just saying that we're basing the property shape on what the aggregations MSC currently says, but we're going to be independent. If the aggregations MSC changes the property shape in the future, and we really want to re-sync, then we can introduce a new MSC to do so.

So...

@mscbot resolve The question of m.relationship vs m.relates_to in MSC1849 should be resolved.

[mscbot]

Unknown concern 'The question of m.relationship vs m.relates_to in MSC1849 should be resolved.'.

[mscbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[anoadragon453]

(Concern resolved manually)

[mscbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

[uhoreg]

Merged! 🎉

[bwindels]

For posterity, I've written #3267 to define how relations are used in this MSC (e.g. rel_type of m.reference)