The Use of DNSSEC by Certificate Authorities

[Henry Birge-Lee]

Hi all,

I would like to open discussion regarding the validation of DNSSEC during domain control validation and CAA checking. I have been discussing this with several form members, but I would like to bring these discussions into a more public light. I present some background and a security justification for why I think explicit inclusion and mandate of DNSSEC validation should be required by the Forum. There is also an appendix to this email addressing some misconceptions regarding DNSSEC that I feel have previously hindered its adoption.

Background:

DNSSEC is fully RFC standardized by the IETF and is a collective name for a group of DNS RFCs that extend the DNS protocol to provide cryptographic validation of domain name lookups. DNSSEC was originally developed as a protection against DNS cache poisoning but also provides protections against a large class of attacks. It operates by signing DNS records so that DNSSEC-validating resolvers will not accept tampered responses. There are two critical properties that DNSSEC has which crypto systems often lack which I think make the point for inclusion of DNSSEC in the CA/B Forum particularly relevant:

Downgrade protection: If a domain is DNSSEC-signed and a resolver validates DNSSEC, this resolver cannot be fooled by getting served non-DNSSEC records even by an on-path adversary. A domain's support for DNSSEC is indicated by a DS record (containing a public key hash) placed at and signed by the parent domain. This signature chain of parent domains goes back to the ICANN root making it impossible to downgrade DNSSEC. Thus, DNSSEC is not an optimistic upgrade protocol (e.g., STARTTLS), it provides full security against downgrade attacks.

Proof of nonexistence: DNSSEC can cryptographically prove DNS records (e.g., CAA records) do not exist. This is done through NSEC/NSEC3 records which are signed records that state what records/labels exist in a zone. If DNSSEC authoritative server gets a query for a non-existent record (for which it cannot return a signed RRSIG), it returns a signed NSEC/NSEC3 record proving that the queried label had no corresponding records of the type requested. A DNSSEC validating resolver will return a SERVFAIL on the absence of a response or a response with an empty answer block, preventing adversaries from suppressing the presence of DNSSEC records.

I highlight these two points as they have major implications to the security of certificate issuance. The adoption of DNSSEC by the Forum would not simply be bringing a new best-effort security mechanism, it would provide cryptographic proof justifying issuance for domains that were signed using DNSSEC.

Also, worth noting, there are two sides to DNSSEC (signing and validating) each of which has different operational considerations. Validating is more widespread than signing (~30% adoption to ~5% adoption) and organizations have been more receptive to it (e.g., Google does not sign google.com but does do DNSSEC validation on default Google cloud lookups and their public 8.8.8.8 DNS resolver). I am primarily advocating the adoption of DNSSEC validation as I feel this is most critical for the protection of subscriber domains and has a smaller operational impact.

Security benefits:

1. Stewardship of the DNS security enacted by millions of domains. A study by our group looked at DNSSEC-signing among domains using Let's Encrypt and found it to be at %5.88 of domains from a 90-day log sample (representing 11.7M domains, see https://secure-certificates.princeton.edu/cryptographic-domain-validation.pdf ). We have taken similar measurements based on CT and they have a roughly similar percentage. While this is not a majority of the ecosystem, it is still millions of domains that have taken the time to create these records and opted into this security protocol. Furthermore, several of the domains we observed opting in to DNSSEC are clearly high-security domains. These include torproject.net, bankofamerica.com along with several other government and financial websites. I think the naive approach of simply looking at the summary statistic for deployment does not take into account the reality that some domains are significantly more high-value targets than others and these domains are more likely to adopt DNSSEC. It is the responsibility of the PKI to follow security best practices and validate these records as opposed to ignoring them.

2. Protection against mis issuance from on-path and off-path attacks on domain DNS infrastructure. Given that DNSSEC utilizes cryptographic proofs, it protects against a large class of attacks on DNS infrastructure including off-path attacks like TXID guessing, IP fragmentation attacks, off-path TCP vulnerabilities and on-path attacks like an on-path adversary or a compromised router and global BGP attacks. I am familiar with a BGP attack which lead to certificate misissuance that was executed via announcing the BGP prefix of a victim's nameserver and serving malicious DNS responses that pointed to adversary infrastructure. In this attack, evidence seems to suggest that the DNS server was an opportunistic target given BGP routing protections that made the victim's webserver IPs more difficult to target. This attack could have been prevented with DNSSEC presuming CAs validated DNSSEC signatures. Thus, DNSSEC provides strong and concrete security benefits in the PKI today.

