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 On 09/03/2016 08:06, Wessels, Duane wrote: > Hi Brian, > > >> On Mar 7, 2016, at 5:48 PM, Brian E Carpenter <[email protected]> >> wrote: >> >> 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. > > "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 > > > >> "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)? > > Such DHCP features would need to be defined. > > >> I would have thought that the natural thing would have been to >> 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. > > >> >> "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. > > 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 > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
