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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 21 Apr 2015 07:51:15 +0000

This document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. Comments and suggestions are welcome.

-Tiru

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, April 21, 2015 1:13 PM
To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Tirumaleswar Reddy (tireddy); Dan Wing (dwing); Dan Wing (dwing); Prashanth Patil (praspati)
Subject: New Version Notification for draft-wing-dprive-dnsodtls-00.txt

A new version of I-D, draft-wing-dprive-dnsodtls-00.txt has been successfully submitted by Tirumaleswar Reddy and posted to the IETF repository.

Name:		draft-wing-dprive-dnsodtls
Revision:	00
Title:		DNS over DTLS (DNSoD)
Document date:	2015-04-21
Group:		Individual Submission
Pages:		11
URL:            http://www.ietf.org/internet-drafts/draft-wing-dprive-dnsodtls-00.txt
Status:         https://datatracker.ietf.org/doc/draft-wing-dprive-dnsodtls/
Htmlized:       http://tools.ietf.org/html/draft-wing-dprive-dnsodtls-00

Abstract:
   DNS queries and responses are visible to network elements on the path
   between the DNS client and its server.  These queries and responses
   can contain privacy-sensitive information which is valuable to
   protect.  An active attacker can send bogus responses causing
   misdirection of the subsequent connection.

   To counter passive listening and active attacks, this document
   proposes the use of Datagram Transport Layer Security (DTLS) for DNS,
   to protect against passive listeners and certain active attacks.  As
   DNS needs to remain fast, this proposal also discusses mechanisms to
   reduce DTLS round trips and reduce DTLS handshake size.  The proposed
   mechanism runs over the default DNS port and can also run over an
   alternate port.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 21 Apr 2015 13:34:09 +0200

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

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.

Generally, I believe you want to reference RFC 6125 and speak in the
terminology of that document for better clarity on TLS certificate
validation.

/Simon

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Wed, 22 Apr 2015 19:06:13 +0000

Hi Simon,
Appreciate the review.

On 4/21/15, 4:34 AM, "Simon Josefsson" <[email-masked]> wrote:

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

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.

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

>terminology of that document for better clarity on TLS certificate

Thanks.

-Prashanth