On Tue, Jan 5, 2016 at 12:07 AM, Erik Nygren <erik+w3@nygren.org> wrote:
> MDNS names (such as "example.local") also provide a way to get at these
> resources without needing to probing adjacent address space since they may
> resolve to public IPv4 or public IPv6 addresses. One way of tackling those
> could be to treat ".local" names as all being private regardless of what
> IPs they resolve to.
>
Adding `.local` makes sense to me, thanks!
> I agree that there are some cases like localhost in particular where this
> is straight-forward (and especially valuable as part of a "(http,localhost)
> as secure origins for sub-resources but requiring CORS" story).
>
Right. I think I noted in the doc that enforcing these limitations would
make me happier about not blocking `http://[loopback]` as mixed content.
I'm not happy at all about doing that in the status quo.
On Mon, Jan 4, 2016 at 5:40 PM, Nottingham, Mark <mnotting@akamai.com>
> wrote:
>
>> Are we trying to defend against the case where an attacker looks at the
>> global IPv6 address of the UA and then crafts the attack to probe adjacent
>> space (i.e., within the delegated prefix)?
>>
>
I would like to do this. It sounds like y'all are telling me that that's
hard to do in a well-defined way.
> Or are we just trying to provide (imperfect) defence in depth against
>> attacks against sloppy local services that assume being behind NAT means
>> they're safe?
>>
>
Certainly this.
> I think Richard is on a pretty good path -- expose the primitives that we
>> have reasonably easy access to, and figure out reasonable default
>> behaviours for each.
>>
>
I still don't follow Richard's proposal. What do you think he's suggesting?
:)
> P.S. Maybe this is an opportunity to reopen a discussion of OPTIONS-free
>> CORS; some of these things get quite chatty.
>>
>
Certainly worth exploring. I think you have a concrete proposal floating
around somewhere? Might be worth a separate thread.
-mike