The CAA DNS Operator Exception Is Problematic

325 views
Skip to first unread message

Andrew Ayer

unread,
Feb 8, 2021, 1:40:15 PM2/8/21
to mozilla-dev-s...@lists.mozilla.org
The BRs permit CAs to bypass CAA checking for a domain if "the CA or
an Affiliate of the CA is the DNS Operator (as defined in RFC 7719)
of the domain's DNS."

Much like the forbidden "any other method" of domain validation, the DNS
operator exception is perilously under-specified. It doesn't say how
to determine who the DNS operator of a domain is, when to check, or for
how long this information can be cached. Since the source of truth for a
domain's DNS operator is the NS record in the parent zone, I believe the
correct answer is to check at issuance time by doing a recursive lookup
from the root zone until the relevant NS record is found, and caching
for no longer than the NS record's TTL. Unfortunately, resolvers do
not typically provide an implementation of this algorithm, so CAs would
have to implement it themselves. Considering that CAs are not generally
DNS experts and there are several almost-correct-but-subtly-wrong ways
to implement it, I have little faith that CAs will implement this
check correctly. My experience having implemented both a CAA lookup
algorithm and an algorithm to determine a domain's DNS operator is that
it's actually easier to implement CAA, as all the nasty DNS details can
be handled by the resolver. This leads me to conclude that the only CAs
who think they are saving effort by relying on the DNS operator exception
are doing so incorrectly and insecurely.

A manifestation of my concerns is this incident involving Microsoft PKI
Services:

https://bugzilla.mozilla.org/show_bug.cgi?id=1670337

Until last month, Microsoft was not checking CAA, but instead relying on
the DNS operator exception. Despite this, they misissued certificates
for both a nonexistent domain and a domain for which they were not the
DNS operator, demonstrating that they had not correctly implemented
the exception. Although Microsoft is now checking CAA for routine
issuances, they are retaining the DNS operator exception for "one off"
issuances, and the process they intend to use involves manually using
the websites https://dns.google.com/ and
https://toolbox.googleapps.com/apps/dig/, which is both a forbidden use
of Delegated Third Parties, and probably not correct because these
tools don't allow you to make non-recursive requests directly to
authoritative servers as required by the above algorithm.

Considering the under-specification of the DNS operator exception and
the risk of CAs being enticed by the apparent but false simplicity of
the exception, I think Mozilla should ban the use of the DNS operator
exception just as it banned "any other method" of domain validation.
At the very least, it deserves a mention on the list of Problematic
Practices.

Regards,
Andrew

Ryan Sleevi

unread,
Feb 8, 2021, 2:27:40 PM2/8/21
to Andrew Ayer, mozilla-dev-security-policy
On Mon, Feb 8, 2021 at 1:40 PM Andrew Ayer via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> The BRs permit CAs to bypass CAA checking for a domain if "the CA or
> an Affiliate of the CA is the DNS Operator (as defined in RFC 7719)
> of the domain's DNS."
>
> Much like the forbidden "any other method" of domain validation, the DNS
> operator exception is perilously under-specified. It doesn't say how
> to determine who the DNS operator of a domain is, when to check, or for
> how long this information can be cached. Since the source of truth for a
> domain's DNS operator is the NS record in the parent zone, I believe the
> correct answer is to check at issuance time by doing a recursive lookup
> from the root zone until the relevant NS record is found, and caching
> for no longer than the NS record's TTL. Unfortunately, resolvers do
> not typically provide an implementation of this algorithm, so CAs would
> have to implement it themselves. Considering that CAs are not generally
> DNS experts and there are several almost-correct-but-subtly-wrong ways
> to implement it, I have little faith that CAs will implement this
> check correctly. My experience having implemented both a CAA lookup
> algorithm and an algorithm to determine a domain's DNS operator is that
> it's actually easier to implement CAA, as all the nasty DNS details can
> be handled by the resolver. This leads me to conclude that the only CAs
> who think they are saving effort by relying on the DNS operator exception
> are doing so incorrectly and insecurely.


Thanks, Andrew, for raising this.

This does seem something that should be looked to be phased out /
forbidden.

We've seen similar concerns raised related to BygoneSSL [1], with respect
to Cloud Providers (incorrectly) believing they are the domain operator
(e.g. customer account configured, but DNS now points elsewhere)

[1] https://insecure.design/

Nick Lamb

unread,
Feb 9, 2021, 9:22:09 PM2/9/21
to dev-secur...@lists.mozilla.org, Andrew Ayer
On Mon, 8 Feb 2021 13:40:05 -0500
Andrew Ayer via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> The BRs permit CAs to bypass CAA checking for a domain if "the CA or
> an Affiliate of the CA is the DNS Operator (as defined in RFC 7719)
> of the domain's DNS."

Hmm. Would this exemption be less dangerous for a CA which is the
Registry for the TLD ?

I can see that there are a set of potential problems that can happen
where an entity mistakenly believes they are the DNS Operator when they
in fact are not, because there's a difference between configuring your
DNS servers to answer (I can tell mine to answer for google.com) and
having the authority to answer, but it seems like it's pretty clear
that either you are the registry for some TLD or you aren't, and so
that confusion ought not to arise in this case.

The existence of the exemption doesn't mean you need to take advantage
of it of course, it may be that any organisation large enough to
possess a CA and a Registry function today thinks it would prefer to
use public methods and not try to short-cut internally anyway, in which
case my thought doesn't matter.


Nick.

Ryan Sleevi

unread,
Feb 10, 2021, 8:45:34 AM2/10/21
to Nick Lamb, Andrew Ayer, dev-secur...@lists.mozilla.org
On Tue, Feb 9, 2021 at 9:22 PM Nick Lamb via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Mon, 8 Feb 2021 13:40:05 -0500
> Andrew Ayer via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>
> > The BRs permit CAs to bypass CAA checking for a domain if "the CA or
> > an Affiliate of the CA is the DNS Operator (as defined in RFC 7719)
> > of the domain's DNS."
>
> Hmm. Would this exemption be less dangerous for a CA which is the
> Registry for the TLD ?


Potentially, but that’s not the use case for why this exists. Recall that
Registry != Registrar here, and even then, the Operator may be distinct
from either of those two. The use case argued was not limited to “just”
gTLDs.

>

Wojtek Porczyk

unread,
Feb 10, 2021, 1:43:14 PM2/10/21
to Nick Lamb, dev-secur...@lists.mozilla.org, Andrew Ayer
On Wed, Feb 10, 2021 at 02:21:53AM +0000, Nick Lamb via dev-security-policy wrote:
> On Mon, 8 Feb 2021 13:40:05 -0500
> Andrew Ayer via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>
> > The BRs permit CAs to bypass CAA checking for a domain if "the CA or
> > an Affiliate of the CA is the DNS Operator (as defined in RFC 7719)
> > of the domain's DNS."
>
> Hmm. Would this exemption be less dangerous for a CA which is the
> Registry for the TLD ?

I understand this would remove one way to shoot yourself in the foot.

> [...], but it seems like it's pretty clear
> that either you are the registry for some TLD or you aren't, and so
> that confusion ought not to arise in this case.

The argument is that theoretically this could work, but in practice people get
this wrong. Examples were given that confusion in fact happens.


--
pozdrawiam / best regards
Wojtek Porczyk
Graphene / Invisible Things Lab

I do not fear computers,
I fear lack of them.
-- Isaac Asimov
signature.asc
Reply all
Reply to author
Forward
0 new messages