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

Spec a way for a source to change the Matrix user it uses to publish information #21

Open
wants to merge 13 commits into
base: master
from

Conversation

Projects
None yet
2 participants
@vabd
Copy link
Member

vabd commented Jan 11, 2019

Resolves #6

@vabd vabd requested a review from Informo/informo-core-team Jan 11, 2019

previous user from it, and adding the new one to it. The signature associated
with the new user **must** be generated from the new user's registration event.
Client implementations **should** consider a trust authority not updating its
list with the source's new user as if it stopped trusting it.

This comment has been minimized.

@GordonF42

GordonF42 Jan 16, 2019

Member

I think this is hard to enforce and potentially dangerous: If an attacker registers deceptive source with a prev_id pointing to a legit source, TAs must not update their list with the new deceptive users, and the legit source should still be trusted as if nothing happened.

The only way I see for a TA to detect if a source has changed its user, is by contacting or being contacted by the source with other communication tools.

This comment has been minimized.

@vabd

vabd Jan 16, 2019

Member

I removed lines 99 and 100.


In such an event, the source or subsource **must** publish a new registration
event from its new Matrix user with the `prev_id` key having its previous user's
ID as its value.

This comment has been minimized.

@GordonF42

GordonF42 Jan 16, 2019

Member

I think you should add a matrix event ID alongside prev_id, in order to invalidate events from the compromised source after a given date (or event in this case), while keep using the older ones.

This comment has been minimized.

@GordonF42

GordonF42 Jan 16, 2019

Member

Maybe also add a reason, to let the source explain why they changed their account

This comment has been minimized.

@vabd

vabd Jan 16, 2019

Member

I added a prev_event key. Regarding the reason, we agreed irl it wasn't needed and would add unnecessary complexity.

@@ -189,6 +220,7 @@ Matrix](https://matrix.org/docs/projects/try-matrix-now.html#client-sdks).
"owner": {
"en": "ACME News Group"
},
"prev_id": "@acmenews:badserver.com",

This comment has been minimized.

@GordonF42

GordonF42 Jan 16, 2019

Member

There's a tab character here instead of spaces, and at other places too

This comment has been minimized.

@vabd

vabd Jan 16, 2019

Member

Fixed (everywhere, hopefully)

@vabd vabd requested a review from Informo/informo-core-team Jan 16, 2019

| `sig_algo` | `string` | x | Algorithm the source will use to cryptographically sign its articles. 🔧 |
| `sig_keys` | `[string]` | x | Public keys the source will use to cryptographically sign its articles. 🔧 |
| `prev_id` | `string` | | Matrix user ID of the Matrix user this source previously used to publish information. See [below](#change-of-matrix-user). |
| `prev_event` | `string` | | ID of the latest event published by the source's previous user. Only valid if `prev_id` is set to a non-empty string. See [below](#change-of-matrix-user). |

This comment has been minimized.

@GordonF42

GordonF42 Jan 19, 2019

Member

prev_id and prev_event might be better in a separated key, like previous: {id: "@acmenews:badserver.com", event: "!xxxxx:badserver.com"}

Client implementations **should** consider a trust authority not updating its
list with the source's new user as if it stopped trusting it.

Client implementations **should** define a threshold for linking a source to its

This comment has been minimized.

@GordonF42

GordonF42 Jan 19, 2019

Member

I'd say "can", since very suspicious/protective clients should not implement any threshold. It's just a comfort feature, in order to require less manual validations.

I can also think of another client implementation that would have two "levels of trusting" the user can chose when trusting a TA: "ultimate" would synchronize TA properties/user changes with the client storage silently, while "normal" would require either a custom threshold (trusted by one ultimate TA, or "x" normal TAs, or "y" percent of normal TAs) or manual validation in order to synchronize the changes.

This comment has been minimized.

@GordonF42

GordonF42 Jan 19, 2019

Member

IMHO it's the client developers' role to decide how to balance usability versus security, not the spec's role. The threshold thing is more a client UX design implementation issue.
We'll probably need to discuss about this on voice chat :)

This comment has been minimized.

@vabd

vabd Jan 19, 2019

Member

Makes sense.

Show resolved Hide resolved content/information-distribution/source.md Outdated
source's previous user in a trust authority's list of trustworthy sources
**must** be considered as a reference to the new user (with the exception of the
cryptographic check on the source's registration, which is still done using the
registration event published by the previous user).

This comment has been minimized.

@GordonF42

GordonF42 Jan 19, 2019

Member

a reference to the source's previous user in a trust authority's list of trustworthy sources must be considered as a reference to the new user

I don't think it's a good idea to alter the TA trusted entities list client-side:

  • That would make TA appear as if they trust sources they didn't explicitly trust. That means if a client makes a wrong decision when validating the new user change, the change would then appear as 100% accepted (which is probably not the case).
  • Verifying the new source's registration event against the old signature is going to fail in some cases (every time for localized sources with subsources list)

This comment has been minimized.

@vabd

vabd Jan 19, 2019

Member

ftr I let the "how the client implementation considers a link valid" (or "accepted" as you name it) unspecified on purpose to let implementations manage that the way they see fit. What is being specified here is what's happening once the client implementation decides the link is valid, either by using a threshold or having the user validate it. Either way, there's a point from which a client implementation will be able to state "now I'm pretty sure this new user is the source it pretends to be", and this paragraph specifies the UX it needs to follow from that point.

I apparently need to add some more details, as it's indeed not clear on how that impact crypto checks (which it shouldn't, the way I see it once the link is validated the "source" entity is defined by both MXIDs, and crypto checks should succeed as long as the MXID used is either the new one of an old one, and in the latter case as long as its registration has been emitted before last_event).

This comment has been minimized.

@vabd

vabd Jan 19, 2019

Member

Re-reading the paragraph, it already says:

a reference to the source's previous user in a
trust authority's list of trustworthy sources must be considered as a
reference to the new user (with the exception of the cryptographic check on the
source's registration, which is still done using the registration event
published by the previous user).

which is pretty much what I said in my previous comment. I'll complete it to mention the cryptographic check is still done using the previous MXID, and might add a short sentence making clear that the source, as an entity, is defined by all of the MXIDs it's used, but otherwise there's not much to add.

valid, client implementations **must** consider both the source's (or
sub-source's) new user and its previous one (and older ones if the source or
sub-source changed its user more than once) as the same entity. This means that
articles published by the source's (or the sub-source's) previous user **must**

