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

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

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

> On Jan 22, 2019, at 3:58 AM, John Dickinson <[e-mail]> wrote:
>>
>> 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,
>
> 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 resolver-addresses.arpa 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 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.
>>
>
> 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.

regards
John

>
> --Paul Hoffman
> _______________________________________________
> Doh mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/doh


John Dickinson

https://sinodun.com

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