[cabf_validation] Using dedicated DNS resolvers for domain validation

[Gurleen Grewal]

Thanks for the thorough analysis and recap of the technical arguments for
using a dedicated DNS resolver. We had a couple of questions/thoughts to
add to the discussion.

Any publicly available ACME CA essentially operates as a public resolver -
by invoking the ACME protocol and requesting domain validation, an attacker
can cause the CA to perform DNS queries for a domain of their choice. In
this case, solely running a dedicated resolver is not an effective
mitigation against the kinds of attacks described.

Could you provide more detail on what mitigations you expect a CA to
implement relative to DNS resolution - e.g. rate limiting DNS queries seems
to be one of the implied measures a dedicated resolver would be expected to
implement? Before the discussion gets too far along, it would help to have
a list of potential threats and tie potential mitigations back to them.

Generally, GTS is in favor of additional requirements on DNS resolvers for
Domain Validation and we’d welcome more work in the community on best
practices for robust DNS resolution.

On Thu, Jul 18, 2024 at 9:27 AM Tobias S. Josefowitz via Validation <
validation at cabforum.org> wrote:

> Hi Doug,
>
> On Mon, 15 Jul 2024, Doug Beattie via Validation wrote:
>
> > During the last VWG call we had a good technical discussion on security
> > concerns related to DNS resolvers being used for multiple purposes.
> > There was agreement that CAs need to use a dedicated DNS resolver for
> > domain validation even if we didn't reach agreement on being permitted
> > to use a third party resolver.
> >
> > I'm curious what the scope of "domain validation" means in this regard.
> > Can CAs use the same resolver for CAA, posting certificates to CT logs,
> > doing who-is or RDAP queries, and if not, then maybe we should list more
> > specifically what we mean by "Dedicated resolver for Domain Validation"
> > when it comes to this locked down resolver topic?
>
> I'd like to start by stating that my comments regarding the use of DNS in
> DV during that call were mostly about the goal and purpose of DV, the
> functional properties of the DNS protocol, associated risks and
> security threats. I was outlining what I would expect an implementation of
> a DV process to look like; it was not necessarily a comment about what is
> currently required by the BRs or NCSSRs or anything else.
>
> To summarize my perspective, the DNS protocol has inherent weaknesses that
> threaten the authenticity of DNS responses/results. For example, DNS was
> initially designed to be a UDP-based protocol, and the only security
> measure against spoofed responses was a two-byte request ID field that
> would be populated with a random value (one of 65536 possible).
>
> While the protocol has been extended to be defined over TCP as well, UDP
> is usually preferred by resolvers for performance. The current security
> baseline for UDP-based DNS requests is less than 4 byte of randomness
> protecting the resolver from spoofed responses (some of you may remember
> that Dan Kaminsky drew attention to the fact that DNS is only protected by
> two bytes in 2008, and coordinated an industry-wide push to include source
> port randomization in DNS queries to increase randomness to a bit less
> than four bytes - some of you may even be aware that Dan "djb" Bernstein
> has pointed this out much before Kaminsky but has been widely ignored).
>
> These weaknesses have often been the basis for off-path attacks against
> DNS. If we for simplicity assume two bytes of "security", you can see that
> even if your random value is hardcoded to "0xff", you will succeed in
> spoofing 1 out of 65536 requests in so far as you manage to always send
> your forged response after the resolver sent the query but before it
> receives the authoritative nameserver's response. Thus it is obviously
> immediately beneficial for an attacker if they can cause the resolver to
> make many requests, giving the atacker more chances to get the resolver to
> accept a forged response.
>
> Both the DNS protocol and DNS resolver implementations have received
> further hardening against such attacks, for example the DNS COOKIE
> mechanism extension to the protocol and DNSSEC, as well as hardening
> against so called sibling attacks in implementations. These are good
> measures, but as we know DNSSEC rollout is minimal when it comes to
> protected domains, and DNS COOKIE is an optional extension that attackers
> could even run downgrade attacks against.
>
> Considering that at its core, DNS is still (usually) a DNS based protocol
> with less than four bytes of security, I would expect that anyone trying
> to use it for Domain Validation would conclude that DV requires special
> considerations when it comes to the use of DNS.
>
> When I think about it, immediate conclusions are:
>
> * It must not be possible for attackers to issue requests to the DNS
>    resolver used, except as mitigated by the DV process to what is
>    absolutely necessary and at a moderated volume/maximum frequency.
> * The resolver should probably try to query via TCP by default, and only
>    fall back to UDP when querying via TCP is not supported by the
>    authoritative nameserver that is being queried.
>
> These two points are critical considerations, but they are by no means
> exhaustive. When actually impementing a "DV resolver", I would expect more
> topics to come up and be considered, ranging from looking at the
> configuration options and establishing what are good settings for the DV
> use case, as well as the question of whether DNS protocol-level attacks
> (attempts) against the "DV resolver" should be detected and cause
> validation to fail or lead to other, more advanced or refined measures to
> ensure correctness of the validation.
>
> I put the second point as a "should probably" because I have not tried
> this in any real-world application and cannot with absolute confidence,
> ascertain how many problems this would cause. I hope none to very few if
> done properly.
>
> These two points immediately preclude any kind of public resolver from
> being used, because they indeed accept all kinds of queries from potential
> attackers and are configured to provide DNS results quickly (i.e. they
> prefer UDP over DNS). I would wager that there is no third party service
> currently offered by anyone that would fit these criteria.
>
> Looking at the two points given above, I would further conclude that using
> the "DV resolver" for figuring out how to reach whois/RDAP and CT logs
> ranges anywhere from "not conflicting" to "probably a good idea", likely
> closer to the latter.
>
> Tobi
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/validation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20240806/884cebaf/attachment-0001.html>