From 6090049c3e0035b84b87240cac083909f7253ed8 Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Wed, 12 Nov 2014 14:43:56 +0000 Subject: [PATCH] Fix formating --- drafts/human-id-rules.rst | 42 ++++++++++++++++++++------------------- 1 file changed, 22 insertions(+), 20 deletions(-) diff --git a/drafts/human-id-rules.rst b/drafts/human-id-rules.rst index 3a1ff398..914a9a42 100644 --- a/drafts/human-id-rules.rst +++ b/drafts/human-id-rules.rst @@ -12,11 +12,11 @@ phishing/spoofing of IDs, commonly known as a homograph attack. 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 -an address failed the check, the raw punycode would be displayed to disambiguate -the address. Similar checks are performed by home servers in Matrix. However, -Matrix does not use punycode representations, and so does not show raw punycode -on a failed check. Instead, home servers must outright reject these misleading -IDs. +an address failed the check, the raw punycode would be displayed to +disambiguate the address. Similar checks are performed by home servers in +Matrix. However, Matrix does not use punycode representations, and so does not +show raw punycode on a failed check. Instead, home servers must outright reject +these misleading IDs. Types of human-readable IDs --------------------------- @@ -24,7 +24,7 @@ There are two main human-readable IDs in question: - Room aliases - User IDs - + 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 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 unlike room aliases, there is no layer of indirection. This presents a much -greater concern with homograph attacks. +greater concern with homograph attacks. Checks ------ - Similar to web browsers. - 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. - Treated in segments (localpart, domain) - 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 --------- @@ -59,21 +60,22 @@ Rejecting rejected and why. - Error message SHOULD contain a ``failed_keys`` key which contains an array of strings which represent the keys which failed the check e.g:: - + failed_keys: [ user_id, room_alias ] - + 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 rarely, easy to forget when implementing clients. - Moderate security: Requires client handshake. Forces clients to implement - a check, else they cannot communicate with the misleading ID. However, this is - extra overhead in both client implementations and round-trips. -- High security: Outright rejection of the ID at the point of creation / + a check, else they cannot communicate with the misleading ID. However, this + is extra overhead in both client implementations and round-trips. +- High security: Outright rejection of the ID at the point of creation / 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 - the ID. Hence, other home servers must reject them if they see them in events. - Client never sees the problem ID, provided the HS is correctly implemented. + entering the system in the first place. However, malicious HSes can just + allow the ID. Hence, other home servers must reject them if they see them in + 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 - protocol complexity aside from rejection of an event. \ No newline at end of file + protocol complexity aside from rejection of an event.