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?

  • Previously I'd thought there was a bit of elegance in the two-trust-chain model; no matter how abysmal the (loosely used words, but) "trust chain" powering the DNS infrastructure, you at least have to break (either IP or) it, and spoof the TLS; whereas Unifying it seems to have turned what was previously a single-point-to-DoS (that admittedly had springboard implications) into a full-on single-point-to-compromise-all-confidentiality – JamesTheAwesomeDude Dec 1 '18 at 0:00
  • (and I guess it would be a significantly reduced issue if SRV records were more well-supported: since you could have _http2._tcp.example.com pointing at www1.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 for server authenticating a ZSK stored warmly on an extremely-well-secured server which had an/various interfaces for performing mundane maintenance) – JamesTheAwesomeDude Dec 1 '18 at 0:07
  • " if there's a way to define ZSKs which do NOT have the authority to generate any RRSIGs for TLSA records.". No a ZSK is expected to be used to sign all records (this is why they are called Zone Signing Keys and not Records Signing Keys). However validators are happy as long as they find one valid path, so if a given KSK signs 2 ZSKs and one ZSK signs some records and the other other records, it might work but this is certainly an edge case and I won't rely on something like that without extensive on the field experiments first. – Patrick Mevzek Apr 11 '19 at 5:59
  • @PatrickMevzek re:"one ZSK signs some records and the other other records", what would be the purpose of that? Just because I reserve a specific ZSK for signing TLSA records doesn't mean that an attacker compromising the one I use for routine A/AAAA/TXT updates would be impeded in any way from using [the latter key] to sign TLSA records. – JamesTheAwesomeDude Aug 1 '19 at 14:38
  • 1
    Another way to view it (maybe): through CNAMEs, put all your TLSA 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. – Patrick Mevzek Aug 1 '19 at 14:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.