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

[Tommy Jensen <[e-mail]>]

> Instead of asking "does this enable an attack", we have to ask "does this make the attacks worse in some scenario"?

Agreed. I still argue that the ability to poison an arbitrary record is not as bad as the ability to lie about the current resolver’s properties, which include an arbitrary URL, especially knowing that a DNSSEC-validating client can raise trust in the answer in the non-DDR case versus in the DDR case.

> In general, RESINFO claims are not verifiable by the client.

True, the claims themselves are not verifiable, as in the client cannot verify the resolver is in fact using QNAME minimalization, without some kind of ridiculously expensive, out of band, TEE powered relationship, but…

> The client simply has to trust that the server is telling the truth, which means it needs a particular kind of pre-existing trust relationship with that server operator

In the non-DDR case, the record will be for a name the client used to connect to the resolver over encrypted DNS. In this case, the record’s authenticity can be confirmed using DNSSEC to be as trustworthy as the original resolver choice configuration (detect upstream forgery). The same cannot be said of the DDR case, since resolver.arpa cannot be validly signed (no detection of forgery).

> I think the simplest solution is to note in the draft that clients MUST NOT rely on RESINFO unless they have an out-of-band agreement with the server operator to abide by its published RESINFO policy

No argument that this is the simplest solution. However, I believe the authors and those interested in adopting the draft may take issue with that, as it will reduce its useful deployment scale, but there’s no doubt it would address this concern. I would be interested to hear from other interested adopters to see what their target scenario is and if this is problematic. For the record, my first suggestion during shepherd review was to declare that clients MUST NOT rely on RESINFO when the resolver was discovered using DDR, and the sig solution was proposed because excluding DDR discovered resolvers was undesirable.

Who else is actively planning to implement RESINFO? Please weigh in.

Thanks,
Tommy

From: Add <[e-mail]> On Behalf Of Ben Schwartz
Sent: Friday, October 13, 2023 8:59 AM
To: tirumal reddy <[e-mail]>
Cc: [e-mail]
Subject: [EXTERNAL] Re: [Add] I-D Action: draft-ietf-add-resolver-info-06.txt

Reasoning about the security properties of insecure systems is tricky.  Instead of asking "does this enable an attack", we have to ask "does this make the attacks worse in some scenario"?

In this thread, we are discussing attackers who are falsifying RESINFO records.  This is only possible if (1) the attacker is upstream of the server* (which could be a resolver or forwarder) AND (2) that server is not DNSSEC-validating AND (3) that server is not using authenticated encryption on this connection AND (4) that server is not RESINFO-aware.

Given these preconditions, we can then ask: does accepting RESINFO make anything worse for the client?  Under these conditions, the attacker can already observe all upstream queries and generate arbitrary responses.  They essentially have taken over the resolver.  For example, the attacker controls the effective QNAME minimization policy: the attacker could capture all queries until the full QNAME is revealed, then pass that name un-minimized to the root servers and other parent zones.

The same logic applies to Kaminsky attacks and off-path cache poisoning: this attacker could point the IP addresses of popular TLD nameservers (or maybe even the root) back to themselves, allowing them to capture virtually all queries and control the responses.

Adding special cryptographic protections to RESINFO is not helpful when the actual functions of the resolver remain unprotected.

In general, RESINFO claims are not verifiable by the client.  The client simply has to trust that the server is telling the truth, which means it needs a particular kind of pre-existing trust relationship with that server operator.  I think the simplest solution is to note in the draft that clients MUST NOT rely on RESINFO unless they have an out-of-band agreement with the server operator to abide by its published RESINFO policy ... which implicitly prevents this attack (via point 4 above).

If we really feel the need to provide authenticated-but-still-untrusted RESINFO, we can move it to EDNS, which is not vulnerable except in pathologically insecure deployments.

--Ben

*Excluding off-path cache poisoning attacks for the moment.
________________________________
From: tirumal reddy <[e-mail]<mailto:[e-mail]>>
Sent: Friday, October 13, 2023 8:14 AM
To: Ben Schwartz <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: 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
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd
On Thu, 12 Oct 2023 at 04:03, Ben Schwartz <[e-mail]<mailto:[e-mail]>> 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 <[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