Re: [w3ctag/design-reviews] CORS-RFC1918 (#572)

Thanks Martin for the review. I apologize in turn for taking a while to respond.

> it will likely provide meaningful improvements for services that are inadequately protected by means other than firewalls.

I would go further and add that the intent is to provide meaningful improvements for services that *are* protected by firewalls. Indeed, an IoT device might think it's well protected if it sits behind a firewall, but still receive HTTP requests crafted by `evil.com`.

Regarding user consent, as I just replied on WICG/private-network-access#42, I agree. I think we can downgrade that recommendation to `MAY` rather than `SHOULD`.

> This proposal is no substitute for services providing encryption and proper access controls. This proposal does not protect adequately against true cross-protocol attacks that use either unencrypted HTTP or attacker-controlled components of TLS handshakes to attack poorly-protected servers from the vantage point of a client (we have a port number blocklist that is designed to help, but we know that too is not perfect).

Very true. Filed https://github.com/WICG/private-network-access/issues/43 to mention this in the spec.

> this proposal cannot protect services that are reachable from globally reachable addresses. If a firewall protects services that can be reached with a globally reachable address, even if that service is not genuinely globally reachable due to the firewall, then the consent check will not be engaged and the service might be vulnerable to attack.

Also true. Filed https://github.com/WICG/private-network-access/issues/44 for this.

> It seems like this could use a structured field, but I realize that the original version of this predates that work by a lot.

Good point. We have not yet started implementing the preflights, so we might as well modernize the spec while it's cheap to do so. Filed https://github.com/WICG/private-network-access/issues/45 for this.

>I couldn't work this out quickly: does the preflight result in revealing that a server exists at the identified address/name? That is, does this change make service enumeration on private address ranges easier, no different, or harder?

>  The preflight shouldn't result in new information leakage. I don't think it changes anything as far as service enumeration goes.

+1. Timing attacks are already possible that reveal which IP adresses exist on the private network. The preflight would not change that - it offers no protection, and neither does it leak additional information. See also https://github.com/WICG/private-network-access/issues/41.

> Another deliberate exclusion here is that servers that are already in a "private" context can attack each other without engaging the additional consent protections. My understanding is that this exclusion exists for two reasons: 1. because we assume that these services can already talk to each other, and 2. so that enterprise services can "talk" to each other.

> There is an open issue on requiring the preflight whenever you go across origins on non-public addresses, but it would likely result in significant breakage so that's not part of the initial plan.

Indeed, see https://github.com/WICG/private-network-access/issues/39.

> Acknowledging that these choices are deliberate would be good.

Agreed. This is mentioned briefly as `ISSUE 2` in https://wicg.github.io/private-network-access/#integration-fetch. It would be good to harmonize that section with https://wicg.github.io/private-network-access/#private-network-request-heading. Filed https://github.com/WICG/private-network-access/issues/46.

> FWIW, I don't think that it would hurt to treat loopback to loopback as a "private" request, though the compatibility risk involved with restricting lateral movement within networks probably makes the same constraint harder to apply at the next layer out.

I'm not sure about the compatibility risk of breaking loopback to loopback. Since this is a strictly additive change, I would be in favor of deferring it along with https://github.com/WICG/private-network-access/issues/39.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/572#issuecomment-818710350