> (DHCPv6 runs over ICMPv6, > so I would suggest s/ICMPv6/DHCPv6/, but again it's a detail.)
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 On 09/03/2016 11:12, Brian E Carpenter wrote: > 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
