Hi Gurleen,
On Tue, 6 Aug 2024, Gurleen Grewal wrote:
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.
ACME is fundamentally JSON over HTTPS, and as such, it is fundamentally
orders of magnitude more expensive to cause a large amount of lookups over
ACME as compared to over DNS over UDP (or even over DNS over TCP). This
especially holds true when you take the receiving end into account (i.e.
the CA's ACME endpoint), the attacker could indeed cheat a bit and drive
complexity down on their end.
As such, an attack mounted via ACME will be inherently more noticeable to
an attacked CA, as it might even cause resource exhaustion, and would
presumably be visible in metrics and logs. By comparison, an attack
mounted on a resolver operated by a DTP but used for DV would not be
visible to the CA at all, and even if the DTP noticed the attack traffic
they would not understand the significance of it, and it would also not be
something they would prioritize to mitigate when it happens; not only
because nobody will distrust them or qualify their audits or whatever when
they do not, but because it is simply not going to be in the envelope of
guarantees and considerations they offer the service under. At least as
long as the DTP is not specifically in the business of operating a "DV
Resolver".
Furthermore, attacking DNS resolution or the resolver itself through ACME
obviously inherently gives an attacker less degrees of freedom in how to
mount the attack, obscure DNS protocol features would not be accessible,
for example.
These are all significant benefits over simply using a resolver that can
be directly queried by an attacker, and these benefits alone, in my
opinion, illustrate why using a dedicated resolver operated for this
purpose alone is the only way to implement a DV process worth its salt.
You are however entirely correct in noting that more can and should be
done.
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.
It has not been my intention to only imply I would expect rate limits. I
would indeed expect them. I worded it the way I did for a reason, however
that may have caused some confusion. Let me try to provide some
background:
You do not necessarily even need to operate a nameserver for the DV
process, or use any (non-authoritative) nameserver in the process at all.
Many programming languages offer DNS protocol support in ways that allow
you to query authoritative nameservers directly.
Using an actual recursive nameserver to do this work has its benefits, the
usual suspects of nameserver implementations are of course written,
maintained and supported by experts with a high level of expertise and a
commendable commitment to writing secure code and providing appropriate
response to security issues.
But fundamentally, only a small portion of the nameserver's features are
relevant to the process of DV validation, while at the same time the
nameserver's API - the DNS protocol - is very powerful and can in
principle access a much larger portion of the nameserver's features and
code.
Because of that, I would indeed consider it extremely important that such
a nameserver could not be reached by anything other than the DV process
and related, tightly controlled other aspects of the CA's operation (like
name resolution occuring in the context of making requests to e.g. QGIS,
WHOIS, RDAP).
And indeed, I would expect rate limits. These would not be enforced only
on the FQDN level, but also on the public suffix level as determined by
the Public Suffix List. And this is where what I wrote maybe is
confusing: I expect the resolver cannot be reached by anything but the DV
process and related tightly controlled use cases, and as such,
appropriate rate limiting would in my mind probably be enforced in the
part of the DV process that is querying the DV Resolver to begin with.
TL;DR I firmly believe the following measures significantly increase the
security of a DV process:
* Rate limits
* Prevent non-DV-related queries to the DV Resolver
* Query using TCP instead of UDP, or other, similarly secure mechanisms
where available (e.g. QUIC and possibly others pointed to by Aaron Gable
in
https://lists.cabforum.org/pipermail/validation/2024-July/002000.html)
* When querying over UDP, detect attempts at injecting forged responses
However, I am certain there could be additional measures providing great
benefit. Since I am not involved in any DV process at any level, I can
really only contribute at the level of more obvious measures without
digging into it further.
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.
Not saying that would be what you meant, but I just want to make it clear
that in my mind, it is not just about configuring a DNS resolver
"appropriately", it is in fact about being very conscious and careful
about how and for what a resolver is used in the DV process and how to
design this involvement in a way that gives an adequate level of
robustness to DNS level attacks.
Tobi
_______________________________________________
Validation mailing list
[email protected]
https://lists.cabforum.org/mailman/listinfo/validation
