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 < [email protected]> 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 > [email protected] > https://lists.cabforum.org/mailman/listinfo/validation >
_______________________________________________ Validation mailing list [email protected] https://lists.cabforum.org/mailman/listinfo/validation
