Subject: [dns-privacy] I-D Action: draft-ietf-dprive-dns-over-tls-00.txt

From: [email-masked]
Date: Fri, 18 Sep 2015 13:21:50 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the DNS PRIVate Exchange Working Group of the IETF.

        Title           : DNS over TLS: Initiation and Performance Considerations
        Authors         : Zi Hu
                          Liang Zhu
                          John Heidemann
                          Allison Mankin
                          Duane Wessels
                          Paul Hoffman
	Filename        : draft-ietf-dprive-dns-over-tls-00.txt
	Pages           : 17
	Date            : 2015-09-18

Abstract:
   This document describes the use of TLS to provide privacy for DNS.
   Encryption provided by TLS eliminates opportunities for eavesdropping
   on DNS queries in the network, such as discussed in RFC 7258.  In
   addition, this document specifies two usage profiles for DNS-over-TLS
   and provides advice on performance considerations to minimize
   overhead from using TCP and TLS with DNS.

   Note: this document was formerly named
   draft-ietf-dprive-start-tls-for-dns.  Its name has been changed to
   better describe the mechanism now used.  Please refer to working
   group archives under the former name for history and previous
   discussion.  [RFC Editor: please remove this paragraph prior to
   publication]

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dprive-dns-over-tls/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dprive-dns-over-tls-00

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 18 Sep 2015 20:34:02 +0000

This is an update to the draft formerly named draft-ietf-dprive-start-tls-for-dns-01.  If searching mail archives for previous discussion of this draft you may need to use the former name.

The former draft described two approaches to establishing a DNS-over-TLS session: upgrade-based (aka STARTTLS for DNS) and port-based.  In this new version we have removed the upgrade-based approach and describe only the use of a well-known port.

The URL below will show the differences between this and the previous document.

http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-dprive-start-tls-for-dns-01.txt&url2=https://tools.ietf.org/id/draft-ietf-dprive-dns-over-tls-00.txt

DW

> On Sep 18, 2015, at 1:21 PM, [email-masked] wrote:
> 
> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Warren Kumari <[email-masked]>
Date: Fri, 18 Sep 2015 17:03:58 -0400

> This is an update to the draft formerly named draft-ietf-dprive-start-tls-for-dns-01.  If searching mail archives for previous discussion of this draft you may need to use the former name.

Thank you authors.

We would appreciate it if the WG could do a careful review of this
document and point out the issues, inconsistencies, errors and
omissions. We'd like to get things rolling along somewhat faster than
we have been...

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 21 Sep 2015 11:58:41 +0200

"Wessels, Duane" <[email-masked]> writes:

> The former draft described two approaches to establishing a
> DNS-over-TLS session: upgrade-based (aka STARTTLS for DNS) and
> port-based.  In this new version we have removed the upgrade-based
> approach and describe only the use of a well-known port.

Yay, thank you!

I believe the abstract or introduction section should mention that TLS
gives you data integrity services, which protects against on-path
tampering.  Right now the document talks about encryption to protect
against eavesdropping.  However, the RFC 7258 pervasive monitoring
attack includes active attacks and thus I believe talking about
integrity is useful to set the context right.

One comment/thought around the /etc/service name 'domain-s'.  I find it
undescriptive and difficult to type.  How about 'dnsovertls' or
something more descriptive?

/Simon

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 21 Sep 2015 16:48:12 +0200

On Fri, Sep 18, 2015 at 05:03:58PM -0400,
 Warren Kumari <[email-masked]> wrote 
 a message of 97 lines which said:

> omissions.

I did not find a serious problem. I have one question and one
criticism.

> Since pipelined responses can arrive out-of-order, clients MUST
> match responses to outstanding queries using the ID field and port
> number.

I do not understand how this works. All replies on a given TCP
connection will have the same source port (the new well-known port)
and the same destination port (the one used to open the TCP
connection). So, how do you use the port number for demultiplexing?
Why not using the QNAME instead? (The query ID may be unsufficient if
there are a lot of outstanding queries + the birthday paradox.)

> For DNS clients that use library functions such as
> "gethostbyname()",

This was replaced by a better function in RFC 2133, in 1997...

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 30 Sep 2015 22:36:14 +0000

Hi Stephane,

Does this change address your concerns?

diff --git a/draft-ietf-dprive-dns-over-tls.xml b/draft-ietf-dprive-dns-over-tls.xml
index a0ae144..a40cec8 100644
--- a/draft-ietf-dprive-dns-over-tls.xml
+++ b/draft-ietf-dprive-dns-over-tls.xml
@@ -394,7 +394,7 @@
          <!-- cut-n-paste from rfc5966-bis sec 7 -->
          Since pipelined responses can arrive out-of-order, clients
          MUST match responses to outstanding queries using the ID
-         field and port number.  Failure by clients to properly
+         field, query name, type, and class.  Failure by clients to properly
          match responses to outstanding queries can have serious
          consequences for interoperability (<xref
          target="I-D.ietf-dnsop-5966bis"/>, Section 7).
@@ -403,7 +403,7 @@
 
       <section anchor="Connection" title="Connection Reuse, Close and Reestablishment">
         <t>
-          For DNS clients that use library functions such as "gethostbyname()",
+          For DNS clients that use library functions such as "getaddrinfo()" and "gethostbyname()",
           current implementations are known to open and close TCP connections each DNS
           call.  To avoid excess TCP connections, each with a single query,
           clients SHOULD reuse a single TCP connection to the

> On Sep 21, 2015, at 7:48 AM, Stephane Bortzmeyer <[email-masked]> wrote:
>