2

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?

JamesTheAwesomeDude
  • 700
  • 6
  • 18
  • 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 01 '18 at 00: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 01 '18 at 00: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 05: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 01 '19 at 14:38
  • See model 2 in https://www.ietf.org/id/draft-ietf-dnsop-multi-provider-dnssec-03.txt : in a multi signer model, there may be separate ZSKs in the zone, so depending on which nameservers you query, a given recursive nameserver could have some records signed by one ZSK and some other signed by another. This could as well happen during a period of time where you are changing your ZSKs... – Patrick Mevzek Aug 01 '19 at 14:43
  • 2
    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 01 '19 at 14:45
  • Dropping these here as relevant to future readers: another question on this site, an (external) essay on the topic; both touching on important aspects of [the real reason behind] this question – JamesTheAwesomeDude Oct 14 '19 at 18:15
  • The first link is not really a question by itself, and is from 2013. As the second opinionated view against DNSSEC, this also has been rebutted by other articles. My view is that people claiming that TLS replaces DNSSEC or that DNSSEC is not needed when you use TLS probably do not understand either TLS nor DNSSEC really. As for "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?" this is true even for DV-based certificates, so nothing specific to DNSSEC in fact. – Patrick Mevzek Oct 14 '19 at 18:25
  • @PatrickMevzek [re:CNAME-TLSA] I like the idea (I even tossed it around myself while drafting the question!), but I believe it will not work. Given two records www.my.tld. IN CNAME ww1.x.my.tld. and ww1.x.my.tld TLSA 2 0 1 0f…8a (where x has a ZSK which is not kept in a safety-deposit box), this doesn't actually authorize a CA0f…8a-anchored TLS cert to serve the big www, if I'm reading the spec correctly. (If _https._tcp SRV records were supported…) – JamesTheAwesomeDude Oct 14 '19 at 18:41

2 Answers2

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).

user174685
  • 11
  • 2
0

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.

JamesTheAwesomeDude
  • 700
  • 6
  • 18