> 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
