Ballot SC-91: Sunset 3.2.2.5.3 Reverse Address Lookup Validation, proposal of new DNS-based validation using Persistent DCV TXT Record for IP addresses

[geegeea]

Ballot SC-91: “Sunset 3.2.2.5.3 Reverse Address Lookup Validation, proposal of new DNS-based validation using Persistent DCV TXT Record for IP addresses”

This ballot sunsets 3.2.2.5.3 ( “Reverse Address Lookup”) and introduces 3.2.2.5.8 (“DNS TXT Record with Persistent Value in the Reverse Namespace”) as its replacement.

This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to allow this method for issuance of certificates with an IP address listed in the Certificate.

Background

The “Reverse Address Lookup” method (3.2.2.5.3) has been recognized as insecure due to its reliance on PTR records and indirect validation of domains instead of IP addresses. However, DNS-based validation of IP addresses is useful for many specific client use cases (e.g., ssh frontends, DoH servers) where HTTP- or TLS-based validation is infeasible due to security concerns with opening associated ports or difficulty with serving challenges from anycasted addresses. For the replacement of “Reverse Address Lookup,” we offer another validation method, “DNS TXT Record with Persistent Value in the Reverse Namespace.” The new method is a more secure replacement of 3.2.2.5.3, allowing subscribers to validate IP addresses by DNS while mitigating the risk of “crossover” attacks.

The new method addresses two primary security concerns of the “Reverse Address Lookup” method: (1) staleness of PTR records (by requiring a TXT record placed at a validation-specific prefix in the .arpa zone) (2) lack of authentication and crossover risk (by requiring an account-bound credential to be placed in the TXT record).

Scope

Two related issues were raised during public discussion of the new validation method:

1. CAA validation for IP addresses

• The new method represents the first validation method to involve placement of validation-specific DNS records in the .arpa reverse namespace. A natural corollary to this novelty is that CAA records can also be placed in these zones, to extend CAA protections to IP addresses that are issued certificates.
• There are concerns about the potential network load involved in querying CAA records of zones associated with IP addresses. A full CAA lookup for an IPv6 address with no record would involve 34 separate CAA queries, due to tree climbing. This CAA lookup must be repeated from multiple vantage points due to MPIC, which may overload nameservers with several hundred CAA queries when validating a single IPv6 address.
• A follow up ballot [We suggest] constraint CAA checks to the exact reverse label of the IP address used for validation, disabling tree climbing. (Alternatively, tree climbing may be limited to climbing 8 labels maximum.)

2. Validation of blocks of IP addresses

• The structure of the in-addr.arpa and ip6.arpa zones does allow delegation of blocks of IP addresses. Because of this, placing the Persistent DCV TXT Record at a higher reverse zone than an individual IP address may suggest validation for that extended zone of an IP address block (for example, placement of a TXT record at _persist.3.2.1.in-addr.arpa for validation of addresses 1.2.3.0-1.2.3.255).
• 3.2.2.5.3 never allowed block-level validation.
• To avoid introducing new semantics, the new method explicitly applies ONLY to validation of single IP addresses. The usage of this method for validation of blocks of IP addresses is out of scope for this ballot.

Justification:

For sunsetting the “Reverse Address Lookup” method for IP addresses (3.2.2.5.3) :

• The method proves a “weak binding” between the IP address listed in the Certificate and the domain name that ultimately completes DV for the certificate to be issued.

  • “Reverse Address Lookup” involves querying PTR records for an IP address’s associated reverse DNS name, and then validating the returned domain name using a DV method listed in 3.2.2.4. Successfully validating the PTR’s domain name proves control over that domain, but does not necessarily prove control of the IP address itself or its reverse zone.

• Stale PTR records represent a critical security risk for this validation method.

  • PTR records are often stale, especially due to dynamic IP reassignment in cloud-based environments. “DNS scavenging” (removal of PTR records for decommissioned domain names) is not enabled by default on DNS server implementations. Additionally, there is no mechanism to sync updates in a FQDN’s A or AAAA records to PTR records in the corresponding reverse zone.
  • If an IP address’s PTR record(s) point to a domain that is no longer in use, an attacker can gain control of the free domain name, and complete validation for an IP address that they do not actually control or have administrative access to. Thus, the method may allow attackers to obtain fraudulent certificates that contain a IP address(es) they do not possess authoritative control.
  • The current reverse name validation method does not require any indication of request to issue in the reverse zone itself; there is no validation-related prefix appended to the reverse name associated with the IP address.

