Drafting security & privacy

index.bs

@@ -268,16 +268,83 @@ Playback API.
 Security and Privacy {#security}
 ================================
 
-Issue(13): Describe security architecture.
+The Open Screen Protocol should, at a minimum, conform to the security and
+privacy guidelines recommended by the [[PRESENTATION-API][Presentation API]] and
+the [[REMOTE-PLAYBACK][Remote Playback API]].
+
+In addition, the Open Screen Protocol itself has additional security and privacy
+considerations.
+
+Presentation API Security and Privacy
+-------------------------------------
+
+The [[PRESENTATION-API#security-and-privacy-considerations][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 recievers should be notified when multiple connections have
+    been made to a presentation, per the user interface guidelines.
+1.  Messaging between presentations and controllers should be authenticated and
+    confidential, per the guidelines for messaging between presentation
+    connections.
+
+Remote Playback API Security and Privacy
+----------------------------------------
+
+The [[REMOTE-PLAYBACK#security-and-privacy-considerations][Remote Playback API
+Security and Privacy Considerations]] also state that messaging between local
+and remote playback devices should also be authenticated and confidential.
+
+Threat Models {#security-threat}
+--------------------------------
+
+## Passive Attacks
+
+The Open Screen Protocol should assume that all parties that are able
+access the LAN, either through a wired connection or through WiFi, are able to
+observe all data flowing between Open Screen controllers and receivers.
+
+These parties will be able collect any data exposed through unencrypted
+messages, such as mDNS records and the QUIC handshake.
+
+## Active Attacks
+
+In addition, all parties with access to the LAN will be able to manipulate data
+exchanged between controllers and receivers and inititate QUIC connections.
+This can be used to attempt attacks such as:
+
+*   Impersonating a new receiver or one already known to the user, in an attempt
+    to convince the user to authenticate it as a trusted receiver.
+*   Connecting to a receiver and querying its capabilities, or attempting to
+    connect to a running presentation or remote playback.
+
+## Denial of Service
+
 
 Data to be secured {#security-data}
 -----------------------------------
 
-Threat model {#security-threat}
--------------------------------
+There are two kinds of data 
+
+1. Presentation URLs
+1. Presentation IDs
+1. Presentation connection messages
+1. Remote playback URLs
+1. Remote playback commands and status messages
+
+The following data cannot be reasonably secured and should be considered public
+and untrusted data:
+
+1. IP addresses and ports used by the Open Screen Protocol.
+1. Friendly names or other data advertised through mDNS.
+1. 
+
+Mitigation Strategies {#security-mitigation}
+--------------------------------------------
 
-Mitigations and defenses {#security-defenses}
----------------------------------------------