Re: [Doh] WGLC #2

["Hewitt, Rory" <[e-mail]>]

> However _if_ section 4 is moved I think there should at least be a reference in section 6.3 to Section 9.

Oh, that sounds like an excellent idea to me - I'd just really prefer to have all the "security considerations" stuff be in one place (Section 9) and ideally non-normative. But there should certainly be references to that section in many other places in the document.

Thanks,

Rory

-----Original Message-----
From: Sara Dickinson [mailto:[e-mail]] 
Sent: Tuesday, May 22, 2018 8:37 AM
To: Hewitt, Rory <[e-mail]>
Cc: DoH WG <[e-mail]>
Subject: Re: [Doh] WGLC #2



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


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


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.

Sara.