Last Call Review of draft-ietf-dprive-dns-over-tls-07

Request Review of draft-ietf-dprive-dns-over-tls
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2016-03-15
Requested 2016-03-01
Authors Zi Hu, Liang Zhu, John Heidemann, Allison Mankin, Duane Wessels, Paul Hoffman
Draft last updated 2016-03-08
Completed reviews Genart Last Call review of -07 by Brian Carpenter (diff)
Genart Last Call review of -08 by Brian Carpenter (diff)
Intdir Early review of -05 by Bob Halley (diff)
Intdir Early review of -05 by Bob Halley (diff)
Assignment Reviewer Brian Carpenter
State Completed
Review review-ietf-dprive-dns-over-tls-07-genart-lc-carpenter-2016-03-08
Reviewed rev. 07 (document currently at 09)
Review result Almost Ready
Review completed: 2016-03-08


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

Document: draft-ietf-dprive-dns-over-tls-07.txt
Reviewer: Brian Carpenter
Review Date: 2016-03-08
IETF LC End Date: 2016-03-15
IESG Telechat date: 2016-03-17

Summary: Almost ready

Minor Issues:

"3.1.  Session Initiation

   A DNS server that supports DNS-over-TLS MUST listen for and accept
   TCP connections on port 853.  By mutual agreement with its clients,
   the server MAY, instead, use a port other than 853 for DNS-over-TLS.

   DNS clients desiring privacy from DNS-over-TLS from a particular
   server MUST establish a TCP connection to port 853 on the server.  By
   mutual agreement with its server, the client MAY, instead, use a port
   other than port 853 for DNS-over-TLS."

Well, that makes my head hurt. I think the only way to relieve the pain
is if both of those MUSTs are replaced by "MUST by default". However,
that means that both clients and servers need a configuration option
to use a different port, and I think that needs to be stated too.

"4.1.  Opportunistic Privacy Profile
   With opportunistic privacy, a client might learn of a TLS-enabled
   recursive DNS resolver from an untrusted source (such as DHCP while
   roaming), it might or might not validate the resolver."

This seems rather underspecified to me. How would a TLS-enabled
resolver be identified in DHCP? How would it be described in
an IPv6 RA (RFC6106)?

I would have thought that the natural thing would have been to
simply try TLS on port 853, and be happy if it worked.

"9.  Security Considerations"

I hoped to find a comment on interaction between DNS/TLS and DNSSEC,
even if the comment is only that there is no issue.