3. CAA + DNSSEC + account ID/secure validation: There is immense synergy between CAA records and DNSSEC. With the advent of CAA records, a CA's permission to issue a certificate is established via DNS queries. Recent CAA record extensions (RFC 8657) go even further to authorize specific domain control validation methods or account IDs that can get certificates. This creates an absolutely critical interplay between DNSSEC and CAA. CAA records can restrict issuance to a particular account ID (which lets assume is securely backed by a cryptographic key) and the CAA records themselves can be protected with DNSSEC, for the first time in the history of the PKI, certificate issuance can be completely based on cryptographic trust and have cryptographic protections against all on path adversaries. This also applies to the use of dns-01 as the required validation method in the CAA record when the DNS validation records are also protected with DNSSEC. These specific techniques are outlined in Sec 5.6 of RFC 8657(see https://datatracker.ietf.org/doc/html/rfc8657#section-5.6 ). Our group also expanded on these ideas, introduced a more general CAA record type for this purpose (see https://birgelee.github.io/draft-caa-security-tag/draft-birgelee-lamps-caa-security.html ), and performed formal analysis proving the security of this technique in a recent paper draft ( https://secure-certificates.princeton.edu/cryptographic-domain-validation.pdf ). Most importantly, several prominent domains are already using this technique and will obtain full protection against on and off path adversaries should the Forum require DNSSEC validation. These sites include slack.com and debian.org (which hosts the Debian APT source lists).

4. Proper enforcement of the DNSSEC-CAA fail clause and the CAA RFC. The Baseline Requirements contain a statement that:

CAs are permitted to treat a record lookup failure as permission to issue if:
• the failure is outside the CA’s infrastructure; and
• the lookup has been retried at least once; and
the domain’s zone does not have a DNSSEC validation chain to the ICANN root.

The way I see it there are three ways to be compliant with these statements: 1) never treat a CAA lookup failure as permission to issue, 2) validate DNSSEC and only treat a lookup failure as permission to issue if the DNSSEC chain provably stops before the final record or 3) check for the presence of DNSSEC records (without necessarily validating those records) and if DNSSEC-related records are not seen (e.g., DNSKEY), allow the lookup failure to be permission to issue. Given this reference to DNSSEC is included in the Baseline Requirements and no requirement that DNSSEC be validated, one would assume that option 3 is valid way to operate a CA. However, this wording is not well formed in light of DNSSEC's proof of non-existence.  If DNSSEC is not validated, an adversary can maliciously suppress the presence of DNSSEC-related records. Imagine a domain (say d) is DNSSEC-signed and is serving all appropriate DNSSEC records. An on-path adversary now goes and surpasses the presence of the DNSSEC-related records at d by injecting empty DNS answers for all DNSSEC-related record types. This does not change the DNSSEC-status of d which is still DNSSEC-signed. This suppression of the DNSSEC records makes the response not DNSSEC valid, but the CA is not validating DNSSEC as this is not required by the current Baseline Requirements. Thus, without DNSSEC validation one cannot confirm or deny if a domain is DNSSEC-signed or not. To this end, I think requiring DNSSEC validation is required to implement downgrade protection that I expect was intended by this section of the Baseline Requirements.

