Draft: draft-ietf-doh-dns-over-https-latest

Commentary: This is similar to but , in my opinion , slightly different . The Introduction text says : I guess this implies integrity and confidentiality over the wire . For example DoH does n't guarantee confidentiality from the DoH server learning the content of the DNS query . Ok so it 's pretty clear that DoH focuses on the wire . Someone could argue it 's obvious but the document actually talks about it . Then in Selection of DNS API Server the text says : And because it 's a MUST , not trusting the server violates the DoH specification and hence its benefits ?  made the comment that trust is a client issue ( ) and I agree but there are different kinds of trust against different threats . I think we should tell clients what kind of trust they need to establish . Clients might trust the TLS connection to the server because , e.g. , it uses a strong CipherSuite and they can verify the server 's identity . At the same time clients might not trust the server to not profile them based on their queries and sell that information to advertisers . ( In this case clients might obscure their source IP address ) Clients might also not trust that the server is being diligent in checking the RRSIG records for every A record it gets from upstream servers . ( In this case clients will do the DNSSEC checks themselves ) In other words , clients may have a trusted connection to the server but at the same time might treat the server 's application logic as untrusted . What should the client do according to the  document ? I think the answer is they should use the server because DoH protects queries on the wire and from that aspect the server is trustworthy . But that 's not clear by the current language which seems to imply absolute trust for everything . I would propose that the text is updated to say : 
 I am uncomfortable with this language because it implies some things about how an HTTPS resource is fetched that are defined elsewhere . Heck , with a good cache there might not even be a connection . Let 's not go there . The existing text : " Before using a DNS API server for DNS resolution , the client MUST establish that the HTTP request URI is a trusted service for the DOH query , in other words , a DNS API client MUST only use a DNS API server that is configured as trustworthy . " It really tries to say the same thing twice ( " in other words " ) - which may cause confusion . They can be blended to be : " A DNS API client selects the URI , and by extension DNS API server , used for resolution via configuration . " This does remove an appropriate ( imo ) MUST , but the next sentence contains a MUST NOT that covers the important part .  ? 
 This text is much better - I support PR Only minor nit is that I might ask it says ' direct configuration ' to distinguish it from any type of dynamic configuration ?
Paragraph (version A):
Before using a DNS API server for DNS resolution, the client MUST
establish that the HTTP request URI is a trusted service for the DOH
query, in other words, a DNS API client MUST only use a DNS API
server that is configured as trustworthy.
Paragraph (version A):
A client MUST NOT use a DNS API server simply because it was
discovered, or because the client was told to use the DNS API server
by an untrusted party.
Paragraph (version B):
A DNS API client uses configuration to select the URI, and thus the
DNS API server, used for resolution.  A client MUST NOT use a DNS API
server simply because it was discovered, or because the client was
told to use the DNS API server by an untrusted party.