Discussion period begins: SC094: DNSSEC exception in email DCV methods

[Dimitris Zacharopoulos (HARICA)]

Summary: 

After discussions around DNSSEC enforcement [1] [2] for all Domain Validation methods, and with the WG's decision that the e-mail Domain Validation methods are scheduled to be deprecated (SC090), in order to reduce complexity and confusion around the way to enforce DNSSEC checks on the various email service agents, an exception to the DNSSEC enforcement is proposed for those methods. More information is available in this pull request.

[1]: https://groups.google.com/a/groups.cabforum.org/g/validation/c/zIKy6Qffw3w/m/qYDGYDQLBAAJ 

[2]: https://groups.google.com/a/groups.cabforum.org/g/servercert-wg/c/g4G7WF6uCHo/m/gX2Ek4S-BAAJ

[3]: https://groups.google.com/a/groups.cabforum.org/g/servercert-wg/c/226_yZ8Lp4c/m/9bJhRHGpAAAJ 

The following motion has been proposed by Dimitris Zacharopoulos (HARICA) and endorsed by Roman Fischer (SwissSign) and Adriano Santoni (Actalis).

--- 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.1.9.

MODIFY the Baseline Requirements as specified in the following Redline: https://github.com/cabforum/servercert/compare/d5ad450cc17ccd306ed87f790e1ef4f4ae5bfe22 .

--- Motion Ends ---

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

Discussion (at least 7 days)

• Start time: 2025-12-05 12:00:00 UTC
• End time: on or after 2025-12-12 12:00:00 UTC

Vote for approval (7 days)

• Start time: TBD
• End time: TBD

[Martijn Katerbarg]

Hi Dimitris,

Sorry for not sending this out sooner.  I’ve voiced concern with this proposal during the last F2F. Those haven’t changed, so I’ll outline them here during the discussion period, as well as some additional context.

Looking at the proposed language, I believe there’s a clash in the language, which renders the newly added SHOULD, pointless. Line 773 states:
“CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control.”

If any DNS query associated with DCV must utilize DNSSEC validation (if it’s not permitted to be disabled, it must be enabled), then how could a CA ever skip DNSSEC validation for certain record types?

 

With regards to the proposal itself, the following concerns were raised for leading to this ballot. Please see my comment for each concern:

• Building a feedback loop between DNSSEC validation and the mail delivery process would be operationally challenging. Without such a feedback channel, failed lookups result in undelivered email and support escalations.
• I’m unsure how this is problematic purely due to the DNSSEC verification requirement. Like I mentioned previously, DNSSEC verification is something done by the DNS resolver, not the mailserver. 
  The statement is correct in that DNSSEC validation failure could result in undelivered emails. However, I fail to see how this a new concern at this moment. 
  Email delivery failures is something that we’ve presumably all been dealing with for the last XX years. The new DNSSEC verification requirement does not suddenly introduce email delivery failure as a new concept. As such, if a CA is worried about needing to track and process email delivery failures, this should already be, and have been a concern, prior to the DNSSEC ballot. 
• Enforcing DNSSEC at this layer could make CAs responsible for diagnosing global DNS configuration problems.
• While true, and we also see our fair share of this, I fail to see how this will see any impact specifically due to email DCV. If DNSSEC verification would fail for an MX record lookup, the likelihood of it also failing for a CAA lookup on the same domain is very high. As such, I do not see how excluding MX records from the DNSSEC verification requirement would reduce the impact.
• Email-based DCV represents only a small portion of issuance volume.
• While I expect this is correct, as Toni already mentioned during the F2F: attackers focus on the weakest link, and this method could be exploited.
  If we leave one method less secure, the entire DNSSEC verification requirement is, frankly, pointless until these methods have been deprecated. I will add here that Email-based DCV is already the weakest link right now, as it has also been exempted from the MPIC requirements. 

Additionally, I would bring up that this carveout, may make the DCV process more complex for CAs. As it stands today, CAs are able to utilize a single DNS Resolver, with the same configuration, in order to satisfy the DNSSEC requirements. 

If a CA wants to scope out some DNS record types, only for specific DCV methods, then it seems the CA would need to setup new DNS Resolvers specifically for those DNS record lookups, leading to more complexity within the system itself. 

