Non-TLS-authoritative ZSKs?

Question

Under DANE, the digital chain of trust goes (roughly):

• [Public visibility of the ceremony for the generation of the]
• ICANN Root Zone Key, which
• something something involving the TLD authorities and registrars, which culminates in validation of the
• DS Record which lists the domain's authorized
• KSK, [which may certify other,
• intermediate KSKs,] which certify/ies authorized
• ZSKs, which are used to produce
• RRSIGs on the
• TLSA Records containing the fingerprint of the
• TLS key which the server (certifies • ephemeral keys with; which it then) uses to encrypt communications.

Now, normally, (that is, pre-DANE,) if your main DNS server gets hijacked, this still isn't (yet) an unqualified "game over", as far as SSL is concerned: since there's still the issue (assuming HSTS) of getting a certificate matching the domain (and given OCSP, HPKP, etc, this is thankfully at least slightly nontrivial.)

However, for a browser or other client which actually implements DANE for positive authentication (that is, in the absence of a trusted-authority-anchored x509 certificate sequence), doesn't this mean that any access to publish new DNS records now allows complete and immediate destruction/spoofing of—not just access to, but, now—authenticity of all affected servers?

So what I am asking is if there's a way to define ZSKs which do NOT have the authority to generate any RRSIGs for TLSA records.

I would like to keep anything which is capable of directly certifying new TLS certificates (TLSA-signing keys, intermediate CAs' private keys, etc.) under cold storage and do all issuances/renewals in an offline/airgapped manner; while I will very likely need to commission more frequent updates to A/AAAA/SRV/TXT/other records.

Or am I stuck with having to secure a simple DDNS update infrastructure as if all my domains' HTTPS directly and immediately depended on it?

Answer 1

1. The proposed threat model lacks credibility. If your DNS server is sufficiently compromised, an attacker can immediately obtain certificates from e.g. Let's Encrypt.
2. Of course you can also operate a hidden master that's tightly locked down, and offers a much smaller attack surface than the web servers whose security you're trying to protect.
   • The various public DNS servers just serve secondary copies of a pre-signed zone, and can't generate any signed TLSA records.
3. Unlike certificates issued by WebPKI CAs, where revocation works poorly, you can "revoke" unauthorised TLSA records promptly, once you regain control over your DNS servers.
4. Nobody does HPKP, it is deprecated and abandoned. OCSP is entirely optional, and rarely used.
5. Presently, none of the web browsers support DANE.

But supposing somehow that the threat model makes sense, and browsers support DANE, and your DNS signing keys are exposed more than the web servers you're concerned about, ... then if their names are in a DNSSEC-signed zone the DNSKEYs of that zone can indeed sign TLSA records. There's no flavour of ZSK that can only sign data you don't care about. However, as noted above the ZSK private key need not be present on any of the visible DNS servers of the zone (unless you're doing online signing a la CloudFlare).

Answer 2

Let's say you have example.net run off a DNS server that is secure, DNSSEC-enabled for records directly on it, but cumbersome to update. Subdomain dynamic.example.net is run off a server that is easy to update records on, but is intentionally insecure per RFC 7672 §2.1.1 — in this case, securely delegated to 3rd-party DDNS host example.org.

I would like to keep anything which is capable of directly certifying new TLS certificates (TLSA-signing keys, intermediate CAs' private keys, etc.) under cold storage and do all issuances/renewals in an offline/airgapped manner; while I will very likely need to commission more frequent updates to A/AAAA/SRV/TXT/other records.

Simply use a CNAME record to point www.example.net at an unsigned record on dynamic.example.com!

; example.net. (secure zone)

dynamic IN      NS      d-ns1.example.org
dynamic IN      NS      d-ns2.example.org
dynamic IN      DS      . ; return NXDOMAIN

www     IN      CNAME   us-east-1.dynamic
www     IN      RRSIG   CNAME 15 3 …

---

Bonus: If you want to deploy DANE yourself while still witholding DANE-authority from the DDNS host, this is provisioned for:

[if the] input domain is a CNAME alias, but the ultimate network address RRset is "insecure"[,] a search is performed for a TLSA record with the original input domain as the candidate TLSA base domain.

…

www     IN      CNAME   us-east-1.dynamic
www     IN      RRSIG   CNAME 15 3 …

_443._tcp.www IN TLSA   2 1 1 …
_443._tcp.www IN RRSIG  TLSA 15 3 …

In this case, the "input domain" would be www.example.net, and the "[insecure] ultimate network address RRset" would be the A/AAAA records associated with us-east-1.dynamic.example.net, so the TLSA search would be bounced back to www so long as IN DS dynamic.example.net. securely returns NXDOMAIN.

(h/t Patrick Mevzek for this brainwave)

---

See also IETF's upcoming SRV-a-like records for HTTPS, which may become another option / an alternative to CNAME for administratively breaking the DANE chain when you need TLSA-A trust separation.