Subject: [dns-privacy] DNS over HTTPS via HTTP proxies

From: [email-masked]
Date: Mon, 19 Jul 2021 13:00:20 +0900 (JST)

People who interests stub resolver's privacy,

I submitted new draft "DNS over HTTPS via HTTP proxies" last week.
https://datatracker.ietf.org/doc/draft-fujiwara-dprive-doh-via-httpproxy/

It is a rewrite of the OARC 35 presentation.
https://indico.dns-oarc.net/event/38/contributions/858/attachments/798/1467/doh-202105060305.pdf

It relates to Oblivious DNS over HTTPS, however, it does not propose
new protocols and new proxy software.
(it uses HTTP/1.1 CONNECT Method.)

I will be happy
if some providers offer "open HTTP proxies for DoH providers"
and application software developpers implement "DoH via HTTP proxy"
in applications (browsers).

# Software needs two proxy settings for DoH and other HTTP targets.

Regards,

--
Kazunori Fujiwara, JPRS <[email-masked]>

---

From: Alec Muffett <[email-masked]>
Date: Mon, 19 Jul 2021 05:21:45 +0100

Good morning!  I am delighted to see more research in this space!

I would like to humbly offer my previous work for review, which may slot
into your other concepts. This paper and presentation was given at NDSS21
earlier this year:

A Year of DNS over HTTPS over Tor
https://github.com/alecmuffett/dohot/blob/master/papers/no-port-53-who-dis-presentation-2.0.pdf
https://github.com/alecmuffett/dohot/blob/master/papers/no-port-53-who-dis-paper-3.1.pdf
https://www.ndss-symposium.org/ndss-paper/auto-draft-124/

I would be also delighted to share notes and experiences (offline?) if they
might be of interest to your work.

Best wishes,

    - a

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 19 Jul 2021 14:46:27 +1000

Hi Kazunori,

I don't know if you are aware of this, but there is discussion about forming a working group for something like ODoH: [email-masked] is the mailing list.  This - just like oblivious DNS more generally - is aimed at providing one additional privacy feature that your proposal does not: that of longitudinal privacy.  That is, it aims to ensure that DNS resolvers aren't able to assemble profiles on people based on the set of queries they make.  As deanonymization techniques are surprisingly effective, the hope is that this would go a long way to break up query flows, while avoiding added latency and overhead.

An HTTP proxy can be used in a way that breaks linkability, but it costs a lot of time and CPU.  The TOR model has the same query linkability issue and even worse performance.  The HPKE-based design in OHTTP (which is fundamentally the same as Oblivious DNS/DoH) trades performance for replay risk.  As DNS queries are naturally pretty resilient to replay, this seems like a pretty good deal.

On Mon, Jul 19, 2021, at 14:00, [email-masked] wrote:
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Alec Muffett <[email-masked]>
Date: Mon, 19 Jul 2021 06:53:03 +0100

On Mon, 19 Jul 2021, 05:47 Martin Thomson, <[email-masked]> wrote:

>
> An HTTP proxy can be used in a way that breaks linkability, but it costs a
> lot of time and CPU.  The TOR model has the same query linkability issue
> and even worse performance.
>

Hi Martin! This is a not an attack, I intend this as a genuine question: I
would be interested to know what you feel constitutes "acceptable
performance" - because of the clear outcomes of my work was that running
DNS queries over Tor was of comparable latency to many people's experience
of running local "advert-filtering" stub revolvers such as PiHole.

As such, I for one am no longer concerned about ever-lower latency, as
opposed to "good enough".

I would be really interested in what you considered "good enough"?

-a

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 19 Jul 2021 16:27:17 +1000

On Mon, Jul 19, 2021, at 15:53, Alec Muffett wrote:
> 
> Hi Martin! This is a not an attack, I intend this as a genuine 
> question: I would be interested to know what you feel constitutes 
> "acceptable performance" - because of the clear outcomes of my work was 
> that running DNS queries over Tor was of comparable latency to many 
> people's experience of running local "advert-filtering" stub revolvers 
> such as PiHole.
> 

Based on your paper, it looks like you essentially open a connection to the DoH server and then use that for DNS queries.  To that end, you would drop that connection only when idle.  Otherwise you would get connection reuse.  (I don't know what you have for resumption, but if you are using TLS 1.3, that shouldn't hurt performance that much.) 

Given that most sites involve a bunch of DNS queries (or hundreds), if you are web browsing that means that any circuit setup and connection establishment costs are paid about most once for each page view.  You still pay some latency cost for bouncing around the TOR network, but your tests show that while it is large, it's not so bad that it makes the whole thing unusable.  Your paper shows a p50 of just over 400ms for most of the DoH servers compared to 1500ms for DoHoT.  

I was speculating about a different baseline, where you might create a new connection for every DNS query.  At that point, TOR could be as much as twice as slow again.

If you go to one connection for each query, which would be required to get equivalent privacy to OHTTP, that adds another round trip to each query.  That could make DoHoT jump to as much as double, depending on what sort of proportion of your queries need to go to authoritative servers.  3s per query, along with all the extra overheads for circuit and connection setup, is much less appealing.

Cloudflare's oblivious DoH results (https://arxiv.org/pdf/2011.10121.pdf) are consistent with yours, showing p50 at ~150ms for DoH, ~300ms for ODoH, and ~700ms for DoHoT.  That's ~2x for ODoH and >4x for DoHoT.  And time is not the only relevant metric.  That used persistent connections, so DoHoT has worse privacy than ODoH.  And it is far more expensive to terminate lots of connections if you were seeking the privacy gains of ODoH/OHTTP.