This comment has been minimized.

@GordonF42

GordonF42 Jan 19, 2019

Member

This means that articles published by the source's (or the sub-source's) previous user before the event defined in prev_event **must**

Show resolved Hide resolved content/information-distribution/source.md Outdated
Show resolved Hide resolved content/information-distribution/source.md Outdated
| `sig_algo` | `string` | x | Algorithm the source will use to cryptographically sign its articles. 🔧 |
| `sig_keys` | `[string]` | x | Public keys the source will use to cryptographically sign its articles. 🔧 |
| `prev_id` | `string` | | Matrix user ID of the Matrix user this source previously used to publish information. See [below](#change-of-matrix-user). |
| `prev_event` | `string` | | ID of the latest event published by the source's previous user. Only valid if `prev_id` is set to a non-empty string. See [below](#change-of-matrix-user). |

This comment has been minimized.

@GordonF42

GordonF42 Jan 19, 2019

Member
Suggested change Beta
| `prev_event` | `string` | | ID of the latest event published by the source's previous user. Only valid if `prev_id` is set to a non-empty string. See [below](#change-of-matrix-user). |
| `prev_event` | `string` | | ID of the last legit event published by the source's previous user. Only valid if `prev_id` is set to a non-empty string. See [below](#change-of-matrix-user). |

There is the same change to do L161

This comment has been minimized.

@vabd

vabd Jan 19, 2019

Member

I'm not sure about the word "legit" which doesn't have an objective definition. Replacing with the latest event published by the source with this user.

GordonF42 and others added some commits Jan 19, 2019

Update content/information-distribution/source.md
Co-Authored-By: vabd <34184120+vabd@users.noreply.github.com>
Update content/information-distribution/source.md
Co-Authored-By: vabd <34184120+vabd@users.noreply.github.com>
Update content/information-distribution/source.md
Co-Authored-By: vabd <34184120+vabd@users.noreply.github.com>

@vabd vabd requested a review from Informo/informo-core-team Jan 19, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment