[cabf_validation] Using dedicated DNS resolvers for domain validation

[Aaron Gable]

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:
- Implement RFC 9539 <https://datatracker.ietf.org/doc/rfc9539/> "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.

Aaron

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/20240718/7e8861e0/attachment.html>