Paying an extra round trip on a per-query basis is still something you could make your own judgment about.  Speaking as a browser-maker, even the 4x slowdown that comes from TOR with connection reuse would give us pause if we were thinking of deploying this for a lot of users.

The overheads of OHTTP/ODoH are not trivial, but when performance is not so bad and privacy is better, it's a trade-off worth considering.  (We're in the process of setting up our own experiments, which will consider the effect on web browsing, because doubling DNS query time might sound bad, but DNS is still a relatively small component of overall load times.)

Cheers,
Martin

p.s., I am not aware of any studies on the effect of PiHole on performance, but I would be surprised if it were significantly worse than baseline.  If it is that much worse, that would be a noteworthy result.

---

From: Alec Muffett <[email-masked]>
Date: Mon, 19 Jul 2021 07:52:27 +0100

Oooh, I'm sorry, but based on what you write, you must really have skimmed
the paper very lightly.

- The DoHoT solution uses a dnscrypt-proxy stub to actively load-balance
between a pool of DoH servers, accessing them all over Tor.
- Only one of those servers is a Tor Onion server (run by Cloudflare) but
all of the DoH servers, that included, are accessed over Tor.
- With this system, measuring 1.6 million uncached requests, p50 resolution
time over the measured period was 464ms
- With this system, measuring the above + an additional 770k cache-hits,
the p50 resolution time over the measured period was 262ms
- The Onion-Networking DoH server tends to perform least well, with a p50
of 1563ms (your figure?) but it's kept in the pool anyway, as a fallback
- The loadbalancing either defrays or spreads (depending on how you look at
it) the risk of fingerprinting
- The dnscrypt-proxy stub sanitises / makes uniform, all lookups in order
to reduce/remove browser-fingerprinting and instance-to-instance
fingerprinting
- Per the paper: "Any [load-balanced] request that exceeds 10 seconds is
killed, and in a small nod towards performance-over-privacy, the default 30
second "keepalive" is retained to reduce renegotiation-loading upon the
server pool."

In short: the "p50 of just over 400ms for most of the DoH servers" which
you cite for DoH, is *actually *the p50 for the overall DoHoT solution.

464ms *is* the figure for running DoH-over-Tor, using an active stub load
balancer - and 262ms using caching, which puts it into competition with
ODoH - and the paper shows that such performance is comparable to PiHole,
as you will see in the graphs and tables in both the presentation and the
paper.

The section "Potential Confusion" in the paper, spells out - "DoHoT uses
Tor, but is not limited to Onion Networking" - the confusion which you
encountered.

And I still don't know what you would consider to be "acceptable
performance", please?

    - alec

On Mon, 19 Jul 2021 at 07:27, Martin Thomson <[email-masked]> wrote:

> Based on your paper, it looks like you essentially open a connection to
> the DoH server and then use that for DNS queries.  To that end, you would
> drop that connection only when idle.  Otherwise you would get connection
> reuse.  (I don't know what you have for resumption, but if you are using
> TLS 1.3, that shouldn't hurt performance that much.)
>
> Given that most sites involve a bunch of DNS queries (or hundreds), if you
> are web browsing that means that any circuit setup and connection
> establishment costs are paid about most once for each page view.  You still
> pay some latency cost for bouncing around the TOR network, but your tests
> show that while it is large, it's not so bad that it makes the whole thing
> unusable.  Your paper shows a p50 of just over 400ms for most of the DoH
> servers compared to 1500ms for DoHoT.
>
> I was speculating about a different baseline, where you might create a new
> connection for every DNS query.  At that point, TOR could be as much as
> twice as slow again.
>
> If you go to one connection for each query, which would be required to get
> equivalent privacy to OHTTP, that adds another round trip to each query.
> That could make DoHoT jump to as much as double, depending on what sort of
> proportion of your queries need to go to authoritative servers.  3s per
> query, along with all the extra overheads for circuit and connection setup,
> is much less appealing.
>
> Cloudflare's oblivious DoH results (https://arxiv.org/pdf/2011.10121.pdf)
> are consistent with yours, showing p50 at ~150ms for DoH, ~300ms for ODoH,
> and ~700ms for DoHoT.  That's ~2x for ODoH and >4x for DoHoT.  And time is
> not the only relevant metric.  That used persistent connections, so DoHoT
> has worse privacy than ODoH.  And it is far more expensive to terminate
> lots of connections if you were seeking the privacy gains of ODoH/OHTTP.
>
> Paying an extra round trip on a per-query basis is still something you
> could make your own judgment about.  Speaking as a browser-maker, even the
> 4x slowdown that comes from TOR with connection reuse would give us pause
> if we were thinking of deploying this for a lot of users.
>
> The overheads of OHTTP/ODoH are not trivial, but when performance is not
> so bad and privacy is better, it's a trade-off worth considering.  (We're
> in the process of setting up our own experiments, which will consider the
> effect on web browsing, because doubling DNS query time might sound bad,
> but DNS is still a relatively small component of overall load times.)
>
> Cheers,
> Martin
>
> p.s., I am not aware of any studies on the effect of PiHole on
> performance, but I would be surprised if it were significantly worse than
> baseline.  If it is that much worse, that would be a noteworthy result.
>

-- 
https://alecmuffett.com/about