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

I apologize for the delay here, but I've started [a conversation about this](https://mailarchive.ietf.org/arch/msg/architecture-discuss/eYJ6XLyuzYxcwuYSm334W2F-72Y).  My read is that this an entirely appropriate application of the addressing architecture and it will likely provide meaningful improvements for services that are inadequately protected by means other than firewalls.

I have a couple of minor concerns with the proposal:

* The strong recommendation that user consent be sought is not a good idea.  Though I believe that many things are permissible here when it comes to consent, I don't believe that this is necessary.  The mechanism here gives the server the ability to consent to communication, and it is the one that generally stands to lose.  While there might be value in giving people control over the destinations that sites can contact, this is a generic one that applies no matter what the destination address happens to be.  In practice however, most people find that sort of granular control to be cumbersome and often rely on blocklist services and other tools (see ad blockers and various "firewall"-type addons).  I would be more interested here in whether there is a case for user override than in an insistence on additionally getting user consent to communicate.

* This is primarily about harm minimization.  It seems like we are able, after more than 15 years of CORS, to start to close the loopholes in the design, which is good.  However, the document needs to be much clearer about the limitations of the protections it offers.  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).  Critically: 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.

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

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?

(I agree with Anne that this is almost entirely a Fetch feature and this should probably move to a pull request on that specification.)

-- 
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-810782778