Re: [Doh] WG Review: DNS Over HTTPS (doh)

Warren Kumari <> Fri, 22 September 2017 16:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 717CC134535 for <>; Fri, 22 Sep 2017 09:24:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5Rxjv33habFP for <>; Fri, 22 Sep 2017 09:24:47 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AA12B134530 for <>; Fri, 22 Sep 2017 09:24:45 -0700 (PDT)
Received: by with SMTP id r74so5397466wme.4 for <>; Fri, 22 Sep 2017 09:24:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zgfibPyeGydfI1bIsTT0DssylYO2CNJ8CA58LkQpw+0=; b=qq4ME2wFD51JqqRR0JKKZu3w671JycQe7bFKoRJ95rNBIFogjGtvKOOYPez4BkMYce SLWqALpcoAmePXP+q1fnsEBhF/lSmLiWspUrKnFIKtAMtKpwMZS6w4B/OMMf3sNQvFbD WjA3o++P/GMmQc9pYQIFJLsEz8g0AZSlLpazQiZQkPUZfHIlZqolYD+g6mwie6eI4SRh nirEMRI0OmxfSAfArfOgHHxqA30p7+MWu+sk2AE2VrX9KoK4L62VvIfz/jEPdkZE5Hu/ ysajaQguAUIFuI8VTJRuVm/j+EF/d+AYPMaKQT1x2y6zFIdx3Uu+nvwtCmh0E2SqHX83 CsaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zgfibPyeGydfI1bIsTT0DssylYO2CNJ8CA58LkQpw+0=; b=RfiFwB1ZySw9sgjzDEhRF6PztrKveeoMsKNeUPfB5bnjfe5xKnymU8RcsFhySKjMS9 VEZ9/h8Ypu/CeQl4/e78zl17A8x1cLI4+v/JC9gZ+fPSrkTTrawTUCBGacs5CINWFE5X X4kOvjLSbKuEfNe03RlAG0/cvenKq9K4cQqPWXhFXO3oIFvgP52KNmQY4wmFf07Jb0qK Oz0g+hYPXXEIJo3aNQSbqMSidoRn56+FXV920S96spMS4GntnP5YLuJVrcbCR1RJcTer ogoGDDaCj7iQly4ahPMNYQ2k8scT9k553JAvoXl3WHaVZK6dkfw9we8PUZG7eSvCeKlm cJgg==
X-Gm-Message-State: AHPjjUiW9TyZeu/gBjxSQiVtoWwmh5+FAujLLDdUxDKHIOIx2rFOyySb UYw/cFrIdvkZy8JkGiuWpBW1XUX+scJf5G8zh3mwrg==
X-Google-Smtp-Source: AOwi7QAp63+QrnSxi4umpfCM/5h6lZL48C/e8rbHcvltvGZZb0ymYWIMjpsNMeph7vz2pBYi1yUXysfGS2I+lnClJ4I=
X-Received: by with SMTP id j195mr218535wmg.124.1506097483881; Fri, 22 Sep 2017 09:24:43 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 22 Sep 2017 09:24:02 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Warren Kumari <>
Date: Fri, 22 Sep 2017 12:24:02 -0400
Message-ID: <>
To: Tony Finch <>
Cc: Ted Hardie <>,, IETF <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
X-Mailman-Approved-At: Fri, 22 Sep 2017 13:53:29 -0700
Subject: Re: [Doh] WG Review: DNS Over HTTPS (doh)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Sep 2017 16:24:48 -0000

On Fri, Sep 22, 2017 at 8:12 AM, Tony Finch <> wrote:
> Ted Hardie <> wrote:
>> I think you're underestimating the value of a switch to a multiplexing
>> facilitating protocol/transport.  Once this has gotten its legs under it, I
>> suspect that this approach for connecting to caching resolver will perform
>> better than any of traditional upd/tcp connections or the tls/dtls
>> approaches DPRIVE created.
> DNS over TCP already supports out-of-order responses. The reason it has
> historically not performed very well is that server implementations have
> handled queries on a TCP connection serially rather than concurrently.
> But this is improving. BIND 9.11 (for example) supports concurrent queries
> with out-of-order responses over TCP and TCP fast open, so queries over
> TCP should perform well, and better than UDP for large responses.

Yup -- RFC7766, S6.2.1.1 says you should do this, as does RFC7858
("Specification for DNS over Transport Layer Security (TLS)").

So, these are only my personal views / no hats / etc, but to my mind
one of the main reasons that I'd like to see Doh! succeed is for
censorship resistance (in parallel with the dprive work).
Currently plain-text DNS leaks a huge amount of privacy information;
DPRIVE solves much of this, but one weakness is that it is still
clearly DNS traffic[0]. This allows bad, evil, no-good totalitarian
regimes to block it and force you to use resolvers under their control
and so can control what you can reach, or watch where you are going
and send the secret police to "re-educate" you if you are looking at
things you shouldn't be.
Now, reread the previous sentence with s/ bad, evil, no-good
totalitarian regimes / friendly corporate IT folk / and s/ the secret
police / human resources /.
This allows friendly corporate IT folk to block it and force you to
use resolvers which they control and so can contol what you can reach,
or watch where you are going and send human resources to re-educate
you if you are looking at things you shouldn't be.

This is (I believe) what Elliot was pointing out -- this is important
information for enterprises - it is used to limit liability, ensure
employees are not "wasting time", and corporate security to detect
that they need to re-image Bob's machine *again* because he persists
in clicking questionable links and installing random bits of malware.

Unfortunately you cannot separate case 1 from case 2 -- if you make it
something that enterprise folk can detect / block (on BYOD devices)
then you have provided that facility to everyone. I believe that this
is simply the "encryption should be outlawed / backdoored because it
helps <insert bad guy here>." argument in another guise[1].

If Doh! is done right in my view it should be indistinguishable from
other web traffic and / or the collateral damage from blocking it
would be (hopefully!) politically untenable.

[0]: either because it is using the domain-s ports (853) or through
fingerprinting / heuristics of the TLS stream if you do something like
just run it over port 443.
[1]: luckily this isn't at all controversial, and isn't going to suck
this thread down another rat-hole.

> Tony.
> --
> f.anthony.n.finch  <>  -  I xn--zr8h punycode
> Faeroes, Southeast Iceland: Southeasterly 4 or 5, increasing 6 to gale 8
> later. Moderate or rough, occasionally very rough later. Showers, rain later.
> Good, becoming moderate or poor later.

I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.