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