Subject: [dns-privacy] DoH vs DoT at IMC 2019

From: Timm Boettger <[email-masked]>
Date: Wed, 11 Sep 2019 09:52:48 +0000

Hi all,

Rob Sayre has pointed me to this thread. I am an author of the linked paper.

He has pointed out some confusing and outdated information in the paper, that I would like to clarify: The version currently available at http://eecs.qmul.ac.uk/~boettget/assets/doh-imc19.pdf was created and correct as of October 2018. In the meantime, things have changed, Google for example today also supports DoT and TLS 1.3 (c.f. Table 2). We are currently working on an updated version which includes changes in the available services as well as explicitly lists timestamps when the data was collected. This version should hopefully be available by end of this week.

If you have further comments, though or feedback on the paper, please feel free to share, I would love to hear them.

Once again, Rob, thanks for pointing me to this thread.

Cheers
Timm

---

From: Rob Sayre <[email-masked]>
Date: Wed, 11 Sep 2019 22:37:28 -0700

On Wed, Sep 11, 2019 at 2:53 AM Timm Boettger <[email-masked]>
wrote:

> Hi all,
>
> Rob Sayre has pointed me to this thread. I am an author of the linked
> paper..
>
> He has pointed out some confusing and outdated information in the paper,
> that I would like to clarify...
>

Let me further clarify: I thought these were minor corrections, and I
didn't want these small flaws to undermine a great point the paper made in
its Section 3:

"Implementing out-of-order delivery via TLS is akin to (re-)implementing
the stream multiplexing part of SCTP, QUIC or HTTP/2.0."

thanks,
Rob

---

From: Petr Špaček <[email-masked]>
Date: Thu, 12 Sep 2019 10:59:42 +0200

On 12. 09. 19 7:37, Rob Sayre wrote:
> On Wed, Sep 11, 2019 at 2:53 AM Timm Boettger <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi all,
> 
>     Rob Sayre has pointed me to this thread. I am an author of the linked paper...
> 
>     He has pointed out some confusing and outdated information in the paper, that I would like to clarify...
> 
> 
> Let me further clarify: I thought these were minor corrections, and I didn't want these small flaws to undermine a great point the paper made in its Section 3:
> 
> "Implementing out-of-order delivery via TLS is akin to (re-)implementing the stream multiplexing part of SCTP, QUIC or HTTP/2.0."

It should be noted that out-of-order query processing is in no way unique to TLS, it is the same for TCP (see RFC 5966 section 6).

It should also be noted that Knot Resolver (which I'm working on), BIND and also modern versions of Unbound _do_ support out-of-order query processing so the point above it moot. (I'm not sure about PowerDNS but I would be surprised if it did not have out-of-order processing support as well.)

Missing support on a particular service is not caused by lack of implementations in servers, maybe it is a problem "added" by layers on top.

Petr Špaček  @  CZ.NIC

---

From: Vladimír Čunát <[email-masked]>
Date: Tue, 17 Sep 2019 17:15:33 +0200

> [...] Implementing out-of-order delivery via TLS is akin to
> (re-)implementing the stream multiplexing part of SCTP, QUIC or
> HTTP/2.0. We believe that this is one of the main reasons why
> DNS-over-TLS failed to gain significant traction.

The last sentence really surprises me.  I'm actually not convinced that
protocol details like this can *directly* affect large-scale adoption,
so to find this it might be more interesting to ask the most popular DNS
clients why they chose the way they did.  AFAIK it's not too common to
support both (equally).  I would think the main reasons will be far from
the suggested one, but I didn't try to find out... except that for web
browsers it's probably natural to prefer DoH, as they're all built
around http(s).

--Vladimir

---

From: Puneet Sood <[email-masked]>
Date: Mon, 23 Sep 2019 10:58:44 -0400

> It should be noted that out-of-order query processing is in no way unique to TLS, it is the same for TCP (see RFC 5966 section 6).

The Google Public DNS DoT implementation supports out-of-order
responses so I am surprised that your experiment found that only
CloudFlare's implementation supports out-of-order delivery. Maybe this
is changed in the updated version of your report.

-Puneet

> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Puneet Sood <[email-masked]>
Date: Mon, 23 Sep 2019 11:02:04 -0400

> browsers it's probably natural to prefer DoH, as they're all built

The fact that browsers are under active development and prefer HTTPS
while client OS DNS APIs have seen minimal changes (barring the
efforts of the getdns project, support for DoT in Android 9) in the
past decade is a more likely reason for the differences in DoH and DoT
adoption.

-Puneet