Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC2241: key verification in DMs #2241

Open
wants to merge 15 commits into
base: master
from

Conversation

@uhoreg
Copy link
Member

uhoreg commented Aug 22, 2019

uhoreg added 2 commits Aug 22, 2019
@uhoreg uhoreg changed the title [WIP] MSCxxxx: key verification in DMs [WIP] MSC2241: key verification in DMs Aug 22, 2019
@uhoreg uhoreg added the proposal label Aug 22, 2019
uhoreg added 2 commits Aug 24, 2019
@uhoreg

This comment has been minimized.

Copy link
Member Author

uhoreg commented Sep 5, 2019

@mscbot fcp merge

@mscbot

This comment has been minimized.

Copy link
Collaborator

mscbot commented Sep 5, 2019

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

Concerns:

  • I'd like to see this working in a client. resolved by #2241 (comment)
  • The question of m.relationship vs m.relates_to in MSC1849 should be resolved. (#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.

@uhoreg uhoreg changed the title [WIP] MSC2241: key verification in DMs MSC2241: key verification in DMs Sep 5, 2019
@turt2live turt2live self-requested a review Sep 5, 2019

Users might have multiple Direct Messaging rooms with other users. In this
case, clients will need to prompt the user to select the room in which they
want to perform the verification.

This comment has been minimized.

Copy link
@erikjohnston

erikjohnston Sep 9, 2019

Member

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)

This comment has been minimized.

Copy link
@uhoreg

uhoreg Sep 16, 2019

Author Member

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

This comment has been minimized.

Copy link
@turt2live

turt2live Nov 1, 2019

Member

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.

visible to other users in the room. However, key verification does not rely on
secrecy, so this will no affect the security of the key verification. This may
reveal to others in the room that Alice and Bob know each other, but this is
already revealed by the fact that they share a Direct Messaging room.

This comment has been minimized.

Copy link
@erikjohnston

erikjohnston Sep 9, 2019

Member

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?

This comment has been minimized.

Copy link
@uhoreg

uhoreg Oct 11, 2019

Author Member

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.

@turt2live turt2live added this to Review stages in Client-server r0.6 proposals Sep 10, 2019
@uhoreg uhoreg mentioned this pull request Oct 8, 2019
@uhoreg uhoreg requested a review from dbkr Oct 11, 2019
Copy link
Member

KitsuneRal left a comment

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

proposals/2241-e2e-verification-in-dms.md Outdated Show resolved Hide resolved
proposals/2241-e2e-verification-in-dms.md Outdated Show resolved Hide resolved
proposals/2241-e2e-verification-in-dms.md Outdated Show resolved Hide resolved
proposals/2241-e2e-verification-in-dms.md Outdated Show resolved Hide resolved
uhoreg and others added 2 commits Oct 23, 2019
Co-Authored-By: Kitsune Ral <Kitsune-Ral@users.sf.net>
Co-Authored-By: David Baker <dbkr@users.noreply.github.com>
…c into e2e_verification_in_dms
@uhoreg

This comment has been minimized.

Copy link
Member Author

uhoreg commented Oct 23, 2019

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

@uhoreg

This comment has been minimized.

Copy link
Member Author

uhoreg commented Oct 23, 2019

@turt2live turt2live self-requested a review Oct 23, 2019
Copy link
Member

richvdh left a comment

Generally looks good to me, though in the new world order it will need prototyping to get to FCP...


#### Requesting a key verification

To request a key verification, Alice will send an `m.room.message` event with the

This comment has been minimized.

Copy link
@richvdh

richvdh Oct 24, 2019

Member

It feels a bit sad that we're using m.room.message here. I guess it's for the benefit of clients which don't support this method, but maybe an alternative would be to send two events, one m.room.message for the fallback, which supporting clients can ignore, and another m.key.verification.request which actually starts the process

This comment has been minimized.

Copy link
@uhoreg

uhoreg Oct 24, 2019

Author Member

Yes, it's so that clients that don't support it will show something sensible. Sending two messages seems redundant, and you'd need some markup on the m.room.message so that supporting clients will know to ignore it, so it doesn't seem like much of a difference from just sticking the verification request payload in the m.room.message.

@richvdh

This comment has been minimized.

Copy link
Member

richvdh commented Oct 24, 2019

Ohh, there is an implementation! Is there an installation we can play with?

@uhoreg

This comment has been minimized.

Copy link
Member Author

uhoreg commented Oct 24, 2019

Ohh, there is an implementation! Is there an installation we can play with?

It's just in the js-sdk so far, without being hooked up to Riot yet. So the only thing that can be played with so far is the unit tests.

@richvdh

This comment has been minimized.

Copy link
Member

richvdh commented Oct 25, 2019

ok. I feel like an actual implementation in a client is a thing that I want to see before I'm happy to tick the fcp box.

@mscbot concern I'd like to see this working in a client.

proposals/2241-e2e-verification-in-dms.md Outdated Show resolved Hide resolved

Users might have multiple Direct Messaging rooms with other users. In this
case, clients will need to prompt the user to select the room in which they
want to perform the verification.

This comment has been minimized.

Copy link
@turt2live

turt2live Nov 1, 2019

Member

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.

@turt2live

This comment has been minimized.

Copy link
Member

turt2live commented Nov 1, 2019

thanks for answering the questions so quickly!

@mscbot reviewed

@uhoreg

This comment has been minimized.

Copy link
Member Author

uhoreg commented Nov 8, 2019

Ohh, there is an implementation! Is there an installation we can play with?

It is now in playable formm on riot.im/develop, if you enable the "Send verification requests in direct message" option in Labs

@bwindels

This comment has been minimized.

Copy link
Contributor

bwindels commented Nov 25, 2019

Some use case came up that currently isn't supported by this MSC.

In Riot, we want to always choose QR verification when accepting a verification request, so the client can show the QR code right after accepting without asking the user for a verification method. If the users can meet in person, they just have to scan the code and be done. If the users can't meet in person, they can hit a button to use SAS verification and continue that way.

One way of supporting this flow would be to accept the request twice: first with QR as a method, and then again with SAS as a method. The MSC doesn't say whether or not accepting a request multiple times is supported or not, but this feels like it is something that should probably be specified here.

Also, I don't think the requesting user can reliably tell which m.key.verification.start event was sent first over federation? If so, the second m.key.verification.start event should probably be an edit of the first (e.g. a m.replace relation referring to the first m.key.verification.start event).

Another way of supporting this could be to introduce an additional event (e.g. m.key.verification.ready) to communicate:

  1. the methods supported by the other party
  2. the fact that the other party is available to start the verification.

Then, if either client scans the QR code, it accepts the request with the QR method. This would mean that now also the party that sent the original verification request can also accept the request.

What do you think would be the cleanest way to support this @uhoreg ?

@richvdh

This comment has been minimized.

Copy link
Member

richvdh commented Nov 26, 2019

@mscbot resolve I'd like to see this working in a client.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.