Re: [Doh] WGLC #2

[Mateusz Jończyk <[e-mail]>]

W dniu 22.05.2018 o 17:37, Sara Dickinson pisze:
> 
> 
>> On 21 May 2018, at 21:41, Hewitt, Rory <rhewitt=[e-mail]> wrote:
>>
>> I know I brought this up in
>> https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/174 and agreed to
>> leave it, but I see that Mateusz subsequently brought it up in
>> https://www.ietf.org/mail-archive/web/doh/current/msg00557.html...
>>
>> I would really like to see Section 4 (Selection of DNS API Server) moved to be
>> within Section 9 (Security Considerations), perhaps as a subsection (9.1:
>> Selection of DNS API Server)
> 
> The reason I think it is useful to have Section 4 is that Section 6.3 (Server Push) discusses which URI’s pushes should be accepted from and so is implicitly talking about which servers to use. However _if_ section 4 is moved I think there should at least be a reference in section 6.3 to Section 9.

I would argue that section 6.3 "Server Push" is poorly written and needs to be
clarified. I have asked several questions about it in the past:
	https://www.ietf.org/mail-archive/web/doh/current/msg00558.html
in order to better understand it. (I would like to thank Patrick McManus and Ben
Schwartz for explanations I received.)

I propose that it should be rewritten simply to:

	A DNS API client MUST ignore pushed DNS API requests (see {{RFC7540}}
	Section 8.2) whose pushed request URI does not match the configured DNS
	API server.

> 
> 
> 2 other comments:
> 
> 1) I previously asked if this spec required that a DNS API Sever should only be used if authentication of the TLS connection was successful. I got conflicting answers from Paul and Martin (‘No we can’t say that’ vs ‘authentication is critical and implicit’) and don’t see anything in this version that resolves this. I know there is other work attempting to address this issue (and more) but the lack of clarity in this document on the topic is still an issue for me. I’d still like to see a single sentence that either
> - makes clear the requirement (preferable) or
> - states that this is out of scope

It may happen that the DNS API server is running on a local home router and uses
a self-signed certificate. (I have talked about running a local DNS API server
on a home router before.)
I suppose that in this case the certificate could be supplied as part of a
configuration.

> 
> 
> 2) “If a client of this protocol encounters an HTTP
>    error after sending a DNS query, and then falls back to a different
>    DNS retrieval mechanism, doing so can weaken the privacy and
>    authenticity expected by the user of the client.”
> 
> What does authenticity mean here - data integrity or DNSSEC authentication? If it is the latter I would argue to remove it because DNSSEC and transport choice are orthogonal.

I suppose that it means here data integrity: the server can provide bogus
responses to DNS requests and strip DNSSEC information.

> 
> Sara.

Greetings,
Mateusz