Re: The CAA DNS Operator Exception Is Problematic
On Wed, Feb 10, 2021 at 02:21:53AM +, Nick Lamb via dev-security-policy wrote: > On Mon, 8 Feb 2021 13:40:05 -0500 > Andrew Ayer via dev-security-policy > 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 Description: PGP signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: The CAA DNS Operator Exception Is Problematic
On Tue, Feb 9, 2021 at 9:22 PM Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Mon, 8 Feb 2021 13:40:05 -0500 > Andrew Ayer via dev-security-policy > 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. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: The CAA DNS Operator Exception Is Problematic
On Mon, 8 Feb 2021 13:40:05 -0500 Andrew Ayer via dev-security-policy 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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: The CAA DNS Operator Exception Is Problematic
On Mon, Feb 8, 2021 at 1:40 PM Andrew Ayer via dev-security-policy < dev-security-policy@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/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
The CAA DNS Operator Exception Is Problematic
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