• Reverse Address Lookup allows any DV method for domains in 3.2.2.4 to be applied for validation of the domain listed in the IP address’s PTR records. Thus, it inherits the attack surface of the superset of all domain DV methods; its effective security is tied to the weakest domain validation method still permitted.

  • The previous method allowed ANY of the 3.2.2.4 methods to be used to validate the IP address, introducing “crossover” attack risk by tying IP address validation to validation of an unrelated domain.
  • This included (previously) weaker WHOIS, email, and phone contact-based methods (scheduled to be sunset by SC-90). This represents a broader attack surface compared to 3.2.2.5.22, which consists purely of DNS. Compromise of any of the 3.2.2.4 methods could allow an attacker to gain a misissued certificate for an IP address.

For creation of 3.2.2.5.8, “DNS TXT Record with Persistent Value in the Reverse Namespace”:

• Offers a secure replacement for a DNS-based validation method for IP addresses

  • The new method limits the validation challenge to direct DNS TXT queries in the .arpa zone associated with an IP address. This focuses proof of control on the authoritative namespace for that IP, rather than relying on a generic PTR record that may be stale or repurposed for uses unrelated to validation.
  • By contrast, “Reverse Address Lookup” allowed ANY of the 3.2.2.4 methods to be used to validate the IP address, introducing “crossover” attack risk by tying IP address validation to validation of an unrelated domain.

• The newly created “DNS TXT Record with Persistent Value” method (SC-088v3, to be 3.2.2.4.22) for validation of domains offers several benefits to subscribers in terms of operational ease, flexibility, and ease of automated certificate issuance. These same benefits can be brought to validation of IP addresses by placement of a Persistent DCV TXT Record within the reverse zone associated with an IP address.

  • The method provides a more direct proof of certificate issuance through IP address-associated reverse zones.
  • The method minimizes the need to make live record updates in reverse zones to complete validation of an IP address, which may be especially challenging due to the fact that IP address holders may not have direct access to the .arpa zone associated with their IP address.
  • We confirmed the feasibility of placement of non-PTR records in reverse zones, through consultation with several in-house DNS experts at Google and directly placing test records in an Unbound zonefile.

Benefits of adoption

For sunsetting the “Reverse Address Lookup” and creating 3.2.2.5.8, “DNS TXT Record with Persistent Value in the Reverse Namespace”:

• Improves validation processes by extending an existing DV method, 3.2.2.4.22 “DNS TXT Record with Persistent Value,” to the validation of IP addresses.

  • This ensures that CAs and subscribers can adopt uniform process and tooling for both domain and IP address validation via the Persistent DCV TXT value method, reducing complexity and the risk of inconsistent implementation.

• Promotes stronger validation integrity by ensuring that DV demonstrates a stronger binding to actual administrative control over an IP address, increasing the consistency of trustworthiness of issued certificates.

  • Reverse DNS zones (in-addr.arpa and ip6.arpa) are delegated by RIRs and LIRs in accordance with IP address block allocations. This makes the reverse namespace the authoritative DNS context for demonstrating control of IP addresses.
  • Direct DNS assertion through IP address-associated reverse zones is a stronger proof of control.
  • Publishing a TXT record at a validation specific-prefix directly demonstrates administrative control of the IP resource AS WELL AS request to issue.
  • Removes reliance on the correctness/freshness of PTR records and eliminates DV indirection through potentially unrelated domains.

• Improves security posture and reduces risk of improper certificate issuance by sunsetting a method that enables "crossover" attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.

  • The new method replaces the current allowance in 3.2.2.5.3 to use any domain validation method in 3.2.2.4 with a single, narrowly defined DNS-based method. This strengthens security by eliminating the "weakest link" problem, as the security of 3.2.2.5.3 was inherently bound to the security of the weakest validation method in 3.2.2.4.
  • Removes the possibility of “crossover” attacks introduced by tying validation of an IP address to validation of an unrelated domain in a stale PTR record.
  • Limits the validation challenge to direct DNS TXT queries in the .arpa zone, minimizing the attack surface to only DNS.

• Facilitates innovation by allowing automation without live DNS updates, supporting shortened certificate lifetimes and more agile re-issuance for IP address certificate subscribers. This is especially helpful because of the administrative burden often inherent in updating .arpa zones.

  • Creates opportunities for faster, more efficient certificate lifestyle management and simplification of maintenance of reverse zones.
  • Brings the improvements of 3.2.2.4.22 to validation of IP addresses.

• Promote stronger validation integrity by ensuring that DCV proves a stronger, more direct binding to actual administrative control over the reverse namespace associated with an IP address.

Proposed Key Dates:

The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.

• Effective immediately:

  • Implementation of 3.2.2.5.8 (“DNS TXT Record with Persistent Value in the Reverse Namespace”)

• Effective March 15, 2027:

  • Sunset of Method 3.2.2.5.3 (“Reverse Address Lookup”)