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

[tirumal reddy <[e-mail]>]

On Fri, 13 Oct 2023 at 22:23, Tommy Jensen <[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]> *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]>
> *Sent:* Friday, October 13, 2023 8:14 AM
> *To:* Ben Schwartz <[e-mail]>
> *Cc:* [e-mail] <[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]> 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]> on behalf of tirumal reddy <
> [e-mail]>
> *Sent:* Wednesday, October 11, 2023 3:30 AM
> *To:* [e-mail] <[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]> 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]
> https://www.ietf.org/mailman/listinfo/add
>
>