Off topic for NSD but having a discussion on Twitter related to Google's announcement that HPKP and static key pinning is being removed from Chrome. I'm a big fan of DNSSEC and DANE and it is my *opinion* that a self-signed cert with a TLSA record is more secure than a CA cert without a TLSA record. I say opinion because I am not aware of any peer reviewed research. I use both - CA cert and TLSA - but that's because no browser is comfortable without a CA cert. The point was brought up that DANE doesn't support static key pinning, and thus is always vulnerable to a DNSSEC key being compromised in the chain above your zone. An idea to fix that, it would require someone who is in the academic circles to write something up and that's not me. Static DS records that browsers could include. If a zone has a static DS record with the browser, then the security of signing keys up the chain doesn't matter. Either you zone's DNSSEC responses validate with that static DS record or it doesn't validate. There even could be an option for EV level of validation with the browsers so that companies who choose to validate could have their static DS records in the browsers flagged as super duper secure or whatever. I personally would not use static DS records for any of my zones, but I could understand it being valuable to many companies (e.g. banks, hospitals, etc.) that are likely targets of MITM attacks. Whether there is merit to the concept of static DS records in browsers or not - hopefully a DNSSEC / security on this list will determine it. I'm no guru, just a user, so I don't feel qualified to argue points for it, but I did think the idea was worth disclosing. Thank you for your time.
On Sat, 28 Oct 2017, Michael A. Peters wrote:> The point was brought up that DANE doesn't support static key pinning, and > thus is always vulnerable to a DNSSEC key being compromised in the chain > above your zone.It does support that. If you run a local DNS resolver, and put a DS record as trusted key in your local configuration, then any changes upstream from that will be ignored. So if you publish a TLSA record, which is signed by ZSK which is signed by KSK that you defined in your local DNS server, then if the parent key takes over the domain, and changes the key because they don't have the private key of this zone, then your local DS record trust anchor will mismatch the received DNSKEY and it wont be trusted and the data becomes BOGUS and not given to the application. And you know what the bonus is here? Everyone can have their own set of static pins and don't have to trust google or mozilla or apple for the set of static pins. And, this even works with DNSSEC stappling as defined in https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-05 Even a compromiesd webserver won't override your pin, although it does assume the browser can load your trust anchors from your disk, or gives the dnssec chain to the local DNS server and then requeries for the TLSA record instead of doing validation inline, but it kind of has to do that anyway to support enterprise (split-DNS view) DNSSEC chains in TLS. Paul