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

[Ben Schwartz <[e-mail]>]

The limiting factor with RESINFO and DDR/DNR is not technical compatibility, and cannot be solved by technical measures.  Proving that the RESINFO is bound to the TLS certificate (authenticity) does not provide any evidence that the resolver will act in accordance with its contents (trustworthiness).  Confirmation of trustworthiness, by nontechnical means, is sufficient to rule out any RESINFO implantation attack, and RESINFO is useless without such confirmation, so no technical defense is required.

If for some reason a technical authentication mechanism is desired, I don't think "sig=" is a good approach.  As I mentioned earlier, it is difficult to implement in architectures that separate TLS termination from DNS logic.  A simpler and cleaner solution would be to move the metadata into EDNS, where it cannot be influenced by external servers.  The record could also be defined in a different CLASS (perhaps CH, for tradition's sake), if we are confident that this will not result in recursive resolution by existing servers.

--Ben
________________________________
From: tirumal reddy <[e-mail]>
Sent: Saturday, October 14, 2023 2:11 AM
To: Tommy Jensen <[e-mail]>
Cc: Ben Schwartz <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [Add] I-D Action: draft-ietf-add-resolver-info-06.txt

On Fri, 13 Oct 2023 at 22: 23, Tommy Jensen <Jensen. Thomas@ microsoft. com> wrote: > Instead of asking "does this enable an attack", we have to ask "does this make the attacks worse in some scenario"? Agreed. I still
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd
On Fri, 13 Oct 2023 at 22:23, Tommy Jensen <[e-mail]<mailto:[e-mail]>> wrote:

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

The proposed mechanism will help identify the attack and warn the client that an upstream attacker is spoofing the DNS response.




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

Agreed. In the DNR case, if the client does not perform DNSSEC validation, it can initiate a RESINFO query after the DNS server is authenticated (I mean after the TLS handshake is complete). If the resolver does not support RESINFO RRtype, it will return "not implemented" response code and on-path attacker spoofing RESINFO is not possible.




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

Yes, the "sig" attribute is specifically introduced to support DDR. One possible way forward would be to relax the rule to validate the "sig" attribute from "MUST" and "SHOULD". In cases where the "sig" attribute is not provided, clients can process the response if and only if they have an out-of-band agreement with the server operator to abide by its published RESINFO policy.

-Tiru




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



Thanks,

Tommy



From: Add <[e-mail]<mailto:[e-mail]>> On Behalf Of Ben Schwartz
Sent: Friday, October 13, 2023 8:59 AM
To: tirumal reddy <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[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<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/<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<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<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<https://www.ietf.org/mailman/listinfo/add>