Another mention of DNSSEC in normative requirements is the statement in RFC8659 (see https://datatracker.ietf.org/doc/html/rfc8659#name-use-of-dns-security ) which reads:

The use of DNSSEC to authenticate CAA RRs is strongly RECOMMENDED but not required

While this clearly does not require DNSSEC (likely to aid in the RFC getting considered by the CA/Browser Forum as a normative requirement), I feel it is clear that the security model presented by CAA records is significantly improved by DNSSEC validation. In the absence of DNSSEC, CAA records do not significantly help against attacks on DNS. Imagine there are two CAs, CA_insecure and CA_secure. A domain owner puts in CA_secure in their CAA record given a recent expose that CA_insecure is vulnerable to DNS cache poisoning attacks. While this would seem like a good use case for CAA records, an adversary can simply exploit CA_insecure's cache poisoning vulnerability to manipulate CA_insecure's CAA lookup (eliminating the security provided by the domain owner's CAA record) and then also manipulate the DNS records required to spoof domain control validation. Because CAA records cannot be authenticated today, domain owners have no tools to avoid weak or insecure DNS deployments by a subset of CAs since the very CAA records used to prevent attacks could themselves be manipulated. Thus, I think the adding DNSSEC validation to the Baseline Requirements helps significantly strengthen the security benefits of CAA records.

5. DNSSEC validation is a well-established best practice for recursive DNS resolvers (see the RIPE DNS Resolver Recommendations https://www.ripe.net/publications/docs/ripe-823/ )

In Closing:

One closing remark I would make about DNSSEC validation is that there are several similarities between DNS resolvers that do not perform DNSSEC validation and web browsers that do not perform TLS certificate validation. I feel that it is the due diligence of a security-conscious web client to perform TLS certificate validation and this is critical regardless of the percentage of websites that use HTTPS or one's personal views on the HTTPS ecosystem. There is a well-established security signal present and well-established handling of that signal that does not risk uptime. To me this argument extends to DNSSEC. DNSSEC presents a cryptographic ground truth. Signing a certificate based on a DNS response that is provably inaccurate feels inappropriate. Yet, as of today, in the top 6 CAs, Digicert and GoDaddy still signed certificates based on DNS queries that had invalid DNSSEC signatures (see https://secure-certificates.princeton.edu/cryptographic-domain-validation.pdf table 6).

I urge the CA/B Forum to consider this issue in a timely manner. Servercert GitHub pull request 567 (which I know is on the agenda for discussion) has language that requires DNSSEC for CAA records https://github.com/cabforum/servercert/pull/567 . Another approach (which I have lately become more inclined towards given I am familiar with an attack that involved misissuance because of on attacks on DNS servers used for DCV) would be to require DNSSEC validation for all lookups performed as part of any step of domain control validation or CAA record checking. I think this would offer stronger security properties than just DNSSEC on CAA record checking.

Also, I have heard feedback that referencing an RFC or group of RFCs may be cleaner than bringing specific DNSSEC language into the Baseline Requirements the way pull request 567 does. RFC 9364 is a good place to obtain a list of relevant RFCs. Most common DNS implementations mention which RFCs they are designed to be compliant with (see https://nlnetlabs.nl/projects/unbound/rfc-compliance/  and https://bind9.readthedocs.io/en/v9.18.15/general.html ). I think saying something like "all DNS queries related to domain control validation and CAA record checking must have DNSSEC validated as defined in these RFCs..." could be easily implemented and audited (particularly since CAs are not allowed to outsource DNS to a third party).

Thank you for your consideration. I have spoken with several members of ICANN and major DNS operators who overwhelmingly support the use of DNSSEC validation by Certificate Authorities. I think the onus is on this body to enforce that CAs uphold strong security standards, of which I feel this is one.

Best,
Henry


-------------------------APPENDIX-------------------------

DNSSEC misconceptions:

1. Misconception: DNSSEC misconfigurations are so prevalent validating DNSSEC would deny certs and turn away customers. As of 2023, 30% of clients use DNS resolvers that validate DNSSEC 
(see https://blog.apnic.net/2023/09/18/measuring-the-use-of-dnssec/) and are unable to access a domain that is DNSSEC invalid. These include users of the popular Google and CloudFlare public DNS service. Thus, any website with a DNSSEC invalid configuration will immediately loose traffic from 30% of users that get resolution errors. Thus, it is not likely that a legitimately-operating website will continue to run with a persistent DNSSEC validation error.

2.   Misconception: DNSSEC introduces so much latency in DNS lookups it is not practical at the scale of the PKI. I think this is most effectively disproven with the fact that 3 of the top 4 largest CAs by volume (per https://crt.sh/cert-populations ) currently validate DNSSEC (specifically ISRG, Sectigo, GTS). These CAs are all signing thousands of certificates a day with DNSSEC validation. Additionally, some of the highest-volume DNS resolvers in the world (Google and CloudFlare's public DNS) validate DNSSEC at an Internet scale without issue. DNSSEC signatures can cause some latency increase (particularly if they are large and trigger a TCP fallback), but DNSSEC does play nicely with DNS caching and can largely be operated using the existing DNS infrastructure already run by CAs.

3. Misconception: DNSSEC has been superseded by other encryption schemes. I have heard variations of this argument several times and they often have little technical merit. One particular variant of this is that DNSSEC is no longer needed due to the rise of HTTPS (see https://blog.apnic.net/2024/05/28/calling-time-on-dnssec/ ). This is clearly not an appropriate argument in this context as CAs are the trust roots for TLS/HTTPS. CAs need to accurately retrieve information about a domain and cannot bootstrap trust on TLS when issuing TLS certificates potentially for the first time. Another variant on this argument is saying that DoH/DoT/DoQ (which I will refer to as DoX to represent DNS piped over an arbitrary TLS channel) are more promising ways of encrypting DNS. This also is not relevant in the CA context as DoX aims to encrypt client to recursive DNS queries but does not secure recursive to authoritative DNS queries. Recent RFC 9539 does explore the use of DoX in recursive to authoritative queries, but does not have any means of authenticating the identities of the authoritative DNS servers. It is merely encryption to protect the DNS queries from passive adversaries, not providing authentication of the DNS responses (see https://www.rfc-editor.org/rfc/rfc9539.html#name-authentication ). The security of authoritative DNS lookups is paramount to the secure issuing of digital certificates. I feel no other currently proposed/standardized crypto system offers comparable security in this context. DNSSEC is and has always been the primary solution proposed for the cryptographic security of authoritative DNS records.


DNSSEC and MPIC:

Over the last couple years I have had several discussions regarding DNSSEC and MPIC. Two variants I often here are "Do we need DNSSEC validation if we do MPIC?" and "Do we need MPIC if we do DNSSEC validation?" I will stress that that answer to both of these questions is Yes as these two security technologies do very different things. DNSSEC validation 1) only protects DNS lookups (e.g., it does not protect connections to webservers that might occur during domain control validation) and 2) only provides a security benefit to the 5.8% of security-conscious domains that choose to deploy it. Despite these limitations, DNSSEC provides cryptographic proof and its security is derived from the underlying properties of the cryptography it is based on, independent of an adversary's position in the network. MPIC on the other hand has the benefit of providing security to both DNS queries and web server communication and it offers a security improvement to 100% of domains with no opt in. However, MPIC inherently is a best-effort security measure. It is vulnerable to global attacks which can affect traffic from all of the perspectives. For example, imagine an adversary compromised an ISP that is providing connectivity to a domain's authoritative DNS server. If this was the exclusive ISP used for that domain's authoritative DNS, MPIC would not be able to defend against this attack as all perspectives would be affected. However, DNSSEC could protect against this threat model.

A more high-level way to consider this is that MPIC covers a very wide attack surface but provides best effort security making it much harder for adversaries to succeed (thus stopping most but not all adversaries). DNSSEC covers a more narrow threat surface but bases its protection on well-established cryptography algorithms (which to the best of our knowledge have never been broken). These are both important to the security of the PKI.

There is one additional interaction between DNSSEC and MPIC that I think should be addressed. That is: Should DNSSEC validation be required by remote perspectives doing MPIC. After careful thought, I am of the opinion remote perspectives do not necessarily need to be doing DNSSEC validation. The reasoning for this has to do with DNSSEC's permission of signature reuse. Essentially, to ensure DNSSEC does not disrupt existing DNS caching and to allow for offline DNSSEC keys, a DNSSEC-signed response can be reused until its signature expires. Let us assume the primary perspective is performing DNSSEC validation and an adversary wants to manipulate a DNS response as part of his/her effort to obtain a malicious certificate. There are several cases here:

1. Domain is not DNSSEC signed: DNSSEC-validation at remote or primary perspectives does not have an impact

2. Domain is DNSSEC signed and adversary does not have access to malicious DNSSEC-signed response: DNSSEC-validation at the primary perspective would catch this attack.

3. Domain is DNSSEC signed and adversary presents a DNSSEC-valid response to the primary perspective: here there are two sub-cases based on the state of the remote perspectives

3.a. Adversary cannot hijack enough remote perspectives to satisfy the quorum policy: The remote perspectives reach the victim and find the legitimate DNS response thus blocking issuance.
3.b. Adversary can hijack enough remote perspectives to satisfy the quorum policy: since DNSSEC signatures can be reused, the same DNSSEC-valid malicious response used to fool the primary domain could be used to fool the remote perspectives as well.

Thus, no where in this decision tree is there a case where issuance is blocked because the remote perspectives validated DNSSEC. This argument largely revolves around the principle that if an adversary has access to DNSSEC-valid records authorizing his/her malicious issuance (as would be needed to fool the primary perspective), the same signed records could just as easily be presented to the remote perspectives making their additional DNSSEC validation not present significant security value. Additionally, unlike primary perspective DNS, MPIC remote perspectives can be delegated to a third party. There are some situations where the default DNS resolvers used by cloud providers do not validate DNSSEC. Thus, I feel there is an additional operational burden related to DNSSEC validation for MPIC that is not present for DNSSEC validation at the primary perspective. With this in mind I think it makes sense to explicitly omit MPIC remote perspectives from a normative requirement regarding DNSSEC validation.

[Henry Birge-Lee]

Hi all,

Per conversations earlier today, I put in some potential language around this and initiated a pull request against Clint Wilson's previous DNSSEC for CAA ballot branch (as it updates this proposed language).

The overall strategy for this change would be to:

1. Remove any reference to DNSSEC in Wayne's CAA Extensions ballot (RFC 8657)

2. Ideally move forward with a separate ballot that requires DNSSEC for DCV and CAA checking (which is synergistic with CAs likely already using the same DNS resolver for both).

Overall I tried to base the requirement off of DNSSEC RFCs and terms defined therein with specific section references to avoid any ambiguity. The primary and current RFC defining this is RFC 4035. However, there are some extensions presented in RFC 6840 (particularly NSEC3 and SHA-2) that I feel should be explicitly mandated.

I should note, both of these RFCs were listed as supported by the handful of DNS resolvers I looked at (e.g., https://nlnetlabs.nl/projects/unbound/rfc-compliance/ , https://bind9.readthedocs.io/en/v9.18.15/general.html , https://github.com/hickory-dns/hickory-dns ).

I also put in some clarification regarding the CAA lookup fail language. The current language reads:

CAs are permitted to treat a record lookup failure as permission to issue if:
• the failure is outside the CA’s infrastructure; and
• the lookup has been retried at least once; and
• the domain’s zone does not have a DNSSEC validation chain to the ICANN root

I personally think there are two major problems with this language:

1. Inability to prove non-existence if DNSSEC validation is not being done. DNSSEC proves non-existence. If DNSSEC is not validated (and it is not required as of today), a CA has no way of cryptographically confirming whether a domain does or does not have a DNSSEC validation chain to the ICANN root. Thus, any issuance on a CAA lookup failure could potentially be a misissuance. Reading this language, I suspect this was intended to ensure the lookup error being permission to issue did not affect the security of DNSSEC-signed domains. However, in the status quo, if a CA does not validate DNSSEC but attempts to determine whether or not the chain exists, an adversary can suppress the presence of DNSSEC at a domain and a CA has no way of knowing about this.

1 (fix) This wording flaw is fixed simply by requiring the use of DNSSEC elsewhere in the BRs.

2. No way of knowing whether a domain "has" a DNSSEC validation chain to the ICANN root. This may seem pedantic, but I do not think this language is well enforceable given DNS's operation as a distributed database. If DNS was a centralized database, "has" would probably imply a concrete meaning of is there a particular set of records in the central database. However, DNS is more complex. In some view of the system a domain may "have" such a signature chain, but this may not be the view presented to the CA. Imagine a domain just turned DNSSEC off. The domain's provider would generate a new NSEC3 record showing there is no DS record associated with the domain. However, this change may take some time to propagate and the old DS record may still be cached in some contexts. Here, the domain 1) "has" a signature chain going back to the ICANN root (i.e., one can construct a non-expired signature chain using the old DS record) and 2) "has" a proof of non-existence that it is no longer DNSSEC signed. This is a perfectly fine transient state for a domain to be in and is the proper way to turn off DNSSEC. Because of the potential presence of these states, I feel a CA has no way of truly knowing if there exists such a signature chain or not. The CA is only aware of what it can verify, not records or signatures that may exist which it has not seen.

2 (fix) In my proposed change this language is brought back to RFC 4035 section 4.3 which clearly states the various states of DNSSEC validation (https://datatracker.ietf.org/doc/html/rfc4035#section-4.3). Of these listed states, the one I feel is intended by the statement "the domain’s zone does not have a DNSSEC validation chain to the ICANN root" is "Insecure" which reads:

Insecure: An RRset for which the resolver knows that it has no chain
      of signed DNSKEY and DS RRs from any trusted starting point to the
      RRset.  This can occur when the target RRset lies in an unsigned
      zone or in a descendent of an unsigned zone.  In this case, the
      RRset may or may not be signed, but the resolver will not be able
      to verify the signature.

Here the RFC is quite clear to have a callout to this case where the zone itself may be signed, but the validating resolver does not expect there to be a signature due to the absence of a DS record. To provide additional clarity, I also specified in the draft language that this implied the presence of NSEC/NSEC3 record proving there is no DS record for the domain being queried.

I put in a pull request against the existing DNSSEC for CAA validation branch established by Clint Wilson. Feel free to look over it here:

https://github.com/cabforum/servercert/pull/571

Thank you for the discussions in the teleconference earlier today. I hope this pull request can address some of the topics that came up.

Best,

Henry

--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/6c1df8c7-9965-4072-b6ba-88b755df4afan%40groups.cabforum.org.