Re: Security considerations - a proposal

On Apr 23, 2014, at 9:27 AM, Harald Alvestrand <harald@alvestrand.no<mailto:harald@alvestrand.no>> wrote:

On 04/23/2014 06:20 PM, Martin Thomson wrote:
On 23 April 2014 04:53, Harald Alvestrand <harald@alvestrand.no<mailto:harald@alvestrand.no>> wrote:
Security considerations
Most of these considerations are comm-sec issues that are already
handled in various IETF documents.

I've no fundamental objection to that, particularly as a set of
pointers, but I think that the focus needs to be on the web platform.
There are probably a bunch of web platform issues that we need to
highlight.  One that springs to mind is the range of concerns around
user consent or lack thereof.  Noting that a data channel can be
created to an arbitrary peer without user consent, and why, might go
some way to addressing a commonly raised, but invalid concern.  Less
necessary, but in a similar vein, is discussion of access to
processing and bandwidth resources.
At the moment, we don't have any user consent features in the webrtc part of WebRTC, and I'd like to keep it that way. It could be good to make that decision explicit here.


Rereading this reminded me to go back and check out draft-ietf-rtcweb-security-arch-09, specifically section 5.5.  While I agree we don't call out user consent features, there is a small section of UI MUST and SHOULDs.  Interestingly, in some conversations, there is ambiguity in the term "client" and whether it becomes the responsibility of the app.  For instance in the doc there is "client", "user oriented client", and "browser client".

The section I am specifically looking at calls out:

 UI Requirements: A user-oriented client MUST provide an
 "inspector" interface which allows the user to determine the
 security characteristics of the media.
 The following properties SHOULD be displayed "up-front" in the
 browser chrome, i.e., without requiring the user to ask for them:
 * A client MUST provide a user interface through which a user may
 determine the security characteristics for currently-displayed
 audio and video stream(s)
 * A client MUST provide a user interface through which a user may
 determine the security characteristics for transmissions of
 their microphone audio and camera video.
 * The "security characteristics" MUST include an indication as to
 whether the cryptographic keys were delivered out-of-band (from
 a server) or were generated as a result of a pairwise
 negotiation.
 * If the far endpoint was directly verified, either via a third-
 party verifiable X.509 certificate or via a Web IdP mechanism
 (see Section 5.6) the "security characteristics" MUST include
 the verified information. X.509 identities and Web IdP
 identities have similar semantics and should be displayed in a
 similar way.

Given the "SHOULD" clause calls out "browser chrome", my reading of the above is that these are actually browser requirements.  Another reading might be an enablement of an application to surface this information through a call to the browser itself.

Since I've run into some ambiguity in discussions, it might be helpful to clarify whether or not "client" specifically refers to the end point implementing the WebRTC API.

Thoughts?
-jim spring