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

On Thu, 12 Oct 2023 at 04:03, Ben Schwartz <bemasc@meta.com> wrote:

> I guess "sig" is based on a security concern I raised
> about draft-jt-add-dns-server-redirection?  In that draft, an upstream
> injection attacker could poison the resolver's own SVCB record, allowing
> the attacker to make the client bypass their chosen resolver entirely, and
> instead use the attacker's resolver ~forever.  This is a kind of "scope
> expansion": a transient, injection-only attacker on one path can upgrade
> themselves into a permanent, read-write attacker on all paths.
>
> RESINFO doesn't have this problem.  Yes, an upstream attacker could inject
> a RESINFO response, but only to the same extent that they could poison any
> other query in the cache.  (If the resolver is DNSSEC-validating, injection
> on resolver.arpa is impossible.)  I don't see a scope expansion attack here.
>

Yes, scope expansion attack is not possible but DNSSEC protection is not
possible with SUDN "resolver.arpa". In case of DDR, the client will not
know whether RESINFO RR is originating from the discovered encrypted
resolver or not.

-Tiru

>
> Operationally, "sig" seems distinctly inconvenient.  Any DNS server that
> sits behind a TLS terminator or CDN will have extreme difficulty
> implementing it.
>
> I recommend removing "sig".
>

> If upstream attackers are a concern, I would solve that by moving RESINFO
> into EDNS, which is not controlled by the authoritative server.  (EDNS
> could still be manipulated by an attacker between a forwarder and its
> upstream resolver ... but that attacker can already control the content of
> all responses, so they effectively *are* the resolver.  Also, if the
> resolver and forwarder are so tightly integrated that the resolver can sign
> RESINFO with the forwarder's TLS private key, why aren't they using a
> secure transport?)
>
> --Ben Schwartz
> ------------------------------
> *From:* Add <add-bounces@ietf.org> on behalf of tirumal reddy <
> kondtir@gmail.com>
> *Sent:* Wednesday, October 11, 2023 3:30 AM
> *To:* add@ietf.org <add@ietf.org>
> *Subject:* Re: [Add] I-D Action: draft-ietf-add-resolver-info-06.txt
>
> This revision, https: //www. ietf.
> org/archive/id/draft-ietf-add-resolver-info-06. html, addresses comments
> from Martin on the "sig" attribute use. The authors consider it ready to
> advance the draft to the next stage.   -Tiru On Wed, 4
> ZjQcmQRYFpfptBannerStart
> This Message Is From an External Sender
>
> ZjQcmQRYFpfptBannerEnd
> This revision,
> https://www.ietf.org/archive/id/draft-ietf-add-resolver-info-06.html, addresses
> comments from Martin on the "sig" attribute use. The authors consider it
> ready to advance the draft to the next stage.
>
> -Tiru
>
> On Wed, 4 Oct 2023 at 13:42, <internet-drafts@ietf.org> wrote:
>
> Internet-Draft draft-ietf-add-resolver-info-06.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-06.txt
>    Pages:   10
>    Dates:   2023-10-04
>
> 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-06.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-add-resolver-info-06
>
> 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
>
>