Subject: [rtcweb] Question on sec architecture proposal

From: Stefan Hakansson LK <[email-masked]>
Date: Sat, 7 Jan 2012 14:43:09 +0100

Hi Ekr,

reading
http://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/?include_text=1
in an effort to catch up, I noted that there is now an appendix called
"A Proposed Security Architecture". It looks like a good start for this
really important topic.

I have a few questions though, and I will start with one:

It is stated (in section A.3.2) that

"API Requirement: The API MUST provide a mechanism for the requesting
JS to relinquish the ability to see or modify the media (e.g., via
MediaStream.record()). Combined with secure authentication of the
communicating peer, this allows a user to be sure that the calling
site is not accessing or modifying their conversion."

I wonder if you could elaborate a bit more on this? It is a bit unclear
to me.

Is the idea that when requesting access to microphones and cameras there
should be a way to stop the application from doing anything else than
... with the data generated?

And in that case, anything else than what? Surely the application must
be allowed to route it to a video element (for a self view)? And surely
it must be allowed to attach it to a PeerConnection (otherwise there
will be no communication happening)?

(Sorry if I should know - i did not attend the Tapei meeting and perhaps
this was already discussed and clarified)

--Stefan

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 7 Jan 2012 06:47:11 -0800

> this was already discussed and clarified)

No need to be sorry. I suspect I glossed over this in my talk anyway...

There are a bunch of pieces of functionality that might allow the JS
to recover/modify the data even if it's end-to-end encrypted with
keys not known to the JS. For instance, it might use mediaStream.record()
to save it somewhere, or send it to a canvas which it is able to
modify or save. There are settings where these features might
be useful, but also settings where they're undesirable. So it
should be possible for a calling service to offer a "really secure mode"
where they promise not to mess with your data and the user
can verify that directly through the browser.

Does that make sense?

-Ekr

---

From: Stefan Hakansson LK <[email-masked]>
Date: Sun, 8 Jan 2012 18:48:44 +0100

> can verify that directly through the browser.

I started to think in terms of APIs, and of course with the current set 
of proposed APIs as starting point. The MediaStream would have to go (as 
it can be copied, recorded, attached to another PeerConnection or to a 
canvas etc), so I started to think about a special version of 
PeerConnection which would use mic/cam input directly. So you would as 
app developer setup a special PeerConnection and in addition tell it 
what audio/video elements to use for local (self) view and remote view.

But that still would not be enough since the app can access the media 
data via the Media elements, look at 
http://www.w3.org/TR/webaudio/#MediaElementAudioSourceNode-section for 
example.

So we are looking for a new API that allows the application to basically 
ask for secure audio and/or video communication, and to have some saying 
about the rendering (e.g. location and size of video windows), but not 
much more. The rest is handled under the hood. It is also important that 
the other end can not emulate a "really secure endpoint" by use of 
PeerConnection - because then the app at the other end would have access 
to all data.

As you indicate it would not be sufficient to have an API, because then 
the app could anyway use the more flexible APIs (getUserMedia, 
MediaStream, PeerConnection, audio/video elements) without the user 
knowing. There would also need to be some info (in the browser chrome, 
and when asking for user consent?) that the "secure communication", and 
no other tools, is used.

