Hi Stephane/Sara, I will be happy with either of your text proposals as they certainly clarify things for me.
Regards Suresh > On Jun 7, 2017, at 6:57 PM, Sara Dickinson <[email protected]> wrote: > > >> 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
