[Bug 25972] Please require a secure origin

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

--- Comment #18 from Ehsan Akhgari [:ehsan] <ehsan@mozilla.com> ---
(In reply to Ryan Sleevi from comment #16)
> (In reply to Ehsan Akhgari [:ehsan] from comment #15)
> > (In reply to Henri Sivonen from comment #14)
> > > From the Gecko Intent to Ship thread:
> > > https://groups.google.com/d/msg/mozilla.dev.platform/bwC_Srw12CM/ReD8hQ1EsDsJ
> > 
> > Ryan, I'm curious to know what your take is on the last paragraph of Henri's
> > post?
> 
> You're talking about the post with the paragraph "As for making new features
> unavailable without TLS in order to promote  the use of TLS", right?

Yes.

> I disagree with Henri's explanations for the motivations, or the analysis of
> risk, with providing the API to secure origins only.
> 
> There are two dimensions of discussion captured on this bug:
> 1) What is a secure origin/Can we find a necessary sufficient definition? 
> 2) Whether there is sufficient risk / sufficient benefit to exposing this
> API to unauthenticated origins
> 
> For 1, I'm not going to spend much time discussing it here. Boris has
> already captured some of the nuance, and I think the conversation is
> rightfully continuing on in the context of WebAppSec for discussions of
> things like Mixed Content (and how things like Blob URLs behave, service
> workers, sandboxed iframes, etc)

Fair enough.

> For 2, the issue is not and has never been about "promoting TLS" as an
> ideological point.

FWIW that is not what I was suggesting at all, and I don't believe you're
arguing for that either.

> It's about a belief, from careful evaluation of the
> security properties of this API, that there is no possible net-positive
> impact of this API surface without some form of code authentication. That
> is, we would have zero interest in implementing this API if it was
> normatively required to be available to unauthenticated origins, because
> this API would provide zero benefit to the web platform, while introducing
> significant complexity for implementors. The only benefits from this API are
> realized when delivered over authenticated transports to authenticated
> origins.
> 
> Our principal is we want new APIs to be secure by default. Having the UA
> ultimately place that decision in the author's hand by saving "caveat
> author", and providing no guidance, continues the trend of insecure by
> default, where authors can and will write applications that attempt to use
> security features insecurely. It's correct that the web platform is vast
> and, for many reasons, there are still lots of ways to shoot yourself in the
> foot. It's also true that even with this API, there are ways to shoot
> yourself in the foot (for example, unauthenticated encryption). However, for
> a new API with zero deployment, and with very real risks, it seems we have a
> unique opportunity to pursue "secure by default".

I agree with all of the above in the abstract, but my specific point was about
Henri's *last* pragraph, which I don't think you addressed in comment 16. 
Here's the scenario again:

Assuming that we require a secure origin for whether or not an app can access
this API, the developer of example.com which is hosted on a non-secure HTTP
server can embed an iframe to a page coming from a secure origin, and
postMessage() the data that it, for example, wants to encrypt to the iframe and
receive the results back.

IOW, it seems to me that restricting the exposure of this API to secure origins
doesn't actually accomplish what you're going for here.

> If this analysis is wrong, which we don't believe it is, it's something we
> can always revisit. We can expand upon the definition of what is an
> authenticated origin if we find we're too restrictive. We can potentially
> expose operations that have "no" security surface (as some claim hashing
> does not, although that's highly debatable).

I may have missed that discussion, do you mind pointing me to some explanation
on why hashing would be insecure if the document has not been transported
securely?

> But if we ship it all by
> default, that's a decision that can never be revisited. Based on the many
> uninformed discussions that have happened in this WG regarding the security
> properties of the Web, we believe the risk is real enough that the value is
> great enough to promote "secure by default".

It's true that shipping something later is easier than unshipping something,
but there's also the interoperability concern, which I think is reason enough
to try to come to an agreement before shipping incompatible implementations, as
Boris already suggested.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Wednesday, 22 October 2014 18:25:41 UTC