Close your eyes and imagine a world in which a user visits a website. This website may be encrypted, and when it is, the SSL certificate used must somehow be validated.
Traditionally, SSL certificates are issued by third parties that have their certificate authorities included in browsers and operating system’s bundles. This way, whichever SSL certificate is signed by a known (and “trusted”) certificate authority is assumed to validate the website that uses encryption is indeed the website the user intended to visit, operated by the party the user intended to have the website operated by … in a broad and rather liberal definition.
However, no user knows ahead of time, whether to expect a website to be encrypted, nor what public key to expect. At least not before having visited the website. Herein lies the difference between HPKP and DANE.
HTTP Public Key Pinning (HPKP) is a methodology to communicate a set of public key signatures, allowing the browser to determine whether or not subsequent connections match the expectations communicated before. Since it communicates this set of expectations through HTTP headers, it is valid for HTTP traffic only — i.e. your browser.
DNS-based Authentication of Named Entities (DANE) is a methodology through which you use the DNS side-channel to manage the client application’s expectations before your client application even attempts to connect to the target endpoint. Effectively, it does not matter whether your client connects over SMTP, IMAP, HTTP, or almost literally whichever other protocol (with exceptions for telnet and NTP, etc.).
This makes DANE the solution far superior to HPKP. But then why do we even have HPKP?
Well, DANE is slightly harder to implement for server administrators, zone owners, internet users, ISPs, operating system vendors and client application developers. It requires a zone uses DNSSEC — because unverifiable records invalidate the trust anchor. It’s therefore incurring a slightly more involved effort on zone owners. Internet users often use routers that are unable to perform DNSSEC — as the length of a single DNSSEC record is likely to overflow the maximum size of a UDP packet, TCP queries should be used. DNSSEC additionally requires signature verification not implemented as a routine on most DSL routers and cable modems. It’s difficult for operating system vendors to ensure the OS as a whole, and the network stack in particular performs all the right actions provided an arbitrary environment without known knowns. It’s difficult for client application developers because they in turn cannot trust the OS nor the environment to provide the necessary means for validation. Often, TCP queries are simply not allowed, and TCP queries to public DNS services that do have DNSSEC (such as 8.8.8.8 and 8.8.4.4) may very well not be available either. Enforcing validation in such cloud of uncertainty is like hitting a pinata in the dark.
Regretfully.
kanarip 