From 3e0675f2a5988fafb4a697958a7314c695dfdb42 Mon Sep 17 00:00:00 2001 From: "mark a. foltz" Date: Fri, 22 Mar 2019 14:34:28 -0700 Subject: [PATCH] Address more comments --- index.bs | 21 ++++++++++++--------- index.html | 26 +++++++++++++++++--------- 2 files changed, 29 insertions(+), 18 deletions(-) diff --git a/index.bs b/index.bs index 45f22f8..921fdd0 100644 --- a/index.bs +++ b/index.bs @@ -852,10 +852,10 @@ 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 controllers use separate authentication contexts and QUIC +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 receivers from correlating activity among a user's -profiles (both normal and incognito). +This prevents Open Screen agents from correlating activity among profiles +belonging to the same user (both normal and incognito). ### Persistent State ### {#persistent-state} @@ -892,9 +892,10 @@ 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 multiple connections have - been made to a presentation, per the user interface guidelines. -1. Messaging between presentations and controllers should be authenticated and +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. @@ -927,7 +928,7 @@ 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 cryptographic the +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 @@ -943,8 +944,10 @@ 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 an advertised display whose public key fingerprint collides with that + from an already-trusted display that is concurrently being advertised. +* Flag an advertised display whose friendly name differs from the one previously + advertised under a public key fingerprint. * Flag already-trusted displays whose metadata has changed. * Flag agents that fail the authentication challenge a certain number of times. diff --git a/index.html b/index.html index 757cb0b..7ce35c3 100644 --- a/index.html +++ b/index.html @@ -1403,7 +1403,11 @@

Open Screen Protocol

+<<<<<<< HEAD

Editor’s Draft,

+======= +

Editor’s Draft,

+>>>>>>> Address more comments
This version: @@ -2177,10 +2181,10 @@

An agent is likely to persist the identity of agents that have successfully completed §6 Authentication. This may include the public key fingerprints, @@ -2217,10 +2221,11 @@

-

Passive attackers may also attempt timing attacks to learn cryptographic the +

Passive attackers may also attempt timing attacks to learn the cryptographic parameters of the TLS 1.3 QUIC connection.

[Security] Review attack and mitigation considerations for TLS 1.3 <https://github.com/webscreens/openscreenprotocol/issues/130>

8.5.2. Local active network attackers

@@ -2259,8 +2264,11 @@

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 an advertised display whose public key fingerprint collides with that +from an already-trusted display that is concurrently being advertised.

    +
  • +

    Flag an advertised display whose friendly name differs from the one previously +advertised under a public key fingerprint.

  • Flag already-trusted displays whose metadata has changed.