SC-090: "Gradually sunset all remaining email-based, phone-based, and ‘crossover’ validation methods from Sections 3.2.2.4 and 3.2.2.5"

[ryancdickson]

Notes:

• As of 09 September 2025, this proposal is not yet in discussion. This PR is being opened to offer greater visibility re: the proposed changes and corresponding implementation schedule.
• For the most up to date version, see this doc.

---

Purpose of Ballot SC-90:

This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to gradually sunset (1) all remaining email and phone-based domain and IP address validation methods from Sections 3.2.2.4 and 3.2.2.5 and (2) a validation method that enables “crossover” attacks as described by Henry Birge-Lee during the 24 July 2025 Validation Subcommittee Meeting.

Background:

Scope:

The following validation methods are proposed for a gradual sunset:

Methods relying on email and phone:

• 3.2.2.4.4 ("Constructed Email to Domain Contact")
• 3.2.2.4.13 ("Email to DNS CAA Contact")
• 3.2.2.4.14 ("Email to DNS TXT Contact")
• 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
• 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
• 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
• 3.2.2.5.5 ("Phone Contact with IP Address Contact")

Method that enable crossover attacks:

• 3.2.2.4.8 (“IP Address”)

Justification

For sunsetting email and phone-based methods:

• The in-scope methods do not offer the stronger security assurances provided by the existing alternative methods currently detailed in the TLS BRs.
  • For example, while MPIC (Ballot SC-067) can be applied to DNS lookups for email addresses sourced from DNS (e.g., Methods 3.2.2.4.13, 3.2.2.4.14), it does not prevent fraudulent issuance if the MX server's IP or its DNS resolution is hijacked, as the MX server address itself is not part of the MPIC lookup for the domain contact.
    • An attacker could perform a BGP hijack of the victim's MX server IP or its DNS resolution, serve the legitimate victim email address (which passes MPIC for the contact lookup), and still intercept the validation email.
    • Similar attacks can target constructed email methods by hijacking the MX server.
  • Though applying MPIC to MX record lookups would be an improvement to help protect against DNS-based attacks affecting email routing, but it would not protect against in-transit hijacks (e.g., vulnerabilities in SMTP traffic itself like opportunistic TLS downgrades) or post-mail-server delivery compromises (e.g., an attacker gaining unauthorized access to the recipient's mailbox via POP3/IMAP).
  • Requiring multiple challenges to be sent from multiple addresses could also be considered a security improvement, but would likely work against agility goals and is expected to be undesirable due to subscriber inconvenience.
• The in-scope methods represent an expanded attack surface to publicly-trusted TLS certificate issuance when compared to existing alternatives.
  • These methods broaden the attack surface compared to “direct” validation methods like DNS TXT records or HTTP file challenges.
  • Email validation involves a more complex chain of operations, including MX record lookups and resolution of mail server addresses, potentially involving third-party mail providers and their DNS infrastructure. Additional participants in the validation process should be seen as added risk.
  • Using DNS TXT or CAA records to find a contact email address can introduce further DNS queries, each an additional vector for attack.
  • Compromise at any point in this extended chain can lead to fraudulent certificate issuance. Direct DNS or HTTP challenges confine the attack surface primarily to the validated domain.
  • Audits don’t meaningfully or completely evaluate the security of these services, even considering elements hosted directly by the CA subject to the audit’s scope, further calling into question their reliability.
• The in-scope methods inherit vulnerabilities from the underlying communication channels and associated service providers.
  • The compromise of an email service provider (private or public), could potentially grant attackers access to any number of fraudulently issued certificates due to no fault of a CA Owner or subscriber.
  • There are numerous examples of large-scale attacks on such services and providers. These attacks should be considered as becoming more prevalent, not less.
  • It is also broadly understood by security professionals that many successful attacks are never publicly disclosed or may go undetected for considerable periods. This established pattern of attacks, combined with the strong and persistent motivations for adversaries to target email systems, makes the continued use of email-based DCV a concern for maintaining the security and integrity of the ecosystem.
  • Email relies on opportunistic TLS and is susceptible to downgrade. Phone systems share similar inherent vulnerabilities like SIM Swapping and SS7 attacks (example).
  • As evidenced in the WatchTowr report that motivated the sunset of methods relying on domain contact information via SC-080, vulnerabilities in these communication channels or associated service providers represent significant and convenient collateral impact.
• The in-scope methods represent a weaker binding to domain/IP control than existing alternatives.
  • Email and phone-based DCV methods exhibit a "weak binding" as they only demonstrate that an applicant can interact with a communication medium associated with the domain, not necessarily direct administrative control over the domain's core infrastructure.
  • Read access to an email inbox (e.g., admin@example.com) or a phone number does not inherently equate to comprehensive control over DNS configuration, web server content, or policy authority for the domain.
  • Email accounts are susceptible to compromise, unauthorized and unintended delegation, or mismanagement independently of the domain's core operational control.
• We presently have DCV methods (e.g., ACME-based DNS or HTTP challenges) that offer greater automation, scalability, security, and better align with subscriber agility needs, especially when considering decreasing certificate lifetimes. Similarly, the SCWG continues to develop new DCV methods that promote automation, agility, and subscriber convenience (e.g., SC-088).

For sunsetting methods that could be used in “crossover” attacks:

• The in-scope methods allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
• While the original scope of this ballot included a sunset for 3.2.2.5.3 (“Reverse Address Lookup”), it is instead planned for sunset in a later proposal that will also add another DNS-based approach similar to the static methods described in SC-088.

Benefits of adoption:

• Elevate overall security posture by directly addressing the "Weakest Link Principle" in our domain validation security chain, ensuring attackers cannot leverage less secure methods to compromise certificate issuance. So long as these inherently less secure and more susceptible methods remain available, they present a persistent, exploitable target for adversaries.
• Reduce 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.
• Promote stronger validation integrity by ensuring that DCV relies on methods with a stronger binding to actual administrative control over a domain or IP address, increasing the consistency of trustworthiness of issued certificates.
• Simplify the threat space by removing phone and email-based DCV, which eliminates unnecessary dependencies on large and complex ecosystems with inherent challenges, risks and vulnerabilities.
• Increase agility by encouraging site owners to transition to modern DCV methods, creating opportunities for faster and more efficient certificate lifecycle management through automation.
• Create opportunities for innovation by promoting the development of new and improved DCV methods, fostering advancements that may further enhance the overall security and agility of the ecosystem.
• Promote simplicity by streamlining the list of approved DCV methods in the TLS BRs, reducing complexity for CAs, developers, auditors, and subscribers.

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 March 15, 2026:
  • 3.2.2.4.8 (“IP Address”)
• Effective March 15, 2027:
  • Method 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
  • Method 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
  • Method 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
  • Method 3.2.2.5.5 ("Phone Contact with IP Address Contact")
• Effective March 15, 2028:
  • Method 3.2.2.4.4 ("Constructed Email to Domain Contact")
  • Method 3.2.2.4.13 ("Email to DNS CAA Contact")
  • Method 3.2.2.4.14 ("Email to DNS TXT Contact")

Proposal Revision History:

• Pre-Ballot Version 1 (this version)
• Version 1 Ballot and discussion (tbd)

The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Ben Wilson (Mozilla) and Tim Callan (Sectigo).

— Motion Begins —

This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.X.X.

MODIFY the Baseline Requirements as specified in the following Redline:

https://github.com/cabforum/servercert/compare/e9176e15805a2f7908411a22a40047b655fa24c4..587e973d017e55f374e24b60628476b33178b6fa

— Motion Ends —

This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:

Discussion (no less than 7 days)

• Start: 2025-XX-XX 20:00:00 ET
• End no earlier than: 2025-XX-XX 20:00:00 ET

Vote for approval (7 days)

• Start: TBD
• End: TBD

[ganeshmallaya]

This is a good ballot towards tightening the security around issuance. I would like to propose few edits to the language

This method has been retired and MUST NOT be used. On and after the Effective Date, the CA SHALL NOT (i) initiate, (ii) complete, or (iii) rely upon any validation, Random Value, or “pending order” initiated under this method, regardless of any reuse windows in Section 4.2.1. Validation data from this method SHALL NOT be used to issue or reissue Certificates after the Effective Date.

[ryancdickson]

@ganeshmallaya - thanks for your feedback!

I'm having trouble understanding how the proposed is not addressed by the current text, which relies on preexisting phrasing used for past sunsets and is presently included in the TLS BRs.

For example, looking at Section 3.2.2.4.16 (Phone Contact with DNS TXT Record Phone Contact) the proposed language states:

Effective March 15, 2027:
- The CA MUST NOT rely on this method.
- Prior validations using this method and validation data gathered according to this method MUST NOT be used to issue Subscriber Certificates.

The above boils down to CAs not being able to perform the following beginning March 15, 2027:

1. rely on this Method for issuing new certificates.
2. issue a certificate relying on the reuse of data originally gathered using the corresponding Method prior to the sunset to issue a new certificate.

Can you help me better understand whether the specific scenarios you described (e.g., use in a "pending order") are not already covered?