This might be a challenge, how should you present this? It must be easy 
to distinguish from the mic/cam being used with getUserMedia. Then there 
are assembled cases; say you want to a push-to-talk service using this 
secure API, but (when pushing another button) do some voice based input 
(http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech-20111206/#solution). 
In this case both the "secure communication" and the voice based input 
would both need access to the mic, how do you present this to the user 
in an understandable way (both when asking for consent, and in the 
chrome during use)?

Perhaps we should focus at the more flexible APIs in the first phase?

Stefan

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Sun, 08 Jan 2012 10:25:29 -0800

> much more. The rest is handled under the hood. It is also important that

I think the expectation is that this would use the same "tainting" 
mechanism used by <canvas> to prevent access to the raw media from 
cross-domain resources. So you could use the normal getUserMedia, etc., 
APIs, but if you tried to use an API that accesses the raw sample data 
(as opposed to just piping the data into an HTMLMediaElement or a 
PeerConnection), it would throw a security exception.

---

From: Stefan Hakansson LK <[email-masked]>
Date: Mon, 9 Jan 2012 14:03:37 +0100

On 01/08/2012 07:25 PM, Timothy B. Terriberry wrote:
> mechanism used by<canvas>  to prevent access to the raw media from

Sounds like a more elegant solution! Basically (to check that I 
understand correctly)

* getUserMedia would be used to ask for a "protected MediaStream"
* the user can easily understand (browser chrome?) that data generated 
by mic/cam is protected
* in the browser generating, it would be allowed to use in audio/video 
elements and in _one_ PeerConnection (and that PeerConnection _must_ use 
SRTP)
* in the browser receiving it would be allowed to use in audio/video 
elements only

Any use trying to access the data (including using the audio element as 
source) would throw security exceptions.

I guess there are still a few things to sort out, like how to convey 
this info about the MediaStream to the other end.

Stefan

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Randell Jesup <[email-masked]>
Date: Mon, 09 Jan 2012 10:46:27 -0500

>> PeerConnection), it would throw a security exception.

Correct - I can't find the reference (perhaps it was a comment made at 
last July's IETF), but I believe Tim is referring to a suggestion made 
about tainting.

This was discussed in a slightly different context around 8/17/2011 - 
for example, a message from Rich Tibbett included this:

     This section of the WHATWG spec summarizes the concept of tainting
     an object via the origin-clean flag, applied to <canvas> elements
     with content coming from a different origin:

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#security-with-canvas-elements 

> source) would throw security exceptions.

I suggest starting by going back in the archives to that period; there 
was considerable discussion of the issue.

-- 
Randell Jesup
[email-masked]

---

From: Stefan Hakansson LK <[email-masked]>
Date: Tue, 10 Jan 2012 09:22:13 +0100

On 01/09/2012 04:46 PM, Randell Jesup wrote:
....
> was considerable discussion of the issue.
Thanks for the tip, funny how things fade away from memory....

I did read up, but it seems that discussion did not really end up at a 
conclusion. And it was mostly discussed for the local context, never how 
to ensure that the data of a stream on the other end of a PeerConnection 
can not be accessed.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 10 Jan 2012 10:14:05 -0800

> to ensure that the data of a stream on the other end of a PeerConnection 

[BA] It seems to me that media security should not necessarily imply the absence of recording capabilities. 

There are scenarios (e.g. web conferences) where the presentations are routinely recorded today, and there are products that support both media security and recording. 

For example, SIPREC does not assume that recording is forbidden if SRTP is used.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 10 Jan 2012 10:17:02 -0800

On Tue, Jan 10, 2012 at 10:14 AM, Bernard Aboba
<[email-masked]> wrote:
> There are scenarios (e.g. web conferences) where the presentations are
> routinely recorded today, and there are products that support both media
> security and recording.
>

Yes, I agree with this. The requirement I am trying to get at is that the site
needs to be able to relinquish the ability to record and the user needs
to be able to know when that has happened.

-Ekr

---

From: Randell Jesup <[email-masked]>
Date: Tue, 10 Jan 2012 16:49:47 -0500

> to ensure that the data of a stream on the other end of a PeerConnection

