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. > 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. > 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. > 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. > 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. > 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. > 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? > 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. > 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. > 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. The fact that few DHCP clients actually use DHCP authentication hasn't stopped the world from using it widely. > 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? Or do you feel that there is no need at all for a resolver to be able to announce its features? --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
