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

[tirumal reddy <[e-mail]>]

Hi Ben,

Please see inline

On Thu, 14 Dec 2023 at 00:10, Ben Schwartz <[e-mail]> wrote:

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

Yes.


> If relevant information is sent by the authority in the Authority section,
> the resolver will move it to the Answer section.
>

Got it, if a client sees the RESINFO in the Answer section it would detect
that the response is not provided by the resolver and discards the
response. I like the proposed change.


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

Agreed and RESINFO can be retrieved once a secure connection is established
with the encrypted DNS server, preventing any modification by an on-path
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".
>
>
>
> 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).
>

I don't see different DoH paths discussed in
https://my.nextdns.io/b7d9e4/setup#setup-guide, please point me to the
relevant link. The client would learn the ADN of resolver "
b7d9e4.dns.nextdns.io" using DNR and send DNS requests to the resolver to
get a signed response for RESINFO. Please elaborate on the attack possible
in the above scenario.

Anyways, with the change you proposed, there is no need to rely on 'SVCB
TargetName' :)


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

I don't think DDR works with DANE for verified discovery (it requires the
server to use a PKIX certificate).

Cheers,
-Tiru


>
>
>
>
> 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]> on behalf of tirumal reddy <
> [e-mail]>
> *Sent:* Friday, December 1, 2023 7:42 AM
> *To:* [e-mail] <[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 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]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>
>