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

Hi Ben,

Please see inline

On Sat, 9 Dec 2023 at 03:22, Ben Schwartz <bemasc@meta.com> wrote:

> In my view, this revision continues to make incorrect security
> recommendations, resulting in unnecessary obstacles to deployment by
> servers and notable vulnerabilities for clients.  I also think it has some
> other issues of clarity and correctness.
>
> As I've noted previously, I think there are various straightforward
> solutions that would render the draft both simpler and more secure.
> Perhaps the simplest would be to move RESINFO to the name "resolver.arpa"
> and require it to be returned in the Authority section, reflecting the fact
> that it is a property of the resolver (not the resolver's name) and is not
> subject to recursive resolution.
>

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.

>
> 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".

> Regardless, this is contradictory to the previous paragraph, which says
> that the RESINFO QNAME is the ADN.
>

The preceding paragraph pertains to a scenario where the resolver is
identified by a name (e.g., DDR, IKEv2). We will update the draft to
improve clarity.

>
> "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. However, I am uncertain about how
RESINFO is incompatible with DANE. Could you please elaborate ?

>
> 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. When RESINFO is
provided by the trusted resolver, the client can process the attributes.

-Tiru

> ------------------------------
> *From:* Add <add-bounces@ietf.org> on behalf of tirumal reddy <
> kondtir@gmail.com>
> *Sent:* Friday, December 1, 2023 7:42 AM
> *To:* add@ietf.org <add@ietf.org>
> *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 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, <internet-drafts@ietf.org> 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/
>
> There is also an HTML version available at:
> 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
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> --
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add
>
>