Regards,

Martijn

From: 'Dimitris Zacharopoulos (HARICA)' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Friday, 5 December 2025 at 12:53
To: CA/B Forum Server Certificate WG Public Discussion List <server...@groups.cabforum.org>
Subject: [Servercert-wg] Discussion period begins: SC094: DNSSEC exception in email DCV methods

This Message Is From an External Sender

This message came from outside your organization.

Report Suspicious

 

--
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/2b3b509a-7bc3-4a89-8759-4d79c65fde3e%40harica.gr.

[Mike Shaver]

On Fri, Dec 12, 2025 at 9:19 AM 'Martijn Katerbarg' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org> wrote:

Additionally, I would bring up that this carveout, may make the DCV process more complex for CAs. As it stands today, CAs are able to utilize a single DNS Resolver, with the same configuration, in order to satisfy the DNSSEC requirements. 

If a CA wants to scope out some DNS record types, only for specific DCV methods, then it seems the CA would need to setup new DNS Resolvers specifically for those DNS record lookups, leading to more complexity within the system itself. 

Hi Martijn,

First, I want to say that I very much share your concern about excepting email-based DCV from DNSSEC requirements, and I thank you for laying out the issues with the proposal so clearly.

I believe that the motivating case for the exception is a CA who does not operate the email infrastructure used for DCV, and therefore relies on another organization (or another part of the same organization, even) whose email infrastructure may or may not have capability for strict DNSSEC validation. In that scenario, there is no complication to be added via the ballot: such CAs are already using another non-validating resolver for email and do not wish to make the necessary investment to repair the security hole that it represents in, as you say, an already-weak DCV method.

I personally believe that CAs who do not wish to properly secure the DNS resolution used by email DCV—even with the existing carve-out for MPIC—should stop offering email DCV instead. The convenience of a small minority of subscribers (or the convenience of the CAs serving them, I suppose) should not outweigh the goal of properly securing DCV, and there are many more options for other DCV methods than there were when email was introduced. CAB/F would likely not introduce email DCV today if it were proposed, and I hope would *certainly* not do so in a way that ignored DNSSEC validation.

If the sunsetting of email validation is “too soon” for it to be worthwhile for CAs to secure their email practices, then I submit that it’s “soon enough” that CAs can sunset their own email practices earlier should they not be willing to honour the DNSSEC requirements of the BRs.

Mike

[Martijn Katerbarg]

Hi Mike,

>lies on another organization (or another part of the same organization, even) whose email infrastructure may or may not have capability for strict DNSSEC validation.

I can see the potential for the case within parenthesis. But just to note, utilizing another organization for email infrastructure (specifically, the email infrastructure responsible for sending DCV emails), would (IMHO) be utilizing a Delegated Third Party for the purpose of DCV, which is not allowed. 

Regards,

Martijn

From: 'Mike Shaver' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Friday, 12 December 2025 at 16:09
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: Re: [Servercert-wg] Discussion period begins: SC094: DNSSEC exception in email DCV methods

This Message Is From an External Sender

This message came from outside your organization.

Report Suspicious

 

--
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/CANx79dQL%2Bui%3DQ9s9Pw8mT-QGKzpPKGn8W3btmFPqm1q6TjJ_Yg%40mail.gmail.com.

[Dimitris Zacharopoulos (HARICA)]

On 12/12/2025 4:19 PM, 'Martijn Katerbarg' via Server Certificate WG (CA/B Forum) wrote:

Hi Dimitris,

Sorry for not sending this out sooner.  I’ve voiced concern with this proposal during the last F2F. Those haven’t changed, so I’ll outline them here during the discussion period, as well as some additional context.

Looking at the proposed language, I believe there’s a clash in the language, which renders the newly added SHOULD, pointless. Line 773 states:
“CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control.”

If any DNS query associated with DCV must utilize DNSSEC validation (if it’s not permitted to be disabled, it must be enabled), then how could a CA ever skip DNSSEC validation for certain record types?

 

Hi Martijn,

