Subject: [rtcweb] security-arch: 6.4.1 PeerConnection Origin Check

From: Michael Procter <[email-masked]>
Date: Mon, 21 Jul 2014 19:51:17 -0400

Section 6.4.1 begins like this:

   Fundamentally, the IdP proxy is just a piece of HTML and JS loaded by
   the browser, so nothing stops a Web attacker o from creating their
   own IFRAME, loading the IdP proxy HTML/JS, and requesting a
   signature.  In order to prevent this attack, we require that all
   signatures be tied to a specific origin ("rtcweb://...") which cannot
   be produced by content JavaScript.

The corresponding section in the w3c draft (8.1.2, bullet 2) describes
how this is achieved, based on the principle of communicating via a
MessageChannel identified by a variable that cannot be set by another
page.  I suggest removing the text about tying signatures to specific
origins (and also the mention of HTML), so that the beginning of 6.4.1
looks more like:

   Fundamentally, the IdP proxy is just a piece of JS loaded by
   the browser, so nothing stops a Web attacker from creating their
   own IFRAME, loading the IdP proxy JS, and requesting a
   signature.  In order to prevent this attack, we require that communication
   with the IdP proxy be via a MessageChannel in a way that cannot
   be emulated by hostile JS.  This is discussed in section 8.2.1 of
[webrtc-api].

Regards,

Michael

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Jul 2014 09:01:53 -0700

>    be emulated by hostile JS.  This is discussed in section 8.2.1 of

I'm having a hard time finding a fault with your suggestions Michael.
This is great, thanks.

---

From: Michael Procter <[email-masked]>
Date: Tue, 22 Jul 2014 21:43:04 -0400

Pull request on github, issue 15.