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 On 09/03/2016 10:50, Wessels, Duane wrote: > Brian, > > >>> >>> 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. > > 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 > > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