I was talking to roc (Robert O'Callahan) last night, and he believes 
using cross-origin-type controls can be used to basically block the JS 
from getting access to the decrypted/decoded media streams.  (This 
already exists for blocking JS access to cross-origin images.)  So, no 
need to use tainting per-se.

There certainly remains the issue of when and how the JS would get 
access to the streams, and without it they wouldn't be able to use some 
of the audio "processed streams" stuff we're working on.  And if the 
user has to give permission for access, does this permission stick? 
(This is overall related to the whole "does this app/website have 
permission to access the camera & mic" issue.)

A strawman proposal might be a "secure connection" checkbox on the 
getUserMedia() popup which defaults to secure.  That may not be an 
optimum UI, however.

-- 
Randell Jesup
[email-masked]

---

From: Stefan Hakansson LK <[email-masked]>
Date: Wed, 18 Jan 2012 15:48:08 +0100

On 01/10/2012 10:49 PM, Randell Jesup wrote:
> permission to access the camera&  mic" issue.)

I think we have a lot to sort out as you indicate above. Matters are 
also complicated by the fact that (at least that is what I understood) 
that one likely way to add functionality like VU meter, possibility to 
adjust levels, panning, etc. could be provided by the use of the Web 
Audio API (so that the webrtc group does not have to re-invent a lot of 
stuff). But how do you restrict what can be done once the audio is 
available to that tool set?

Then the same rules must apply on the other end of a PeerConnection, so 
this limitation in JS access must be carried over in a really secure way 
(and ideally the sending side should get an ack from the receiving 
browser that the data can not be accessed). This is also not clear to me 
how to do.

And even if we manage to fix all this, there are other possible security 
issues, like:
* A hacked application uses a canvas to present incoming video and adds 
fake objects to the scene (I agree, a bit silly)
* A hacked application also uses voice based search API (they seem to be 
going for a lower security bar) to record

I'm not saying we should not investigate this; on the contrary I think 
this is of great interest. It is only that my personal gut feeling is 
that we should do this in an orderly fashion with a holistic view so 
that things developed in different groups (we have the Audio WG, the 
voice search work in WebApps, Web Security, discussions on a Identity WG 
etc.) fit together - and that this may take some more time than what is 
available in the current charters, and perhaps should be moved to a 
phase 2. Or maybe it's just me being overly pessimistic!
> getUserMedia() popup which defaults to secure.  That may not be an

Or the application decides if it asks for secure or not (some 
applications may not work as intended without access to the data) but 
most importantly the user is clearly informed when giving consent and 
through the icon in the browser chrome (solved in some unknown way when 
in full-screen mode!) whether the access to user data is secure or not.

---

From: Roman Shpount <[email-masked]>
Date: Wed, 18 Jan 2012 12:36:17 -0500

How realistic is what you are trying to achieve? If we cannot provide an
end-to-end identity verification during the call, and we consider
JavaScript application compromised, there is no guarantee that what the end
user is communicating with is the actual remote party and not some type of
intermediary device which is recording or modifying the media.

What we need is some sort of application specific client identity
mechanism, that can ensure that ICE candidates and key fingerprints are not
tempered with. This borders on creation of a signaling protocol, but if we
make PeerConnection take the HTTPS url of the media description signing
agent, credentials for this agent, remote party ID, and local party IDs,
issue an HTTPS request to sign the media description, and show this
information to the user (i.e. you are placing call from local party ID to
remote party ID validated by service URL), we will have a media description
that can be validated at least in the context of this specific service.
When media description is received from the remote party, the same
mechanism can be used to validate this description and show information to
the user (incoming call from remote party ID to local party ID validated by
service URL). I realize these are very rough ideas, but unless we close
this hole, all other security measures can be easily circumvented.
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Jan 2012 09:43:49 -0800

On Wed, Jan 18, 2012 at 9:36 AM, Roman Shpount <[email-masked]> wrote:
> end-to-end identity verification during the call, and we consider JavaScript
> application compromised, there is no guarantee that what the end user is
> communicating with is the actual remote party and not some type of
> What we need is some sort of application specific client identity mechanism,
> that can ensure that ICE candidates and key fingerprints are not tempered
> with. This borders on creation of a signaling protocol, but if we make
> PeerConnection take the HTTPS url of the media description signing agent,
> credentials for this agent, remote party ID, and local party IDs, issue an
> HTTPS request to sign the media description, and show this information to
> the user (i.e. you are placing call from local party ID to remote party ID
> validated by service URL), we will have a media description that can be
> validated at least in the context of this specific service. When media
> description is received from the remote party, the same mechanism can be
> used to validate this description and show information to the user (incoming
> call from remote party ID to local party ID validated by service URL). I
> realize these are very rough ideas, but unless we close this hole, all other
> security measures can be easily circumvented.

See Section A.3.6 of draft-ietf-rtcweb-security-01

-Ekr