That's a good point. I considered the entire paragraph as a combined text but I can see how it can be interpreted under a "strict reading". The intent was to require DNSSEC for the cases of CNAME, CAA and TXT queries to address Aaron's concern (about possible delegations) but not for the mail service itself. As discussed, it is very likely that a CA has a different infrastructure for handling the CA/RA operations and a separate one for the mail service. Some CAs even outsource the mail service to third-parties, as mentioned in those previous discussions. We may disagree about this being allowed or not and where the line is drawn, but the general understanding is that the management of a mail system extends beyond the scope of "CA Operations" and usually serves an entire organization (or organizations within an organization). 

So, to answer your question, the CA could force DNSSEC validation in a local resolver used for CNAME, CAA, TXT and any other query, closely tied with the "CA operations" (CAA checks and non-email DCV methods), and the mail service could use a different resolver that does not validate DNSSEC because that would have a significant impact on the delivery of emails outside the scope of DCV. 

In any case, I will try to propose some language to address this "MUST NOT" conflict (happy to accept contributions :) .

With regards to the proposal itself, the following concerns were raised for leading to this ballot. Please see my comment for each concern:

• Building a feedback loop between DNSSEC validation and the mail delivery process would be operationally challenging. Without such a feedback channel, failed lookups result in undelivered email and support escalations.
• I’m unsure how this is problematic purely due to the DNSSEC verification requirement. Like I mentioned previously, DNSSEC verification is something done by the DNS resolver, not the mailserver. 
  The statement is correct in that DNSSEC validation failure could result in undelivered emails. However, I fail to see how this a new concern at this moment. 
  Email delivery failures is something that we’ve presumably all been dealing with for the last XX years. The new DNSSEC verification requirement does not suddenly introduce email delivery failure as a new concept. As such, if a CA is worried about needing to track and process email delivery failures, this should already be, and have been a concern, prior to the DNSSEC ballot. 
• Enforcing DNSSEC at this layer could make CAs responsible for diagnosing global DNS configuration problems.
• While true, and we also see our fair share of this, I fail to see how this will see any impact specifically due to email DCV. If DNSSEC verification would fail for an MX record lookup, the likelihood of it also failing for a CAA lookup on the same domain is very high. As such, I do not see how excluding MX records from the DNSSEC verification requirement would reduce the impact.
• Email-based DCV represents only a small portion of issuance volume.
• While I expect this is correct, as Toni already mentioned during the F2F: attackers focus on the weakest link, and this method could be exploited.
  If we leave one method less secure, the entire DNSSEC verification requirement is, frankly, pointless until these methods have been deprecated. I will add here that Email-based DCV is already the weakest link right now, as it has also been exempted from the MPIC requirements. 

Forcing DNSSEC validation to a mail service that affects an entire organization is IMHO not a balanced approach to the security risks that led to the DNSSEC enforcement and the phased-out deprecation of the email validation methods. Henry's post summarizes the intent and the balance of this ballot very accurately IMO.

Additionally, I would bring up that this carveout, may make the DCV process more complex for CAs. As it stands today, CAs are able to utilize a single DNS Resolver, with the same configuration, in order to satisfy the DNSSEC requirements. 

If a CA wants to scope out some DNS record types, only for specific DCV methods, then it seems the CA would need to setup new DNS Resolvers specifically for those DNS record lookups, leading to more complexity within the system itself. 

As explained earlier, this is not adding complexity, on the contrary it allows the option for a CA to maintain separate DNS resolver configurations between the "CA operations" and the "Mail services" which is an entire ecosystem of its own and extends beyond the scope of "CA/RA Operations". IMHO requiring a CA to implement, manage and support an entire separate mail service just for sending emails to Applicants, for a phased-out set of methods, seems quite more complex.


Best regards,
Dimitris.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/SA1PR17MB6503EA958C6EB59C6D190BA6E3AEA%40SA1PR17MB6503.namprd17.prod.outlook.com.

[Dimitris Zacharopoulos (HARICA)]

Hi Mike,

As noted in previous discussions, during the DNSSEC-enforcement ballot the group did not address how the changes would affect the email-based DCV methods. Had this issue been identified during the discussion of SC085, CAs may have taken a different position. Unfortunately, it was raised only after the ballot had passed, making this a typical example of an “unintended consequence” that the group has historically and collectively sought to address. By way of comparison, the NetSec Working Group has recently conducted several consecutive ballots to remediate unintended consequences and was able to complete that work through good faith and collaborative effort.

