3 ms·
I'm surprised that this doesn't require DNSSEC or at the very least actively encourage configuring DNSSEC. While I used to be fully in the camp that DNSSEC was
by solatic 8mo ago
I'm surprised that this doesn't require DNSSEC or at the very least actively encourage configuring DNSSEC. While I used to be fully in the camp that DNSSEC was way more trouble than it was worth, in particular when access was de-facto secured by trusted CA certificates, more and more DNS record types (CAA, CERT, SSHFP, these TXT records) are responsible for storing information that can be manipulated in MITM attacks to seize control of a root of trust.
Of course, this has little applicability to anyone who is small enough not to have nation-state level actors in their threat model. But when I look behind the curtain of even Fortune 100 companies that really ought to have nation-state level actors in their threat model, too often you find people who are just not operating at that level or are swamped with unrelated work. So I'm starting to become of the opinion that guidance should change here and at the very least be documented recommendations - if it's not encouraged down the organizational size scale, too often it's not applied further up where it's needed.
- ajnin 8mo agoDNSSEC is encouraged ("SHOULD" wording) in the RFC draft : https://datatracker.ietf.org/doc/html/draft-ietf-acme-dns-persist-00#name-dnssec https://datatracker.ietf.org/doc/html/draft-ietf-acme-dns-pe...
- solatic 8mo agoThe RFC wording is a little weird. If the zone has DNSSEC configured, then the wording should be stronger and use MUST wording, and not imply that CAs will be compliant if they choose to avoid verifying signatures despite the presence of signstures. Likewise, these TXT records for dns-persist-01 ideally "SHOULD NOT" be deployed when DNSSEC is not configured.
- pepdar 8mo agoAn open PR on the draft (#35) adds exactly this language: if a CA performs DNSSEC validation and it fails (expired signatures, broken chain of trust), the CA MUST treat it as a challenge failure and MUST NOT use the record. The rationale is that dns-persist-01 records are long-lived, so a DNSSEC failure has more severe consequences than it would for a transient challenge.
- paulnpace 8mo agoWhen it comes to DNSSEC, I wish it were TLSA, but for whatever reason that was pretty much not supported anywhere, most notably by browsers.
- Ajedi32 8mo agoDNS has always been a single-point-of-failure for TLS cert issuance. The threat is real, but not at all unique to this validation method. (For example, an attacker with control of DNS could switch the A record to their server and use that to pass HTTP-01 or TLS-ALPN-01 validation, or update the _acme-challenge TXT record and use that to pass DNS-01.)
- redleader55 8mo agoWhile this is true, improvements in the TLS issuance process should also improve security. When the eventual deprecation of TLS-ALPN-01 and DNS-01 comes, this new method would be completely secure. Here, the record could for example contain a signature from the same key pair used to authenticate the account. The alternative is DNSSEC, but that's avoided by a lot of domains.