Perfect, thanks! Regards Brian
On 09/03/2016 10:01, Wessels, Duane wrote: > >> On Mar 8, 2016, at 11:31 AM, Brian E Carpenter <[email protected]> >> wrote: >> >> 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. > > > 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 > > > >> 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