Historically, even members holding opposing views have acknowledged unintended consequences and worked constructively to find balanced solutions. Dismissing such consequences is risky and inconsistent with the collaborative approach this group strives to maintain. Put differently, ballot SC085 never intended to make email DCV methods obsolete and it did not reveal the fact that an entire mail service system would  have to force DNSSEC validation. 

Email-validation methods are also very much used by Subscribers. These Subscribers have already been informed (or will be informed soon enough) that the email-validation methods are being deprecated. So there will be a positive security change to the ecosystem, and time for subscribers to change their processes and tools. There is no identified "immediate risk" or "security flaw" in the email-validation methods, which is why the group has agreed to a 3-year phase-out period (March 15, 2028). Let's not use the DNSSEC ballot as a tool to force CAs that have separate mail infrastructure to stop validation methods actively used by their Subscribers, sooner than expected.

I will not reiterate points already discussed regarding the Delegated Third Party issue or where the boundaries are drawn. This work was intended to be undertaken by the Validation Subcommittee through a method-by-method examination of Domain Validation, considering implementation details, dependencies, and real-world scenarios using a risk-based approach. I am unsure of the current status of that effort, but without a focused discussion of each individual method, I do not believe consensus can be achieved.


Best regards.
Dimitris.

Mike

--
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/CANx79dQL%2Bui%3DQ9s9Pw8mT-QGKzpPKGn8W3btmFPqm1q6TjJ_Yg%40mail.gmail.com.

[Dimitris Zacharopoulos (HARICA)]

On 12/13/2025 11:07 AM, 'Dimitris Zacharopoulos (HARICA)' via Server Certificate WG (CA/B Forum) wrote:

On 12/12/2025 4:19 PM, 'Martijn Katerbarg' via Server Certificate WG (CA/B Forum) wrote:

Hi Dimitris,

Sorry for not sending this out sooner.  I’ve voiced concern with this proposal during the last F2F. Those haven’t changed, so I’ll outline them here during the discussion period, as well as some additional context.

Looking at the proposed language, I believe there’s a clash in the language, which renders the newly added SHOULD, pointless. Line 773 states:
“CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control.”

If any DNS query associated with DCV must utilize DNSSEC validation (if it’s not permitted to be disabled, it must be enabled), then how could a CA ever skip DNSSEC validation for certain record types?

 

Hi Martijn,

That's a good point. I considered the entire paragraph as a combined text but I can see how it can be interpreted under a "strict reading". The intent was to require DNSSEC for the cases of CNAME, CAA and TXT queries to address Aaron's concern (about possible delegations) but not for the mail service itself. As discussed, it is very likely that a CA has a different infrastructure for handling the CA/RA operations and a separate one for the mail service. Some CAs even outsource the mail service to third-parties, as mentioned in those previous discussions. We may disagree about this being allowed or not and where the line is drawn, but the general understanding is that the management of a mail system extends beyond the scope of "CA Operations" and usually serves an entire organization (or organizations within an organization). 

So, to answer your question, the CA could force DNSSEC validation in a local resolver used for CNAME, CAA, TXT and any other query, closely tied with the "CA operations" (CAA checks and non-email DCV methods), and the mail service could use a different resolver that does not validate DNSSEC because that would have a significant impact on the delivery of emails outside the scope of DCV. 

In any case, I will try to propose some language to address this "MUST NOT" conflict (happy to accept contributions :) .

I reworded the section to ensure that DNSSEC validation MUST NOT be disabled for non-email DCV methods, nor for DNS CNAME, CAA, and TXT queries associated with email DCV methods. For the remaining DNS queries associated with non-email DCV methods, the requirement was relaxed so that disabling DNSSEC is now a SHOULD NOT.

https://github.com/cabforum/servercert/commit/a9f40a597e45605e499bc73a64aaa1d607bd5b0a

I hope this addresses at least the inconsistency issue. Please let me know if any further wordsmithing is needed.


Thank you,
Dimitris.