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

["John Dickinson" <[e-mail]>]

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

> On Jan 16, 2019, at 1:29 PM, Martin Thomson <[e-mail]> 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, I see server discovery (requiring extensions to the protocol) as well out of scope for the BCP.

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).

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. For example, I think that at least the title should be something more like ‘Associating a DoH Server with a Resolver for Opportunistic DoH’.

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 resolver-associated-doh.arpa 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.

I do not think this draft should be adopted until a separate use cases document is written (I am happy to help write it).

regards
John


John Dickinson

https://sinodun.com

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