Hiya,
I had a pretty quick read of this. I haven't followed this discussion in detail though, so am not claiming to be that well informed. I'm not that convinced by it tbh - it seems that running DNS/Tor is quite doable for at least some clients so it may well be that it'd be as or more valuable to explore how to make that work better, and/or to compare this design vs. DNS/Tor or other designs in various scenarios before adopting something like this. (In full-disclosure mode: I think it'd be great if we managed to figure a way to include Tor in our standards, if we can do that without distracting the Tor people too much, and maybe DNS/Tor could be a tractable option there, so I have a bit of a bias towards exploring that design, but without being willing to devote the effort required myself, so that's both a bias and me being a hurler-on-the-ditch [1]:-) The apparently impending work on oblivious HTTP is also a negative here, for me, due to the danger of duplication of scarce effort. There's also lots of scope for (O)DoX confusion if we do this now. Publishing this via the ISE and running experiments, then bringing those results to the WG may be a good way to proceed, should the proponents want to do that. Or maybe experimenting on this in PEARG could be a better route. I do like the idea of improving DNS privacy by making it harder to track a single client's queries though, so I'm not totally against this by any means. On the draft itself: - I'm not clear as to the overall efficacy of the approach, given deployment realities - it may make more sense to first adopt a work item to explore the design space of proxied DNS (or some form of gossip as another commenter noted) before adopting a specific solution as a WG draft. The draft itself quite reasonably points out that it's early days for this work, so I'm not sure if we'd be better to adopt a design now or to wait some, but I suspect "wait some" is the better conclusion for now. - The danger of things like XFF/Forwarded seems real, should this get widely deployed. I wondered if a scheme where the entire proxy->target HTTP request (or similar octets) are embedded into the target's encryption could allow a client to detect that a proxy is not sending only the expected HTTP headers etc. That'd likely require some form of "test query" be sent to multiple targets via the same proxy, with perhaps one of the targets being the client itself. The idea would be to try detect cheating proxies. I'm sure that's naive in various ways, but again for me that argues for adopting a work-item to explore a bigger design space than just this draft may be right. (And apologies in advance if my quick scan of the draft missed a discussion of such ideas.) Lastly, typing all the above has nearly convinced me that the right outcome here is probably: GOTO PEARG. Cheers, S. [1] https://idioms.thefreedictionary.com/hurler+on+the+ditch
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
