On Thu, Apr 24, 2025 at 3:16 PM Jelte Fennema-Nio <postg...@jeltef.nl> wrote: > Why is this dangerous? As long as we'd validate that the provided cert > by the server is for example.com
I can't help but read this as "as long as everyone mitigates the danger, what's the danger?" We won't be the only implementers of any URL schemes we introduce. > I don't see any security problem in > having DNS resolution happen for evil.com, nor in having the IP > addresses hardcoded using hostaddr. I think if we introduce a new scheme with the idea that it's "HTTPS mode", it needs to behave very similarly to HTTPS, so people reason about it correctly in worst-case corner cases. To attack an https:// connection, you need to both steal the server key _and_ get the client to talk to you instead of the real server. And for HTTPS, that second part generally requires hijacking DNS or mounting a successful MITM, not modifying the query. The idea of a query string overriding the //authority is... weird. It breaks the conventions of generic parsers (and I will include "humans" in that group). We're "allowed" to do it, I guess -- it's our scheme, we do it with our existing schemes today, and the IETF isn't going to send spec police to our doors -- but I don't think we should. Thanks, --Jacob
