[cabf_validation] Using dedicated DNS resolvers for domain validation

[Tobias S. Josefowitz]

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