Merge pull request #133 from webscreens/issue-13

Adds security and privacy section to the spec.

index.bs

@@ -605,7 +605,6 @@ message which contains the following values:
 
 -   url: The URL of the presentation to connect to. 
 
-
 The receiver should, upon receipt of a
 presentation-connection-open-request message, send back a
 presentation-connection-open-response message which contains the
@@ -725,19 +724,289 @@ Issue(12): Propose control protocol for Remote
 Playback API.
 
 
-Security and Privacy {#security}
-================================
-
-Issue(13): Describe security architecture.
+Security and Privacy {#security-privacy}
+====================
 
-Data to be secured {#security-data}
+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 agents can use to meet these security and privacy
+requirements.
+
+Threat Models {#threat-models}
+--------------------------------
+
+### Passive Network Attackers ### {#passive-network-attackers}
+
+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 Protocol agents.
+
+These parties will be able collect any data exposed through unencrypted
+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}
+
+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 an agent or one already trusted 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
+    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 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 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.
+
+### Same-Origin Policy Violations ### {#same-origin-policy-violations}
+
+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 its agents.
+
+The [=presentation ID=] carries some protection against unrestricted
+cross-origin access; but, rigorous authentication of the parties connected by a
+{{PresentationConnection}} must be done at the application level.
+
+Open Screen Protocol Security and Privacy Considerations {#security-privacy-questions}
 -----------------------------------
 
-Threat model {#security-threat}
+### Personally Identifiable Information & High-Value Data ### {#personally-identifiable-information}
+
+The following data exchanged by the protocol can be personally identifiable
+and/or high value data:
+
+1. Presentation URLs and availability results
+1. Presentation IDs
+1. Presentation connection IDs
+1. Presentation connection messages
+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 prevent an
+attacker from changing them or substituting other values during the discovery
+and authentication process.
+
+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 display name prefix, the
+    certificate fingerprint, and the metadata version.
+
+### Cross Origin State Considerations ### {#cross-origin-state}
+
+Access to origin state across browsing sessions is possible through the
+Presentation API by reconnecting to a presentation that was started by a
+previous session. This scenario is addressed in
+[[PRESENTATION-API#cross-origin-access]].
+
+Presentation display availability and remote playback device availability are
+states that are available cross-origin depending on the user's network
+context.  Exposure of this data to the Web is also discussed in
+[[PRESENTATION-API#personally-identifiable-information]] and
+[[REMOTE-PLAYBACK#personally-identifiable-information]].
+
+### Origin Access to Other Devices ### {#origin-access-devices}
+
+By design, the Open Screen Protocol allows access to presentation displays and
+remote playback devices from the Web.  By implementing the protocol, these
+devices are knowingly making themselves available to the Web and should be
+designed accordingly.
+
+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 agents that follow the specification
+behave identically regardless of which mode is in use.
+
+It's recommended that user agents use separate authentication contexts and QUIC
+connections for normal and incognito profiles from the same user agent instance.
+This prevents Open Screen agents from correlating activity among profiles
+belonging to the same user (both normal and incognito).
+
+### Persistent State ### {#persistent-state}
+
+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
+process.  It can be an implementation choice whether the user agent clears or
+retains this data when the user clears browsing data.
+
+Issue(132): [Privacy] Fate of metadata / authentication history when clearing
+browsing data
+
+### Other Considerations ### {#other-considerations}
+
+The Open Screen Protocol does not grant to the Web additional access to the
+following:
+
+* New script loading mechanisms
+* Access to the user's location
+* Access to device sensors
+* Access to the user's local computing environment
+* Control over the user agent's native UI
+* Security characteristics of the user agent
+
+Presentation API Considerations {#presentation-api-considerations}
 -------------------------------
 
-Mitigations and defenses {#security-defenses}
----------------------------------------------
+[[PRESENTATION-API#security-and-privacy-considerations]] place these
+requirements on the Open Screen Protocol:
+
+1.  Presentation URLs and presentation IDs should remain private among the
+    parties that are allowed to connect to a presentation, per the
+    cross-origin access guidelines.
+1.  Controllers and receivers should be notified when connections representing
+    multiple user agent profiles have been made to a presentation, per the user
+    interface guidelines.
+1.  Messaging between controllers and receivers should be authenticated and
+    confidential, per the guidelines for messaging between presentation
+    connections.
+
+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 agents can track
+     the number of active connections.
+
+Remote Playback API Considerations {#remote-playback-considerations}
+----------------------------------
+
+The [[REMOTE-PLAYBACK#security-and-privacy-considerations]] also state that
+messaging between local and remote playback devices should also be authenticated
+and confidential.
+
+This consideration is handled by requiring mutual authentication and a
+TLS-secured QUIC connection before any remote playback related messages are
+exchanged.
+
+Mitigation Strategies {#security-mitigations}
+--------------------------------------------
+
+### Local passive network attackers ### {#local-passive-mitigations}
+
+Local passive attackers may attempt to harvest data about user activities and
+device capabilties using the Open Screen Protocol.  The main strategy to address
+this is data minimization, by only exposing opaque public key fingerprints
+before user-mediated authentication takes place.
+
+Passive attackers may also attempt timing attacks to learn the
+cryptographic parameters of the TLS 1.3 QUIC connection.
+
+Issue(130): [Security] Review attack and mitigation considerations for TLS 1.3
+
+### Local active network attackers ### {#local-active-mitigations}
+
+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.
+
+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:
+
+* Untrusted agents whose public key fingerprint collides with that from an
+    already-trusted agent that is concurrently being advertised.
+* Untrusted agents whose friendly 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.
+* Untrusted agents that advertise a friendly name that is similar to that from an
+    already-trusted agent.
+* 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.
+
+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
+by a correct implementation of TLS 1.3.
+
+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
+Protocol agents, because a misconfigured firewall or NAT could expose a
+LAN-connected agent to the broader Internet.  Open Screen Protocol agents
+should be secure against attack from any Inernet host.
+
+Issue(131): [Security] Mitigations for remote network attackers
+
+### Denial of service ### {#denial-of-service-mitigations}
+
+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, close connections that receive too many messages, 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 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, agents should be thoroughly tested using approaches
+like [fuzz testing](https://en.wikipedia.org/wiki/Fuzzing).
+
+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.
 
 Appendix A: Messages {#appendix-a}
 ====================