All The Call for Adoption for draft-sah-resolver-information has ended, and there seems to be strong consensus. The consensus is "Let's adopt this document, but let's do more work on the details". The chairs here this quite strongly.
We'll adopt the document and if the working group should be able to work on addressing all issues. Thanks for the comments. Tim On Tue, Aug 6, 2019 at 4:05 AM tirumal reddy <kond...@gmail.com> wrote: > Hi Paul, > > Please see inline > > On Mon, 5 Aug 2019 at 19:56, Paul Hoffman <paul.hoff...@icann..org > <paul.hoff...@icann.org>> wrote: > >> Thank you for your detailed list >> >> On Aug 5, 2019, at 4:07 AM, tirumal reddy <kond...@gmail.com> wrote: >> > >> > I did not receive response to the attacks discussed in >> https://mailarchive.ietf.org/arch/msg/dnsop/4ubj2D4bzxS1VTsZKzcNqBcWgtM. >> > Listing the attacks and comments for further discussion: >> >> To be clear, most of what you have below are not "attacks" at all.. >> > > Please explain why you think these are not "attacks" at all ? > > >> >> > a) Attackers can also host DoH/DoT servers and claim they offer >> security and privacy policies. How will the stub resolver know the >> recursive server is not lying ? >> >> The same way it can "know" that a web site it is going to follows that >> site's claims of security and privacy policies. That is: it cannot without >> help from trusted third parties. A resolver's claims inherently can be no >> different. This can be clarified in the draft. >> > > An user visiting a web site is different from an endpoint discovering a > network provided DoH/DoT server. Both good and back actors can advertise > DoH/DoT servers with the same security and privacy policies.. The attacker > can also potentially block the discovery of good DoH/DoT server. > > The above attacks are different from an user visiting www.google.com and > the browser rejecting the spoofed certificate from an MiTM. > > How will the user/endpoint distinguish between advertised good and > malicious DoH/DoT servers ? > > >> >> > b) How will the client know the policy statement is issued by a >> resolver deployed by the network administrator or by an attacker ? >> >> See above. This is barely different than the web model, if at all. >> > > No, this is not the same as a web model. Attacker can host a malicious > domain, deploy DoH/DoT servers and get the server certificate signed by a > CA (it can be automated with ACME and is free of cost with letsencrypt). > > >> >> > c) I don't see any discussion in the draft explaining how the client >> determines the future DHCP configuration options are coming from a trusted >> > source. >> >> For the DNS method, it can use DNSSEC validation. For the HTTPS method, >> it can use normal TLS authentication. This can be clarified in the draft. >> > > No, my comment is how will the client determine the future DHCP > configuration options are coming from a trusted source.. TLS authentication > and DNSSEC validation will also work for malicious DoH/DoT servers. > > >> >> > If the source cannot be trusted, endpoint can be configured to use a >> malicious resolver server compromising the endpoint security and privacy, >> > and future DHCP configuration options will not be helpful (DHCP clients >> typically have no secure and trusted relationships to DHCP servers). >> >> Are you saying here that, because there is no typically-trusted way to >> get this information from DHCP, there should be no way to get it from the >> DNS either? If so, that seems like a harsh restriction. >> > > If DHCP response can be spoofed, the endpoint has no way to know the DNS > response is coming from a trusted source even with DNSSEC and TLS > validation. > > Consider the following scenario: > > The network to which the endpoint attached uses OpenDNS to block access to > malicious domains. The attacker spoofs the DHCP response to send > Google DoH/DOT server instead of OpenDNS.. Assuming Google does not block > access to malicious domains, the attack is successful. > Note that DNSSEC and TLS server certificate validations will not prevent > the attack. > > >> >> > d) What type of DNS information is self-published ? >> >> The draft clearly says that a resolver can self-publish any information >> it wants, so I don't understand the question. >> > > The question is what is the information and what is its use to the > endpoint. In other words, why should a stub resolver implement this > specification and what problems will it solve to the end user ? > > >> >> > e) What type of decisions will the stub resolver make based on the >> features advertised by the recursive resolver ? >> >> Whichever decision it wants. This is true for any protocol, yes? >> > > No, the decisions may have privacy and security implications. > > >> >> > f) What is the need for both new RRtype and new well-known URI ? >> >> As I said earlier in the thread, it is not a "need". >> >> Some clients who want the information will want to use HTTPS because >> that's what they already do (such as applications with DoH clients); there >> is no need to force them to also have DNS transport stacks just to get the >> information. >> >> Some clients who want the information will want to use DNS because that's >> what they already do (such as stub resolvers); there is no need to force >> them to also have HTTPS transport stacks just to get the information. >> > >> > g) Why isn't the information the resolver will publish discussed in >> this document itself ? >> >> This is the same as asking "why isn't every DHCP option defined in the >> main DHCP protocol specification". We cannot know all the kinds of >> information that a resolver will want to publish. Different resolver >> operators have told me that, if this is adopted, they will suggest types of >> information they want stubs to know about them. There is no reason to >> restrict them in that, I believe. >> > > DHCP discusses several options (see > https://tools.ietf.org/html/rfc3315#section-22) and discusses scope for > future options in separate documents. This draft does not even specify any > details on the information the resolver will publish. > > >> > h) An on-path attacker can modify the response to return NXDOMAIN >> response. How is this attack prevented ? >> > Looks like DNSSEC validating client is mandatory to detect fake >> NXDOMAIN response. >> >> Yes, exactly. If you have a better suggestion, that would be great. >> > > If DNSSEC is mandatory to implement by the endpoint, it should be > specified in the document. Please note neither > https://tools.ietf.org/html/rfc8310 nor > https://tools.ietf.org/html/rfc8484 mandate the use of DNSSEC. > > >> >> > i) If the server certificate cannot be validated, why will the client >> trust the resolver information provided by server whose identify cannot be >> validated ? >> >> That's up to a client's policy for the specific information they receive. >> Again, this is no different than DHCP. > > > I don't see any such client policy mentioned in > https://tools.ietf.org/html/rfc8484. Are you aware of any browsers that > ignore server certificate validation > and why would the browser ignore the results of server certificate > validation ? > > >> The fact that few DHCP clients actually use DHCP authentication hasn't >> stopped the world from using it widely. >> > > And the world is moving away from clear text HTTP to use HTTPS. Ignoring > the server certificate validation will compromise the endpoint security and > privacy, and needs strong justification. > > >> >> > The draft does not look ready for adoption. >> >> Given the above, and given that the WG would be able to change any part >> of the draft it wants, do you still feel that way? > > > Yes, the draft look premature for adoption. As you already know, the > outcome of this work will impact DPRIVE, DoH and the discussions in ADD > mailing list. You may want to inform them about this draft, and seek > feedback. > > >> Or do you feel that there is no need at all for a resolver to be able to >> announce its features? >> > > No. > > Cheers, > -Tiru > > >> >> --Paul Hoffman > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
