Re: [dns-privacy] FW: New Version Notification for draft-wing-dprive-dnsodtls-00.txt

["Prashanth Patil (praspati)" <[e-mail]>]

Hi Simon,
Appreciate the review.


On 4/21/15, 4:34 AM, "Simon Josefsson" <[e-mail]> 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