Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-reid-doh-operator

Brian Dickson <> Sun, 24 March 2019 21:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 885F112012B; Sun, 24 Mar 2019 14:31:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 xPWAzbe85ZKh; Sun, 24 Mar 2019 14:31:55 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5148112012F; Sun, 24 Mar 2019 14:31:55 -0700 (PDT)
Received: by with SMTP id w10so7917107wrm.4; Sun, 24 Mar 2019 14:31:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PW4TwbPSuqXeHJxCfOIizjbYCIfGUJ66gDdsbv7wr1M=; b=VhFpud1YbwhMCK8BiH6sr7zp4l3MO0qLzqVk4TU2YQdr9G684t5J32NPS4PnYAOwOt TSh4K0/R4BFFXPLgE8/TH8JUjFCBny6J1l90clvJlPG8oGHOdOU3BARRhiS4bgH8Y1vX +n7lhEzReBgoH7nN0i4KB1fPqdSVjtOy3jqJR4QguzjG81NRIlTrCpqRCHjN3witTux3 yWXqcRyZrg6tdOPh66jGB/77fv1yfC3KHexNZuAoRqwWimr0W6NqnFkiLiDmGYHQFIPN D9Yc7sXJKZ8ib1KSb6FkpI70rN1qilEaEJdjCgXb7sGDjHA/o4amxFjjBfmXPFf+P7U5 W4WA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PW4TwbPSuqXeHJxCfOIizjbYCIfGUJ66gDdsbv7wr1M=; b=cA6ybR7CFnJNp8fzQ4jtXsVS8zejUsdYmj6EbJakYsSwvyEqSjaIyqwlAmpi/BOMJP XCVg8T6IMDZ74g/YjVPtUTEXLMFxsrH+nb1NtpVYsT44ltpCKnTWQjcvAhmW0KyX6y4/ c60rkg5m2A2tRIaLc0Afq695nJMrnOJ3W7uGXOOGMPXUax3l5M9XNyDekAvnCvqLR7b3 kQxR2XAKOi4iNrfqDyR+qXjEgyP9ybBBpV9+xzaQ8gDCM8eNJTrrurnsL1d3qiYXe0tL EgJt/HS7psLYOz2zYP0aw1eaFIhyZwSxA6pHEHQu/WWCAdTlURR9IXA9jT9eyf4+jxNq UJlA==
X-Gm-Message-State: APjAAAVDhYyYVHu44b9KrXveu6qPsNsV40DjAXZqjb6JwfvEOQwS5oCv XNUUGWkLQ1BMZo2MOxPak0RX074wFoWiTw==
X-Google-Smtp-Source: APXvYqyj4PvfbObqzPiCoZRq6DW/+foZnTSoWNyCDsAFbYkj9+AhRNJ/JKJyYcaDumm9Han8VibcZg==
X-Received: by 2002:a5d:698b:: with SMTP id g11mr10605651wru.65.1553463113556; Sun, 24 Mar 2019 14:31:53 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:edb7:d3e6:fffe:6c7a? ([2001:67c:1232:144:edb7:d3e6:fffe:6c7a]) by with ESMTPSA id k4sm5181799wro.33.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Mar 2019 14:31:52 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-4CFAF010-C3B3-437D-840A-8C7902E8D592"
Mime-Version: 1.0 (1.0)
From: Brian Dickson <>
X-Mailer: iPhone Mail (16D57)
In-Reply-To: <>
Date: Sun, 24 Mar 2019 22:31:52 +0100
Cc: "Winfield, Alister" <>, Eric Rescorla <>, "" <>, "" <>, "" <>, "" <>, "" <>
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <> <> <> <> <> <>
To: Patrick McManus <>
Archived-At: <>
Subject: Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 24 Mar 2019 21:31:58 -0000

Sent from my iPhone

>> On Mar 24, 2019, at 9:43 PM, Patrick McManus <> wrote:
>> On Fri, Mar 22, 2019 at 11:15 AM Winfield, Alister <> wrote:
>> Don't overplay the privacy provided by DoH it has no effect on the DNS provider
> The major effect of the transport security on the privacy practices of the provider is that it allows the client to authenticate the provider. Trust in their privacy practices needs to be establish some other way (and the best way we have right now is 'out of band' - hopefully that gets better) - but with DoH

Minor correction: with DoH or DoT ...

> you can be confident that you're having a private conversation with the entity you've decided to trust. That's a pretty big distinction from port 53. Without that assurance its reasonable to be concerned about what names you lookup.
> This of course applies to local and enterprise configs as well as the cloud configs contemplated by most of this thread. An enterprise DoH server

Minor correction: An enterprise DoH and/or DoT server...

> expresses and enforces a policy - if an application needs to use that policy it should be comforted in transport security providing confirmation that it is doing so rather than reading in whatever might be showing up on port 53.

The only point I’m making in the above is there is no meaningful distinction in the privacy, security, or server validation between DoH vs DoT.

There is one important difference, which is that DoT uses a unique port number. This is important for network operators in identifying encrypted DNS traffic, in order to ensure that implementation of security policies for DNS don’t conflict with any other network policies (regardless of what those policies are.)

IMNSHO, if both ports are reachable for a given provider of Do*, the DoT port MUST be used. DoH should only be used with explicit informed user consent, and only when DoT is unavailable. This supports the “dissident” use case, without impacting any other aspects of privacy provided by DoT.

The blocking of DoT to a given provider should be interpreted as an explicit policy. Users should be informed that they may, and very likely will, be violating someone’s policy, if they choose to use DoH in that circumstance, and that they may be violating laws by doing so, and should only do so if they are willing to accept that risk.

There is no reason DoH should be used if DoT works (towards the same DNS provider).