[Bug 27271] Normatively require https for all ancestor origins when requiring https at all

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27271

--- Comment #5 from David Dorwin <ddorwin@google.com> ---
(In reply to Ryan Sleevi from comment #2)
> (In reply to Henri Sivonen from comment #0)
> > (Start proposed spec text for a *normative* section)

This is helpful text, but we need to figure out how to integrate it.

The proposed normative addresses a hole in a non-normative section. (The second
proposed paragraph is a Note and thus non-normative anyway.) We seem to be
heading towards moving more privacy and security considerations to normative
text, so this issue may eventually go away.

I hope we can normatively address these concerns in the algorithms (currently
blocked by bug 26332). If that change is sufficient, non-normative text
describing these requirements or a Note below the step explaining the behavior
may be sufficient.

For now, maybe we should integrate Henri's proposed text and add an Issue box
to make the section normative. Maybe we need an umbrella bug for making (more
of) the considerations sections normative.
> > 
> > When the User Agent is limiting the support of the APIs described in this
> > document or a specific Key System to secure origins, the secure origin
> > requirement MUST apply not only to the origin calling the APIs described in
> > this document but also to all the ancestor origins in the browsing context
> > chain up to and including the top-level browsing context.
> 
> Would it be possible / should we incorporate the language from
> https://w3c.github.io/webappsec/specs/mixedcontent/#may-document-use-
> powerful-features , which makes it clearer as to the algorithm necessary to
> process this?

Yes, we should reference a central definition of expected behavior. Does this
algorithm cover the scenarios about which Henri is concerned?

Note that the normative algorithm step that addresses origins currently
references http://www.w3.org/TR/mixed-content/#authenticated-origin, which has
since been removed from the Mixed Content Editor's Draft. I will update that
step to use a newer reference.
> 
> > 
> > Note: This ensures that a network attacker cannot work around the secure
> > origin restriction by injecting an iframe with a attacker-hosted
> > https-origin document into an http-origin victim page. Also, this makes it
> > harder for a site to foil the intended privacy properties of the secure
> > origin restriction by exposing EME messages to an insecure origin by using
> > postMessage() to send data to an insecure-origin parent browsing context.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 10 November 2014 21:47:05 UTC