> On 6 Jun 2017, at 19:55, Suresh Krishnan <[email protected]> wrote: > > Hi Stephane, >> >> It seems there was no reply to this DISCUSS? > > Yes. There was no response to this DISCUSS.
Apologies, I indirectly responded to a similar comment another review (in that we would need to update the text given that there were several comments on it) but hadn’t proposed any new text. The revised I-D is still being worked on. > On 6 Jun 2017, at 20:21, Stephane Bortzmeyer <[email protected]> wrote: >> >> 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. Stephane was correct in that this section was not requesting or proposing anything specific with regard to DHCP, only outlining a potential future use case. I have proposed some minor modifications to Stephane’s text below which could make this even clearer, however if this isn’t sufficient then I think moving this to an appendix would be the best option. Sara. > Proposal for a new 7.3: 7.3 No configuration - dynamic discovery of ADN This section discusses the general case of a DNS client discovering both the authentication domain name and IP address dynamically. This is not possible at the time of writing by any standard means. However since, for example, a future DHCP extension could (in principle) provide this mechanism the required security properties of such mechanisms are outlined here. When using a Strict profile the dynamic discovery technique used as a source of authentication domain names MUST be considered secure and trustworthy. This requirement does not apply when using an Opportunistic profile given the security expectation of that profile. 7.3.1 DHCP In the typical case today, 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.) This document does not specify or request any DHCP extension to provide authentication domain names. However, if one is developed in future work the issues outlined in section 8 of [RFC7227] should be taken into account as should the Security Considerations in section 23 of [RFC3315]) . 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
