Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-dprive-dns-over-tls-07

From: Brian E Carpenter <[email-masked]>
Date: Tue, 8 Mar 2016 14:48:19 +1300

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
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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.

---

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 8 Mar 2016 19:06:08 +0000

Hi Brian,

> On Mar 7, 2016, at 5:48 PM, Brian E Carpenter <[email-masked]> wrote:
> 

"Must by default" sounds fine with me.  I've made that change and added a
sentence about configuration options.  New text:

   A DNS server that supports DNS-over-TLS MUST by default 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.  In order to use a port other than 853, both clients and
   servers would need a configuration option in their software.

   DNS clients desiring privacy from DNS-over-TLS from a particular
   server MUST by default establish a TCP connection to port 853 on the

> resolver be identified in DHCP? How would it be described in

Such DHCP features would need to be defined.  

> simply try TLS on port 853, and be happy if it worked.

How does this strike you then?

   With opportunistic privacy, a client might simply try port 853 on a
   normally configured recursive DNS resolver, or it might learn of a
   TLS-enabled recursive DNS resolver from an untrusted source (such as
   with a yet-to-be-defined DHCP extension or ICMPv6 type).  The client
   might or might not validate the resolver.  These choices maximize
   availability and performance, but they leave the client vulnerable to
   on-path attacks that remove privacy.

> even if the comment is only that there is no issue.

We mention this in the introduction, but I think its fine to repeat
it in Security Considerations:

   Note, DNS Security Extensions (DNSSEC) [RFC4033] provide _response
   integrity_ by defining mechanisms to cryptographically sign zones,
   allowing end-users (or their first-hop resolver) to verify replies
   are correct.  By intention, DNSSEC does not protect request and
   response privacy.

DW

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 9 Mar 2016 08:31:20 +1300

Hi Duane,

OK on the first two points, thanks. On the Security Considerations,
I was a bit unclear: I was looking for a statement that running DNSSEC
through a TLS connection will work OK, and that using DNS/TLS does not
remove the need for DNSSEC validation.

Thanks
   Brian

---

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 8 Mar 2016 21:01:34 +0000

> On Mar 8, 2016, at 11:31 AM, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi Duane,
> 

How about this then?

   As noted earlier, DNSSEC and DNS-over-TLS are independent and fully
   compatible protocols, each solving different problems.  The use of
   one does not diminish the need nor the usefulness of the other.

DW

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 9 Mar 2016 10:16:04 +1300

Perfect, thanks!

Regards
   Brian

---

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 8 Mar 2016 21:50:57 +0000

Brian,

>   on-path attacks that remove privacy.

One of the authors has suggested the following rewrite of what I proposed
earlier:

   With opportunistic privacy, a client might learn of a TLS-enabled
   recursive DNS resolver from an untrusted source (such as DHCP's DNS
   server option [RFC3646] to discover the IP address followed by
   attemting the DNS-over-TLS on port 853, or with a future DHCP option
   that specifics DNS port).  With such an discovered DNS server, the
   client might or might not validate the resolver.  These choices
   maximize availability and performance, but they leave the client
   vulnerable to on-path attacks that remove privacy.

Does that still address your concern?

DW

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 9 Mar 2016 11:12:52 +1300

No objection. A complete approach would also need an extension
to the IPv6 Router Advertisement DNS option (RFC6106) as
well as DHCPv6, but that's a detail. (DHCPv6 runs over ICMPv6,
so I would suggest s/ICMPv6/DHCPv6/, but again it's a detail.)

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Mar 2016 08:33:34 +1300

> (DHCPv6 runs over ICMPv6,

Wrong. It's IPv6 neighbor discovery messages that run over ICMPv6, sorry.
So again - the logical alternative to a DHCPv6 option would be a variant
of the RFC6106 option.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Mar 2016 17:22:53 +1300

I am on travel and have not yet seen a -08 version appear, but it's
getting quite close to the IESG telechat.

Formally my review is still "Almost ready". However, if the changes
suggested by the authors are in the -08 version, that will become "Ready."

Regards
   Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Mar 2016 17:44:38 +1300

And of course that crossed in the mail with the new draft ;-)

So now my review is "Ready", thanks. I am short of time so
I will omit the Gen-ART boilerplate.

Regards
   Brian

---

From: Allison Mankin <[email-masked]>
Date: Wed, 16 Mar 2016 00:49:06 -0400

Excellent, thanks, Brian.
On Mar 16, 2016 00:44, "Brian E Carpenter" <[email-masked]>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Mar 2016 08:16:16 +0000

Thanks, all! This is an important spec.

Jari

On 16 Mar 2016, at 04:49, Allison Mankin <[email-masked]> wrote:

> On Mar 16, 2016 00:44, "Brian E Carpenter" <[email-masked]> wrote:
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art