Respond to comments by pthatcherg and btolsch

index.bs

@@ -727,14 +727,14 @@ Playback API.
 Security and Privacy {#security-privacy}
 ====================
 
-The Open Screen Protocol allows two networked user agents to discover each other
+The Open Screen Protocol allows two networked agents to discover each other
 and exchange user and application data.  As such, its security and privacy
 considerations should be closely examined.  We first evaluate the protocol
 itself using the W3C [[SECURITY-PRIVACY-QUESTIONNAIRE|Security and Privacy
 Questionnaire]].  We then examine whether the security and privacy guidelines
 recommended by the [[PRESENTATION-API|Presentation API]] and the
 [[REMOTE-PLAYBACK|Remote Playback API]] are met.  Finally we discuss recommended
-mitigations that implementations can use to meet these security and privacy
+mitigations that agents can use to meet these security and privacy
 requirements.
 
 Threat Models {#threat-models}
@@ -744,39 +744,39 @@ Threat Models {#threat-models}
 
 The Open Screen Protocol should assume that all parties that are connected to
 the same LAN, either through a wired connection or through WiFi, are able to
-observe all data flowing between Open Screen controllers and receivers.
+observe all data flowing between Open Screen Protocol agents.
 
 These parties will be able collect any data exposed through unencrypted
-messages, such as mDNS records and the QUIC handshake.
+messages, such as mDNS records and the QUIC handshakes.
 
 These parties may attempt to learn cryptographic parameters by observing data
 flows on the QUIC connection, or by observing cryptographic timing.
 
 ### Active Network Attackers ### {#active-network-attackers}
 
-In addition, all parties connected to the LAN will be able to manipulate data
-exchanged between controllers and receivers.  They will be able to inject
-traffic into existing QUIC connections and attempt to inititate new QUIC
-connections.  These abilities can be used to attempt the following:
+Active attackers, such as compromised routers, will be able to manipulate data
+exchanged between agents.  They can inject traffic into existing QUIC
+connections and attempt to inititate new QUIC connections.  These abilities can
+be used to attempt the following:
 
-*   Impersonate a new receiver or one already trusted by the user, in an attempt
+*   Impersonate an agent or one already trusted by the user, in an attempt
     to convince the user to authenticate to it.
-*   Connect to a receiver and query its capabilities.
+*   Connect to an agent and query its capabilities.
 *   Connect to and control a presentation or remote playback, or extract data
     from the application state of the presentation or remote playback.
 
 One particular attack of concern is misconfigured or compromised routers that
-expose local network devices (such as Open Screen Protocol controllers and
-receivers) to the Internet.  This vector of attack has been used by malicious
-parties to take control of printers and smart TVs by connecting to local network
-services that would normally be inaccessible from the Internet.
+expose local network devices (such as Open Screen Protocol agents) to the
+Internet.  This vector of attack has been used by malicious parties to take
+control of printers and smart TVs by connecting to local network services that
+would normally be inaccessible from the Internet.
 
 ### Denial of Service ### {#denial-of-service}
 
-Parties connected to the LAN may attempt to deny access to Open Screen
-Protocol controllers and receivers.  For example, an attacker my attempt to open
-a large number of QUIC connections to a receiver in an attempt to block
-legitimate connections or exhaust the receiver's system resources.  They may
+Parties with connected to the LAN may attempt to deny access to Open Screen
+Protocol agents.  For example, an attacker my attempt to open
+a large number of QUIC connections to an agent in an attempt to block
+legitimate connections or exhaust the agent's system resources.  They may
 also multicast spurious DNS-SD records in an attempt to exhaust the cache
 capacity for mDNS listeners, or to get listeners to open a large number of bogus
 QUIC connections.
@@ -785,10 +785,10 @@ QUIC connections.
 
 The Presentation API allows cross-origin communication between controlling pages
 and presentations with the consent of each origin (through their use of the
-API).  This is similar to cross-origin communication via {{Window/postMessage()}}
-with a target origin of `*`.  However, the Presentation API does not convey
-source origin information with each message.  Therefore, the Open Screen
-Protocol does not convey origin information between controllers and receivers.
+API).  This is similar to cross-origin communication via
+{{Window/postMessage()}} with a target origin of `*`.  However, the Presentation
+API does not convey source origin information with each message.  Therefore, the
+Open Screen Protocol does not convey origin information between its agents.
 
 The [=presentation ID=] carries some protection against unrestricted
 cross-origin access; but, rigorous authentication of the parties connected by a
@@ -809,16 +809,20 @@ and/or high value data:
 1. Remote playback URLs
 1. Remote playback commands and status messages
 
+Presentation IDs are considered high value data because they can be used in
+conjunction with a Presentation URL to connect to a running presentation.
+
 Presentation display friendly names, model names, and capabilities, while not
-considered personally identifiable, are important to protect to preserve the
-integrity of the discovery and authentication process.
+considered personally identifiable, are important to protect to prevent an
+attacker from changing them or substituting other values during the discovery
+and authentication process.
 
-The following data cannot be reasonably secured and should be considered public
-and untrusted data:
+The following data cannot be reasonably made confidential and should be
+considered public and untrusted data:
 
 1. IP addresses and ports used by the Open Screen Protocol.
-1. Data advertised through mDNS, including the certificate fingerprint and the 
-    metadata version.
+1. Data advertised through mDNS, including the display name prefix, the
+    certificate fingerprint, and the metadata version.
 
 ### Cross Origin State Considerations ### {#cross-origin-state}
 
@@ -845,20 +849,19 @@ Below, we discuss mitigation steps to prevent malicious use of these devices.
 ### Incognito Mode ### {#incognito-mode}
 
 The Open Screen Protocol does not distinguish between the user agent's normal
-browsing and incognito modes, and should operate identically regardless of which
-mode is in use.
+browsing and incognito modes, and agents that follow the specification
+behave identically regardless of which mode is in use.
 
 It's recommended that controllers use separate authentication contexts and QUIC
 connections for normal and incognito profiles from the same user agent instance.
-This prevents Open Screen receivers from correlating activity between a user's
-normal profile and their incognito profile.
+This prevents Open Screen receivers from correlating activity among a user's
+profiles (both normal and incognito).
 
 ### Persistent State ### {#persistent-state}
 
-An implementation of the Open Screen Protocol is likely to persist the identity
-of controllers and receivers that have successfully completed
-[[#authentication]].  This may include the public key fingerprints, metadata
-versions, and metadata for those parties.
+An agent is likely to persist the identity of agents that have successfully
+completed [[#authentication]].  This may include the public key fingerprints,
+metadata versions, and metadata for those parties.
 
 However, this data is not normally exposed to the Web, only through the native
 UI of the user agent during the display selection or display authentication
@@ -900,8 +903,8 @@ The Open Screen Protocol addresses these considerations by:
 1. Requiring mutual authentication and a TLS-secured QUIC connection before
      presentation URLs, IDs, or messages are exchanged.
 1. Adding explicit messages and connection IDs for individual
-     {{PresentationConnection|PresentationConnections}} so that controllers and
-     receivers can track the number of active connections.
+     {{PresentationConnection|PresentationConnections}} so that agents can track
+     the number of active connections.
 
 Remote Playback API Considerations {#remote-playback-considerations}
 ----------------------------------
@@ -933,19 +936,17 @@ Issue(130): [Security] Review attack and mitigation considerations for TLS 1.3
 
 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 a controller or
-receiver, 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.
+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.
 
 This can be addressed through a combination of techniques.  The first is flagging:
 
 * Flag advertised displays whose friendly name, public key fingerprint, or
     IP:port collide with an already trusted display.
 * Flag already-trusted displays whose metadata has changed.
-* Flag controllers or receivers that fail the authentication challenge a certain
-    number of times.
+* Flag agents that fail the authentication challenge a certain number of times.
 
 Flagging means that the user is notified, or in some cases they are required to
 re-authenticate to the presentation display to verify its identity.
@@ -969,33 +970,33 @@ Issue(130): [Security] Review attack and mitigation considerations for TLS 1.3
 ### Remote active network attackers ### {#remote-active-mitigations}
 
 Unfortunately, we cannot rely on network devices to fully protect Open Screen
-controllers and receivers from traffic from the broader Internet.  Open Screen
-Protocol implementations that are only intended to work on the LAN should filter
-packets from non-local IP addresses.  Implementations can also use the ARP cache
-to detect attempts to spoof local network IP addresses.
+Protocol agents from traffic from the broader Internet.  Open Screen Protocol
+agents that are only intended to work on the LAN should filter packets
+from non-local IP addresses.  Agents can also use the ARP cache to
+detect attempts to spoof local network IP addresses.
 
 Issue(131): [Security] Mitigations for remote network attackers
 
 ### Denial of service ### {#denial-of-service-mitigations}
 
-It will be difficult to completely prevent denial of service attacks that
-originate on the user's local area network.  Open Screen Protocol
-implementations can refuse new connections, rate limit the rate of messages from
-existing connections, or limit the number of mDNS records cached in an attempt
-to allow existing activities to continue in spite of such an attack.
+It will be difficult to completely prevent denial service of attacks that
+originate on the user's local area network.  Open Screen Protocol agents can
+refuse new connections, rate limit the rate of messages from existing
+connections, or limit the number of mDNS records cached from a specific
+responder in an attempt to allow existing activities to continue in spite of
+such an attack.
 
 ### Malicious input ### {#malicious-input-mitigations}
 
-Open Screen Protocol implementations should be robust against malicious input
-that attempts to compromise the target device by exploiting parsing
-vulnerabilities.
+Open Screen Protocol agents should be robust against malicious input that
+attempts to compromise the target device by exploiting parsing vulnerabilities.
 
 CBOR is intended to be less vulnerable to such attacks relative to alternatives
-like JSON and XML.  Still, implementations should be thoroughly tested using
-approaches like [fuzz testing](https://en.wikipedia.org/wiki/Fuzzing).
+like JSON and XML.  Still, agents should be thoroughly tested using approaches
+like [fuzz testing](https://en.wikipedia.org/wiki/Fuzzing).
 
-Where possible, Open Screen Protocol implementations (including the content
-rendering components) should use defense-in-depth techniques like <a
+Where possible, Open Screen Protocol agents (including the content rendering
+components) should use defense-in-depth techniques like <a
 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.