Merge security-ux

index.bs

@@ -306,25 +306,8 @@ it has been truncated.
 Advertising agents must follow the mDNS [=conflict resolution=] procedure, to
 prevent multiple advertising agents from using the same DNS-SD Instance Name.
 
-Agents must treat Instance Names as unverified information, and should check
-that the Instance Name is a prefix of the display name received through the
-[=agent-info=] message after a successful QUIC connection.  Once an agent has done
-this check, it can show the name as a <dfn noexport>verified display name</dfn>.
-
-Agents should show only complete display names to the user, instead of truncated
-display names from DNS-SD.  A truncated display name should be verified as above
-before being shown in full as a [=verified display name=].
-
-<div class="note">
-This means there are three categories of display names that agents should be
-capable of handling:
-<ol>
-  <li>Truncated and unverified DNS-SD Instance Names, which should not be shown to the user.</li>
-  <li>Complete but unverified DNS-SD Instance Names, which can be shown as
-     unverified prior to [[#authentication]].</li>
-  <li>Verified display names.</li>
-</ol>
-</div>
+Agents should be careful when displaying Instance Names to users; see
+[[#instance-names]] for guidelines on Instance Name display.
 
 Advertising agents must include DNS TXT records with the following
 keys and values:
@@ -1738,7 +1721,7 @@ exchanged between agents.  They can inject traffic into existing QUIC
 connections and attempt to initiate new QUIC connections.  These abilities can
 be used to attempt the following:
 
-*   Impersonate an agent or one already trusted by the user, in an attempt
+*   Impersonate an agent or one already authenticated by the user, in an attempt
     to convince the user to authenticate to it.
 *   Connect to an agent and query its capabilities.
 *   Connect to and control a presentation or remote playback, or extract data
@@ -1920,15 +1903,18 @@ Local active attackers may attempt to impersonate a presentation display the
 user would normally trust.  The [[#authentication]] step of the Open Screen
 Protocol prevents a man-in-the-middle from impersonating an agent, without
 knowledge of a shared secret.  However, it is possible for an attacker to
-impersonate an existing, trusted display or a newly discovered display that is
-not yet authenticated and try to convince the user to authenticate it.
+impersonate an existing, trusted agent or a newly discovered agent that is not
+yet authenticated and try to convince the user to authenticate to it.  (Trust in
+this context means that a user has completed [[#authentication]] from their
+agent to another agent.)
 
 This can be addressed through a combination of techniques.  The first is
-detecting and flagging attempts at impersonation; a few of the situations that
-should be flagged include:
+detecting attempts at impersonation.  Agents should detect the following
+situations and flag an agent that meets any of the criteria as a <dfn>suspicious
+agent</dfn>:
 
-* Untrusted agents whose public key fingerprint collides with that from an
-    already-trusted agent that is concurrently being advertised.
+* Agents with distinct IP endpoints whose public key fingerprints collide during
+    concurrent advertisement.
 * Untrusted agents whose display name differs from the one previously
     advertised under a given public key fingerprint.
 * Untrusted agents that fail the authentication challenge a certain number of times.
@@ -1937,21 +1923,13 @@ should be flagged include:
 * Already-trusted agents whose metadata provided through the [=agent-info=]
     message has changed.
 
-Flagging means that the user is notified of the attempt at impersonation.  In
-the last case, the user should be required to re-authenticate to the
-already-trusted agent to verify its identity.
-
-Issue(118): UI guidelines for pairing and trusted/untrusted data.
-
 The second is through management of the low-entropy secret during mutual
 authentication:
 
 * Rotate the low-entropy secret to prevent brute force attacks.
 * Use an increasing backoff to respond to authentication challenges, also to
     prevent brute force attacks.
 * Use a cryptographically sound source of entropy to generate the shared secret.
-* Require the end user to manually type the shared secret - shown only on the
-    display - to prevent the user from blindly clicking through this step.
 
 The active attacker may also attempt to disrupt data exchanged over the QUIC
 connection by injecting or modifying traffic.  These attacks should be mitigated
@@ -1994,6 +1972,52 @@ href="https://en.wikipedia.org/wiki/Sandbox_(computer_security)">sandboxing</a>
 to prevent vulnerabilities from gaining access to user data or leading to
 persistent exploits.
 
+User Interface Considerations {#security-ui}
+-----------------------------
+
+This specification does not make any specific requirements of the security
+relevant user interfaces of Open Screen agents.  However there are important
+considerations when designing these user interfaces, as PSK-based authentication
+requires users to make informed decisions about which agents to trust.
+
+1. Before an agent has authenticated another device, the agent should make it
+    clear that any `agent-info` or other data from that device has not been
+    verified by authentication.  (See below for how this applies to DNS-SD
+    Instance Names.)
+1. A [=suspicious agent=] should be displayed differently from trusted
+    agents that are not suspicious, or not displayed at all.
+1. The user interface to input a PSK during authentication should be done in
+    trusted UI and be difficult to spoof.
+1. The user should be required to take action to input the PSK, to prevent the
+    user from blindly clicking through this step.
+1. The user interfaces to render and input a PSK should meet accessibility
+    guidelines.
+
+### Instance and Display Names  ### {#instance-names}
+
+Because DNS-SD [=Instance Names=] are the primary information that the user
+sees prior to authentication, careful presentation of these names is necessary.
+
+Agents must treat Instance Names as unverified information, and should check
+that the Instance Name is a prefix of the display name received through the
+`agent-info` message after a successful QUIC connection.  Once an agent has done
+this check, it can show the name as a <dfn noexport>verified display name</dfn>.
+
+Agents should show only complete display names to the user, instead of truncated
+display names from DNS-SD.  A truncated display name should be verified as above
+before being shown in full as a [=verified display name=].
+
+<div class="note">
+This means there are three categories of display names that agents should be
+capable of handling:
+<ol>
+  <li>Truncated and unverified DNS-SD Instance Names, which should not be shown to the user.</li>
+  <li>Complete but unverified DNS-SD Instance Names, which can be shown as
+     unverified prior to [[#authentication]].</li>
+  <li>Verified display names.</li>
+</ol>
+</div>
+
 Appendix A: Messages {#appendix-a}
 ====================