wholetrans/docs-matrix-spec
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Fix formating

Browse source
This commit is contained in:
Mark Haines 2014-11-12 14:43:56 +00:00
parent 3fd1833bc5
commit 6090049c3e
1 changed files with 22 additions and 20 deletions
Download patch file Download diff file Expand all files Collapse all files

42
drafts/human-id-rules.rst
View file

@ -12,11 +12,11 @@ phishing/spoofing of IDs, commonly known as a homograph attack.
Web browers encountered this problem when International Domain Names were Web browers encountered this problem when International Domain Names were
introduced. A variety of checks were put in place in order to protect users. If introduced. A variety of checks were put in place in order to protect users. If
an address failed the check, the raw punycode would be displayed to disambiguate an address failed the check, the raw punycode would be displayed to
the address. Similar checks are performed by home servers in Matrix. However, disambiguate the address. Similar checks are performed by home servers in
Matrix does not use punycode representations, and so does not show raw punycode Matrix. However, Matrix does not use punycode representations, and so does not
on a failed check. Instead, home servers must outright reject these misleading show raw punycode on a failed check. Instead, home servers must outright reject
IDs. these misleading IDs.
Types of human-readable IDs Types of human-readable IDs
--------------------------- ---------------------------
@ -24,7 +24,7 @@ There are two main human-readable IDs in question:
- Room aliases - Room aliases
- User IDs - User IDs
Room aliases look like ``#localpart:domain``. These aliases point to opaque Room aliases look like ``#localpart:domain``. These aliases point to opaque
non human-readable room IDs. These pointers can change, so there is already an non human-readable room IDs. These pointers can change, so there is already an
issue present with the same ID pointing to a different destination at a later issue present with the same ID pointing to a different destination at a later
@ -32,18 +32,19 @@ date.
User IDs look like ``@localpart:domain``. These represent actual end-users, and User IDs look like ``@localpart:domain``. These represent actual end-users, and
unlike room aliases, there is no layer of indirection. This presents a much unlike room aliases, there is no layer of indirection. This presents a much
greater concern with homograph attacks. greater concern with homograph attacks.
Checks Checks
------ ------
- Similar to web browsers. - Similar to web browsers.
- blacklisted chars (e.g. non-printable characters) - blacklisted chars (e.g. non-printable characters)
- mix of language sets from 'preferred' language not allowed. - mix of language sets from 'preferred' language not allowed.
- Language sets from CLDR dataset. - Language sets from CLDR dataset.
- Treated in segments (localpart, domain) - Treated in segments (localpart, domain)
- Additional restrictions for ease of processing IDs. - Additional restrictions for ease of processing IDs.
- Room alias localparts MUST NOT have ``#`` or ``:``.
- User ID localparts MUST NOT have ``@`` or ``:``. - Room alias localparts MUST NOT have ``#`` or ``:``.
- User ID localparts MUST NOT have ``@`` or ``:``.
Rejecting Rejecting
--------- ---------
@ -59,21 +60,22 @@ Rejecting
rejected and why. rejected and why.
- Error message SHOULD contain a ``failed_keys`` key which contains an array - Error message SHOULD contain a ``failed_keys`` key which contains an array
of strings which represent the keys which failed the check e.g:: of strings which represent the keys which failed the check e.g::
failed_keys: [ user_id, room_alias ] failed_keys: [ user_id, room_alias ]
Other considerations Other considerations
-------------------- --------------------
- Basic security: Informational key on the event attached by HS to say "unsafe - Basic security: Informational key on the event attached by HS to say "unsafe
ID". Problem: clients can just ignore it, and since it will appear only very ID". Problem: clients can just ignore it, and since it will appear only very
rarely, easy to forget when implementing clients. rarely, easy to forget when implementing clients.
- Moderate security: Requires client handshake. Forces clients to implement - Moderate security: Requires client handshake. Forces clients to implement
a check, else they cannot communicate with the misleading ID. However, this is a check, else they cannot communicate with the misleading ID. However, this
extra overhead in both client implementations and round-trips. is extra overhead in both client implementations and round-trips.
- High security: Outright rejection of the ID at the point of creation / - High security: Outright rejection of the ID at the point of creation /
receiving event. Point of creation rejection is preferable to avoid the ID receiving event. Point of creation rejection is preferable to avoid the ID
entering the system in the first place. However, malicious HSes can just allow entering the system in the first place. However, malicious HSes can just
the ID. Hence, other home servers must reject them if they see them in events. allow the ID. Hence, other home servers must reject them if they see them in
Client never sees the problem ID, provided the HS is correctly implemented. events. Client never sees the problem ID, provided the HS is correctly
implemented.
- High security decided; client doesn't need to worry about it, no additional - High security decided; client doesn't need to worry about it, no additional
protocol complexity aside from rejection of an event. protocol complexity aside from rejection of an event.