From 2a75005022eb6829e64e2ec970a47bde9a08c887 Mon Sep 17 00:00:00 2001 From: "mark a. foltz" Date: Tue, 27 Aug 2019 11:44:40 -0700 Subject: [PATCH 1/4] UI guidelines --- index.bs | 92 +++++++++++++++++++++++++++++----------------- index.html | 106 +++++++++++++++++++++++++++++++++++------------------ 2 files changed, 129 insertions(+), 69 deletions(-) diff --git a/index.bs b/index.bs index a8d4152..0693c07 100644 --- a/index.bs +++ b/index.bs @@ -305,25 +305,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 verified display name. - -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=]. - -
-This means there are three categories of display names that agents should be -capable of handling: -
    -
  1. Truncated and unverified DNS-SD Instance Names, which should not be shown to the user.
    2. -
  2. Complete but unverified DNS-SD Instance Names, which can be shown as - unverified prior to [[#authentication]].
    3. -
  3. Verified display names.
    4. -
-
+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: @@ -1726,7 +1709,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 @@ -1908,15 +1891,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 suspicious +agent: -* 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. @@ -1925,12 +1911,6 @@ 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: @@ -1938,8 +1918,6 @@ authentication: * 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 @@ -1982,6 +1960,52 @@ href="https://en.wikipedia.org/wiki/Sandbox_(computer_security)">sandboxing to prevent vulnerabilities from gaining access to user data or leading to persistent exploits. +User Interface Considerations {#security-ui} +----------------------------- + +This specification does 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. An [=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 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 verified display name. + +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=]. + +
+This means there are three categories of display names that agents should be +capable of handling: +
    +
  1. Truncated and unverified DNS-SD Instance Names, which should not be shown to the user.
    2. +
  2. Complete but unverified DNS-SD Instance Names, which can be shown as + unverified prior to [[#authentication]].
    3. +
  3. Verified display names.
    4. +
+
+ Appendix A: Messages {#appendix-a} ==================== diff --git a/index.html b/index.html index 6519f2e..6217134 100644 --- a/index.html +++ b/index.html @@ -1214,7 +1214,7 @@ - + - + - +