Re: [Doh] [Ext] Request for the DOH WG to adopt draft-hoffman-resolver-associated-doh

"John Dickinson" <> Tue, 22 January 2019 17:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D8367130F3C for <>; Tue, 22 Jan 2019 09:09:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GBRR6vHpuQTN for <>; Tue, 22 Jan 2019 09:09:21 -0800 (PST)
Received: from ( [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 71F9D126CC7 for <>; Tue, 22 Jan 2019 09:09:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; ; s=haggis-2018; h=Date:Subject:To:From; bh=loyu2zpI1a1XKiPaXhZ8EbicToMLIwgqYMkuNEFD7pw=; b=MB0xLHeg1lwhY3MMpxATYlRBmP awFh/v2GDbnQX8rheROSNN7lTRWzxVhGJFm5iSP8/k7HQJ9W4d2wlYuXIQm2gijURjKNFmCK+AO5C ekOKbThhUohoMrvg86fFNDZualqEDYZRoMgbN/yHJJjs6r5LBYxtgwBtxYdoR0FyWPwgVGzRb0ptV 74DOf8aSugCZeSFHGPLyiGXb6t4RieWP+E8OS/dZxeQMB28m1kMKnrg7JEBwl4OO/nXFwVOyxL25z zCn6eewyjdS4+pxAm7hBU+xYiqe4q3gwPrrJGRGz6hFuhGL6kREwl2HWne1Ba8vr2DkPG3bIVeLEp s4FZgy7w==;
Received: from [2001:b98:204:102:fff1::f145] (port=63797 helo=[]) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <>) id 1glzY3-0005eo-Jf; Tue, 22 Jan 2019 17:09:19 +0000
From: "John Dickinson" <>
To: "Paul Hoffman" <>,
Date: Tue, 22 Jan 2019 17:08:32 +0000
X-Mailer: MailMate (1.12.3r5579)
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_509A3587-1239-4F30-91ED-EA40174CE92C_="; micalg=pgp-sha512; protocol="application/pgp-signature"
X-BlackCat-Spam-Score: -21
Archived-At: <>
Subject: Re: [Doh] [Ext] Request for the DOH WG to adopt draft-hoffman-resolver-associated-doh
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: Tue, 22 Jan 2019 17:09:24 -0000

On 22 Jan 2019, at 16:11, Paul Hoffman wrote:

> On Jan 22, 2019, at 3:58 AM, John Dickinson <> wrote:
>> On 16 Jan 2019, at 22:32, Paul Hoffman wrote:
>>> On Jan 16, 2019, at 1:29 PM, Martin Thomson <> wrote:
>>>> On Wed, Jan 16, 2019, at 11:25, Paul Hoffman wrote:
>>>>> People from a few browser vendors have expressed unofficial interest in
>>>>> implementing at least parts of it if it gets standardized, so it seems
>>>>> like a good idea to try to standardize it. There is still a reasonable
>>>>> amount of work to be done in the document itself, and it certainly needs
>>>>> input from both browser and DNS folks.
>>>> What happened to DRIU?  It seemed like there was an effort to work on the problem more generally.
>>> There was little interest in anything other than this part.
>>>> But I see the DoT comment down-thread and wonder whether this is the right place for doing this sort of work.
>>> DPRIVE is (sadly very slowly) working on draft-ietf-dprive-bcp-op, where DoT discovery would fit just fine.
>> I don’t think so. The BCP is Informational,
> As a process note, BCPs are standards, not Informational.

OK, my bad.

>> I see server discovery (requiring extensions to the protocol) as well out of scope for the BCP.
> For that, I agree. For DoT, "try it and see" works just fine.
>> As mentioned by Ben, for opportunistic DoT port 853 can be probed, but there is still no DNS or DHCP solution for Strict DoT (i.e. securely obtaining the authentication domain name).
> Agree. There has been little interest in this so far.
>> My understanding of this draft is that it provides only an ‘opportunistic’ discovery mechanism for DoH where the resulting URI template cannot be DNSSEC validated by the system resolver or the requesting application/browser. If that is the case the resulting HTTPS connection _could_ have been re-directed and so I think that should be spelt out more clearly.
> Good point, will do.
>> For example, I think that at least the title should be something more like ‘Associating a DoH Server with a Resolver for Opportunistic DoH’.
> I would push back on this change because "DoH Servers by TXT" is opportunistic while "DoH Servers by Addresses" is not.

As you mention in Section 8. This is only true if the application _knows_ how the OS resolver was configured or if the lookup of was DNSSEC validated and the application _knows_ it was DNSSEC validated.

>> Other comments:
>> I find this draft extremely difficult to read. For example, I am unable to easily parse Section 1, Para. 2, Sentence 1:
>>   “There is a use case for browsers and web applications to want the DNS
>>   recursive resolver(s) configured in the operating system to use DoH
>>   for DNS resolution instead of normal DNS, but to do so to at a DoH
>>   server specified by the configured resolver.”
>> I find the rest of the Introduction just as difficult to read.
>> Please add SUDN to the Terminology section and to the next DNS Terminology -bis draft.
>> Section 2.1
>>   “the zone is
>>   not actually delegated and never will be.”
>>   So it can never be DNSSEC signed unless you use a local trust anchor.
>> Section 2.2
>>   “To find the DoH servers associated with a resolver, the client sends
>>   a query to
>>   https://IPADDRESSGOESHERE/.well-known/doh-servers-associated/”
>>   Need to make it clear that this is a DoH query not a regular “http query”
>> Section 3 makes no mention of the fact that the OS stub resolver typically has more than 1 resolver configured.
>> Section 4
>>   “That wording might say
>>   something like "DoH server associated with my current resolver" (or
>>   "servidor DoH asociado con mi resolucion actual" or "serveur DoH
>>   associe a mon resolveur actuel”).”
>>   Is this intended to be read only configuration? It doesn’t sound like a configuration item for a User to edit.
> The purpose of having a WG review the draft is to make it easier to read. All the above seem like good changes.
>> I do not think this draft should be adopted until a separate use cases document is written (I am happy to help write it).
> We disagree here. In which WG has the separate use cases document being finished before the protocol started worked out well?

Well it would be good practice especially since we are trying to bring together DNS and HTTP folks. However, I take your point so I guess I would be happy if the use cases you are considering were very explicit and more clearly described in this draft.


> --Paul Hoffman
> _______________________________________________
> Doh mailing list

John Dickinson

Sinodun Internet Technologies Ltd.
Magdalen Centre
Oxford Science Park
Robert Robinson Avenue
Oxford OX4 4GA