W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2015

Re: Definition of secure origin in MIX and POWER

From: Mike West <mkwst@google.com>
Date: Thu, 9 Jul 2015 06:07:25 +0200
Message-ID: <CAKXHy=d=TvV36CSZa8dbwk7q4rzjojsnd_VqZRpCSEC7-UVDkQ@mail.gmail.com>
To: Devdatta Akhawe <dev.akhawe@gmail.com>
Cc: Brian Smith <brian@briansmith.org>, Francois Marier <francois@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Wed, Jul 8, 2015 at 8:57 PM, Devdatta Akhawe <dev.akhawe@gmail.com>
wrote:

> On 8 July 2015 at 09:25, Mike West <mkwst@google.com> wrote:
>
>> Note that whether `localhost` or `127.0.0.1` or any other RFC1918 URL is
>> blocked by MIX is a separate question from whether or not they should be
>> blocked, period (I think they should, modulo some sort of authentication
>> ceremony that would allow embedding). I still think this group should
>> tackle that question, and I'm still a bit sad that we dropped that
>> discussion from this iteration of MIX.
>>
>
> Exactly. My understanding was that, in the context of MIX where the threat
> model is  "network attacker" only, we had agreed that 127.0.0.1 is secure.
> If we want to tackle the question of whether or not to allow that, that
> should be a separate spec.
>

I don't remember agreeing to that. Link to a thread? :)

I do remember explicitly punting everything related to RFC 1918 origins
from the spec.


> This doesn't mean it is actually secure, as Brian notes, but there are
> many sites with valid SSL certificates that are not secure. MIX really
> shouldn't get into all that.
>

I do agree with this, to the extent that MIX can only help with assertions
about the last-mile connectivity between the user and the frontend server.
Anything that happens beyond that (reverse proxies, etc) isn't something
about which we can reliably make any assertions.

-mike
Received on Thursday, 9 July 2015 04:08:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:13 UTC