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

[Tommy Jensen <[e-mail]>]

Hey Ben,

>(If the resolver is DNSSEC-validating, injection on resolver.arpa is impossible.)

I fail to see how this closes the issue. This means the stub’s security is dependent on the recursive’s feature set and behavior (just because the recursive supports DNSSEC doesn’t mean it’s strongly enforcing it). I don’t think we should assume the recursive supports DNSSEC the same way we cannot assume they support both DDR and this draft. When they support only DDR, not this draft, and do not strongly enforce DNSSEC, an upstream attack can tell the client whatever it wants when resolver.arpa is used to identify the resolver by this draft without some kind of client-side validation.

Per DDR’s threat model, the name of the resolver cannot be used because it is prone to during-DDR attack (the only trusted identity for the resolver in this case is its IP address).

> I don't see a scope expansion attack here.

Depends on client policy. If the client refuses to use servers that do not support qnamemin, for example, the attacker could influence resolver selection by lying about the resolver’s feature set. Admittedly, this isn’t as scary as “directly sends client to a malicious endpoint” like potential EDSR and DDR attacks could in older text.

Full disclosure: I raised this concern during shepherd review. If the WG can gain consensus that Tommy made this up, let’s hear it. I’m just worried about the lack of discussion volume here.

Thanks,
Tommy

From: Add <[e-mail]> On Behalf Of Ben Schwartz
Sent: Wednesday, October 11, 2023 3:34 PM
To: tirumal reddy <[e-mail]>; [e-mail]
Subject: [EXTERNAL] Re: [Add] I-D Action: draft-ietf-add-resolver-info-06.txt

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.

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 <[e-mail]<mailto:[e-mail]>> on behalf of tirumal reddy <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, October 11, 2023 3:30 AM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
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, <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/add