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
