Discussion Period Begins - Ballot SC-90: "Gradually sunset all remaining email-based, phone-based, and ‘crossover’ validation methods from Sections 3.2.2.4 and 3.2.2.5"
Ryan Dickson
[A "doc" formatted version of this preamble is available here.]
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 ability for email-based DCV methods to reliably satisfy DNSSEC checking expectations introduced by SC-085 is unclear, further emphasizing these methods as a “weak link.” Because of this concern, this ballot discourages use of email-based methods beginning the effective date of SC-085 (March 15, 2026).
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., ad...@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 SC-091.
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:
Sunset method 3.2.2.4.8 (“IP Address”)
Discourage use of email and phone-based methods.
Effective March 15, 2027:
Sunset method 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
Sunset method 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
Sunset method 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
Sunset method 3.2.2.5.5 ("Phone Contact with IP Address Contact")
Effective March 15, 2028:
Sunset method 3.2.2.4.4 ("Constructed Email to Domain Contact")
Sunset method 3.2.2.4.13 ("Email to DNS CAA Contact")
Sunset method 3.2.2.4.14 ("Email to DNS TXT Contact")
Proposal Revision History:
Version #1 (this version)
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:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 14 days)
Start: 2025-10-24 11:15:00 ET
End no earlier than: 2025-11-07 11:15:00 ET
Note: Due to ongoing discussion periods for SC-091 and SC-086 (V2), we are intentionally signalling an extended discussion period. However, we feel it’s important community members can evaluate the comprehensive set of changes proposed across Sections 3.2.2.4 and 3.2.2.5 introduced by all of the in-progress ballots, and are therefore starting this discussion period to raise attention to these proposed changes, which are also referenced by SC-091.
Vote for approval (7 days)
Start: TBD
End: TBD
Mark Gamache
Sent: Friday, October 24, 2025 8:14 AM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: [Servercert-wg] Discussion Period Begins - Ballot SC-90: "Gradually sunset all remaining email-based, phone-based, and ‘crossover’ validation methods from Sections 3.2.2.4 and 3.2.2.5"
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/CADEW5O8_FmTkM5N9HaZac242w_QKZWXnovcg6KjNRYLaS1YSpw%40mail.gmail.com.
Chris Clements
Hi Mark,
We appreciate you sharing your perspective.
The foundational issue, as we see it, is that risk must be evaluated from the perspective of the public relying party, not just the individual certificate subscriber. Every TLS certificate issued under the scope of the minimum requirements that are the CA/Browser Forum TLS BRs extends a chain of trust to billions of endpoints. A weak DCV method doesn’t just endanger one brand; it endangers the credibility of the entire model. The option to “take that risk” doesn’t seem appropriate when the externalities affect the public.
Email introduces its own unbounded set of weaknesses: MX misconfigurations, supply-chain compromises, STARTTLS downgrades, mailbox hijacks, and provider breaches. Several examples of these weaknesses are listed in the ballot’s justification, and other recent conversations in this working group continue to highlight email-based DCV as being a weakest link. We also note that email-based validation is not aligned with the forward-looking security controls being developed to protect the ecosystem. While improvements like DNSSEC and MPIC are raising the security floor for DNS-based challenges, their benefits are not consistently or fully extended to email. Retaining these email methods means knowingly accepting a control that has no current path for improvement, creating risk that will only become more dangerous over time.
We acknowledge the operational challenges large organizations might face when migrating established processes (and that small and medium-sized businesses have challenges too). However, these challenges shouldn’t stop progress in security. Instead, the solution is to manage that transition effectively by providing distant timelines, like the multi-year proposal here, and encouraging more verifiable and automated control proofs, like the recently passed Ballot SC-088.
This follows a well-established and successful pattern for this working group. We progressively strengthen the ecosystem by sunsetting vulnerable or outdated methods while simultaneously introducing modern, more secure alternatives. The group did this when deprecating TLS-SNI-01 in Ballot SC-033 and again with the WHOIS-based methods in Ballot SC-80. In their place, ballots like SC-088 and the proposed SC-91 encourage greater automation, streamline certificate lifecycle management for shorter-lived certificates, and improve security for all relying parties.
Ultimately, we find it less compelling for email-based validation methods to persist for fallback convenience when they also:
do not offer the stronger security assurances provided by the existing alternative methods currently detailed in the TLS BRs
represent an expanded attack surface to publicly-trusted TLS certificate issuance when compared to existing alternatives
inherit vulnerabilities from the underlying communication channels and associated service providers
represent a weaker binding to domain/IP control than existing alternatives
Again, thank you for sharing your perspective.
-Chris
Mark Gamache
Sent: Monday, November 3, 2025 8:33 AM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: Re: [Servercert-wg] Discussion Period Begins - Ballot SC-90: "Gradually sunset all remaining email-based, phone-based, and ‘crossover’ validation methods from Sections 3.2.2.4 and 3.2.2.5"
