Re: [Doh] A question of trust (was Re: Draft -09 and WGLC #2)

Mateusz Jończyk <> Tue, 29 May 2018 18:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2835E12E03D for <>; Tue, 29 May 2018 11:28:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hZHPvmR5vNQc for <>; Tue, 29 May 2018 11:28:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 749C312EB5A for <>; Tue, 29 May 2018 11:28:42 -0700 (PDT)
Received: (wp-smtpd 29100 invoked from network); 29 May 2018 20:28:38 +0200
Received: from (HELO []) ([]) (envelope-sender <>) by (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for <>; 29 May 2018 20:28:38 +0200
To: Sara Dickinson <>, DoH WG <>, Martin Thomson <>, Patrick McManus <>
References: <> <> <> <> <> <> <> <> <> <>
From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= <>
Openpgp: preference=signencrypt
Message-ID: <>
Date: Tue, 29 May 2018 20:28:14 +0200
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82kpRHMDgtpr0ysAVxwRBduC4tN7WHI7A"
X-WP-MailID: 2b7a16f7591dca9445a4bd9e6b10cc32
X-WP-AV: skaner antywirusowy Poczty o2
X-WP-SPAM: NO 0000000 [QYO0]
Archived-At: <>
Subject: Re: [Doh] A question of trust (was Re: Draft -09 and WGLC #2)
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: Tue, 29 May 2018 18:28:56 -0000


W dniu 29.05.2018 o 03:30, Patrick McManus pisze:
> "A DNS API client uses configuration to select the URI, and thus the DNS API
> server, used for resolution. [RFC2818] defines how HTTPS verifies the server's
> identity.
> A client MUST NOT use a different URI simply because it was discovered outside
> of configuration. Specifically, this specification does not extend DNS
> resolution privileges to URIs that are not recognized by the DNS API client as
> configured URIs. A future specification may support this case."

This does not differ much from the following text:

"A client MUST NOT use arbitrary DNS API servers. Instead, a client MUST only
use DNS API servers specified using mechanisms such as explicit configuration."

which happens to be what is specified by the current draft.

I think that the misunderstanding here stems from the fact that server trust is
specified in two distinct places in the document ("Security Considerations" and
"Selection of DNS API Server") and in each place differently.

I've been proposing over and over to unify both specifications. It is OK if Paul
(if I remember correctly) wants to have server trust defined in a separate
section outside "Security Considerations", but we should make both
specifications similar and make one of them refer to the other.


I have also been thinking about the following mechanism:

A DNS API client would have a list of "trustworthy" DNS API servers, but which
DNS API server from that list is used could be selected using DHCP.

I sent this to the DRIU list [1], as I supposed it is more appropriate there.
But now such topics are being discussed on the DOH mailing list and so I am
posting it here.

It would have the following benefits:

1. Using one's own ISP's DNS server would allow DNS64.

2. It would give network administrators an easy way to choose a DNS provider
across a whole network (using DHCP) and configure it in one place instead of on
multiple machines.

3. It would also enable use of ISP's DNS API server (as a main server or as a
fallback), which would make it possible to share global DNS load across many
ISP's DNS servers. For details, see the quoted mail.

At the same time, it would provide protection against phishing and rogue actors.