Hi Simon, Appreciate the review.
On 4/21/15, 4:34 AM, "Simon Josefsson" <[email protected]> wrote: >Hi. Quoting section 3.2: > > To authenticate the server providing DNS privacy, the DNS client > needs to be configured with the names of those DNS privacy servers. > When connecting a DNS privacy server, the server's IP address can be > converted to its hostname by doing a DNS PTR lookup, verifying that > the name matches the pre-configured list of DNS privacy servers, and > finally validating its certificate trust chain or a local list of > certificates. > >Your first sentence says that DNS client needs to be configured with the >names of those DNS privacy servers. The second sentence starts with >"When connecting...". Presumably, the DNS client needs an IP address to >connect. How does it get that? The idea was to have a configuration list that only has names of trusted servers. A client discovers an IP address to connect using any of the existing techniques that clients use today e.g. DHCP. > Would it be correct to change the first >sentence into: > > the DNS client needs to be configured with IP addresses and names of > those DNS privacy servers, so that each IP address is associated with > one name. Yes, I suppose we could also have the list include Name+IP address combinations. This would form a default list of servers that a client can connect with, if the client failed to learn a DNS server OR didn¹t want to use a DNS server learned via DHCP. > >Further, the second sentence suggest that the client do a PTR lookup. >This presumably needs to happen after the TLS handshake has finished, >which is where certificate validation usually happens. However, I don't >understand why this PTR dance is useful. Why can't the client just >compare the name it has configured for that IP address with the name >presented in the certificate from the server? It seems this PTR >approach would be a way to avoid the need foor clients to configure a >name, but you already said in the document that it has to know a name. The PTR approach was included to address the case when a client was only configured with trusted DNS names and not IPs associated with those names. > >Generally, I believe you want to reference RFC 6125 and speak in the >terminology of that document for better clarity on TLS certificate >validation. Thanks. -Prashanth > >/Simon _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
