Hi Swapneel, Thank you for your supportive feedback and for the recommendation regarding DNSSEC treatment.
We appreciate the distinction you've highlighted, and we personally value DNSSEC's security properties. However, after discussion between our co-authors, we believe that requiring DNSSEC validation—even in the form of "MUST use a DNSSEC validating resolver"—would encumber this specification in ways that limit its practical utility. As discussed in https://github.com/sheurich/draft-sheurich-acme-dns-persist/issues/1, our primary concerns are: 1. Flexibility for diverse implementations: While requiring a validating resolver doesn't mandate DNSSEC deployment by domain owners, it does impose infrastructure requirements on CAs. Many private PKI deployments and internal environments use DNS infrastructure that may not have DNSSEC deployed or where DNSSEC validation infrastructure may not be practical to implement. 2. Uncertain long-term trajectory: As DNSSEC's future role in DNS security continues to evolve, we prefer not to mandate specific infrastructure choices that might become less relevant. 3. Defense in depth: We believe the combination of account binding, multi-perspective validation (Section 7.7.2), and other security measures provides robust protection even without mandatory DNSSEC validation. Our current approach in Section 7.7.1 ("DNSSEC signatures SHOULD be validated") encourages DNSSEC validation where practical while preserving the flexibility needed for diverse deployment contexts. We believe this strikes the right balance for this specification. We remain open to discussing this further with the working group if there's strong consensus for change, but wanted to clarify our current position. Thank you again for the reference to draft-sheth-identifiers-dns and for your engagement on improving this specification. Best regards, Shiloh > On Oct 10, 2025, at 12:03, Sheth, Swapneel <[email protected]> wrote: > > As authors of draft-sheth-identifiers-dns (included as an informative > reference in draft-sheurich-acme-dns-persist), we are supportive of seeing > this draft be adopted as it can help address challenges of using > non-persistent approaches we see today. > > One change we recommend would be to align the treatment of DNSSEC in this > draft with the upcoming changes to > draft-ietf-dnsop-domain-verification-techniques (DCV BCP) specified in > https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/pull/188/files. > Any future version of draft-sheth-identifiers-dns will also align with this > change. > > Adopting such language would change 7.7.1 of this draft from SHOULD validate > DNSSEC signatures to a MUST use a DNSSEC validating resolver. From our > perspective, it is important that if a domain name has opted to use DNSSEC > that it continues to be protected by the security properties of DNSSEC. The > cited text would not prevent non-DNSSEC enabled domain names from using > dns-persist-01 or using multi-perspective validation as currently specified. > > Thanks! > Swapneel Sheth > > >> From: Mike Ounsworth <[email protected] <mailto:[email protected]>> >> Sent: Friday, September 26, 2025 11:13 AM >> To: IETF ACME <[email protected] <mailto:[email protected]>> >> Subject: [EXTERNAL] [Acme] Call-for-Adoption for >> draft-sheurich-acme-dns-persist >> >> Caution: This email originated from outside the organization. Do not click >> links or open attachments unless you recognize the sender and know the >> content is safe. >> Hi ACME! >> >> This thread begins a two-week Call-for-Adoption for >> draft-sheurich-acme-dns-persist, which will end 2025-10-10. >> >> Please speak for or against adopting this document as a working group item. >> >> -Mike >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
