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?
_http2._tcp.example.com
pointing atwww1.us.servers.example.com
, where the root KSK could still be kept on an HSM in a safe deposit box, after signing a few records including TLSA records, and a DS forserver
authenticating a ZSK stored warmly on an extremely-well-secured server which had an/various interfaces for performing mundane maintenance)CNAME
s, put all yourTLSA
records in some separate and delegated zone, so that keys there used to sign those records, are not the keys used to sign the rest of your zone.