On Wed, Jun 07, 2017 at 12:25:25AM +0530, Suresh Krishnan <[email protected]> wrote a message of 42 lines which said:
> > If so, let me give my opinion: I disagree with the DISCUSS. > > Not sure what you are disagreeing with. Are you saying this text is > clear about what is needed from the eventual DHCP option(s)? IMHO, yes. > The strict profile requires the DHCP server to be “secure and > trustworthy” but declines to define what it means by “secure and > trusted”. So I cannot tell if it requires anything from current DHCP > servers or not. Proposal for a new 7.3: In the typical case, a DHCP server [RFC2131] [RFC3315] provides a list of IP addresses for DNS resolvers (see section 3.8 of [RFC2132]), but does not provide a domain name for the DNS resolver, thus preventing the use of most of the authentication methods described here. (All those that are based on a mechanism with ADN in table 2.) In the future, a DHCP server might use a DHCP extension to provide a list of authentication domain names for the offered DNS servers, which correspond to IP addresses listed. People who wish to work on such a yet-to-come extension may be interested in section 8 of [RFC7227]. Even with this future extension, this leaves open the issue of the trust in the DHCP server. Of course, in a typical hotspot, the DHCP server is not to be trusted (see section 23 of [RFC3315]) for the Strict profile. When using an Opportunistic profile, it would be reasonable to use the ADN indicated by the DHCP server, given the security expectation of that profile. Some clients may have an established trust relationship with a known DHCP server for discovering their network configuration. When using a Strict profile the DHCP servers used as sources of authentication domain names is sensible only if the server is considered secure and trustworthy. This document does not attempt to describe secured and trusted relationships to DHCP servers, which is a purely DHCP issue. (Still open, at the time of writing.) Whilst some implementation work is in progress to secure IPv6 connections for DHCP, IPv4 connections have received little to no implementation attention in this area. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
