Re: [DNSOP] [Ext] Call for Adoption: draft-sah-resolver-information

[tirumal reddy <[e-mail]>]

Hi Paul,

Please see inline

On Mon, 5 Aug 2019 at 19:56, Paul Hoffman <[e-mail]> wrote:

> Thank you for your detailed list
>
> On Aug 5, 2019, at 4:07 AM, tirumal reddy <[e-mail]> 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