Re: [dns-privacy] WG Call for Adoption: draft-pauly-dprive-oblivious-doh

[Stephen Farrell <[e-mail]>]

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