Re: [Add] I-D Action: draft-ietf-add-resolver-info-08.txt

[Ben Schwartz <[e-mail]>]

On 12/13/23, 4:12 AM, "tirumal reddy" <[e-mail]> wrote:

I am uncertain about how moving the RESINFO to the authority section addresses the issue of a resolver not supporting RESINFO. In such a case, the resolver will forward the query upstream, and the client could potentially receive a positive RESINFO response either from a legitimate upstream DNS resolver or an attacker.

I believe that resolvers never place received information in the Authority section.  If relevant information is sent by the authority in the Authority section, the resolver will move it to the Answer section.  Thus, requiring RESINFO records from a resolver to appear in the Authority section is sufficient to prove that those records were produced locally by the resolver, not forwarded (potentially insecurely) from an upstream authority.



Detailed notes:

Section 3:

"By using the DNS server's domain name from the DDR SVCB response to issue the RESINFO query, a client accepts the risk that a resolver supports DDR but does not support RESINFO."
-> The "server's domain name for the DDR SVCB response" is not a defined value.  Maybe you mean "The SVCB TargetName"?

Yes, we will update the draft to use "SVCB TargetName".

This is an abuse of the SVCB TargetName, which is explicitly not intended to serve as an identity anchor for the service.  It is also incompatible with services like NextDNS that host many DNS servers with distinct behaviors on a single hostname (at different DoH paths or DoT ports).


…


"clients wishing to retrieve resolver information from resolvers discovered when performing DDR discovery using resolver IP address (Section 4 of [RFC9462]) MUST ensure during the TLS handshake that the TLS certificate presented by the resolver contains in its SubjectAltName (SAN) the domain name in the TargetName of the DDR SVCB response"
-> This rules out the use of RESINFO in Opportunistic DDR scenarios, which seems like a serious loss for debugging small networks.  It also interferes with the usual interpretation of SVCB TargetName and renders RESINFO incompatible with DANE.  It also fails to accomplish the desired authentication: if the name is unsigned or the resolver is non-validating, an upstream attacker could still have injected an arbitrary RESINFO response despite this attempted protection.

In the case of debugging, the validation rule discussed in the draft can be disabled using a configuration knob.

This seems strange to me.  RESINFO can replace “bind.version”, but only if the user changes a configuration knob?

However, I am uncertain about how RESINFO is incompatible with DANE. Could you please elaborate ?

DANE does not require an X.509 certificate to exist at all: it can authorize bare keys.  If a certificate does exist, it is not always required to cover the name that would be expected without DANE.


Section 6:

"If the client cannot validate the attributes received from the resolver, which will be used for resolver selection or display to the end-user, the client should process those attributes only if the encrypted resolver has sufficient reputation according to local policy"
-> As above, this does not accomplish the desired authentication unless the reputation assessment specifically requires that the resolver is "RESINFO-aware" (which would be false of all resolvers today, regardless of reputation).

I don't see a problem. In cases where the trusted resolver does not support RESINFO, the client can identify a spoofed DNS response.

How?  A trusted resolver is still vulnerable to DNS cache poisoning on unsigned domains.

When RESINFO is provided by the trusted resolver, the client can process the attributes.

-Tiru


________________________________
From: Add <[e-mail]<mailto:[e-mail]>> on behalf of tirumal reddy <[e-mail]<mailto:[e-mail]>>
Sent: Friday, December 1, 2023 7:42 AM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Add] I-D Action: draft-ietf-add-resolver-info-08.txt

This revision of the draft https: //www. ietf. org/archive/id/draft-ietf-add-resolver-info-08. html has been updated based on discussions during the presentation at IETF-118. Special thanks to Tommy Jensen for contributing text to this revision. 
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd
This revision of the draft https://www.ietf.org/archive/id/draft-ietf-add-resolver-info-08.html<https://www.ietf.org/archive/id/draft-ietf-add-resolver-info-08.html> has been updated based on discussions during the presentation at IETF-118. Special thanks to Tommy Jensen for contributing text to this revision. The draft is now ready for progression to the next stage.

Cheers,
-Tiru

On Fri, 24 Nov 2023 at 13:47, <[e-mail]<mailto:[e-mail]>> wrote:
Internet-Draft draft-ietf-add-resolver-info-08.txt is now available. It is a
work item of the Adaptive DNS Discovery (ADD) WG of the IETF.

   Title:   DNS Resolver Information
   Authors: Tirumaleswar Reddy
            Mohamed Boucadair
   Name:    draft-ietf-add-resolver-info-08.txt
   Pages:   9
   Dates:   2023-11-24

Abstract:

   This document specifies a method for DNS resolvers to publish
   information about themselves.  DNS clients can use the resolver
   information to identify the capabilities of DNS resolvers.  How such
   an information is then used by DNS clients is out of the scope of the
   document.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-add-resolver-info/<https://datatracker.ietf.org/doc/draft-ietf-add-resolver-info/>

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-add-resolver-info-08.html<https://www.ietf.org/archive/id/draft-ietf-add-resolver-info-08.html>

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-add-resolver-info-08<https://author-tools.ietf.org/iddiff?url2=draft-ietf-add-resolver-info-08>

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


--
Add mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/add<https://www.ietf.org/mailman/listinfo/add>