About DANEportal

End-to-end security is a big deal – yet it is currently an exception on the internet.

Take secure messaging: users have to go out of their way to use specific platforms and apps that support it. And if they do, they can only communicate with others on that same platform or within the same organization.

Why can’t we do E2E security on an internet-wide scale, like we do for HTTPS?

It all comes down to the key-learning problem:

The security is based on public-key cryptography, meaning you need the public key of the recipient to encrypt things such that only their corresponding private key can decrypt.

But how does one learn the public key for their recipient? If you never met before to manually share keys, you have to be on some messaging app that does it under the covers for its users, or your workplace has a cert system for their own employees.

Ultimately, you will need to be part of some infrastructure that can securely share / learn keys. That is the critical missing link which prevents Internet-scale E2E protection.

It would be really convenient if such an infrastructure existed on an Internet-wide scale...

... and thankfully it does: the Domain Name System.

The DNS is a standard, mature, and decentralized global database of internet records – with the adoption of DNSSEC, we gain the ability to authenticate those records.

At a basic level, this just means you can prove the IP address you got for a website over DNS is not fake. However, with some creativity - by making real-world cryptographic keys into DNS records - DNSSEC provides the foundation for Internet-scale key-learning for any keys which can be associated with names under a domain.

That is why some smart folks at the IETF made the protocol DANE.

DNS-based Authentication of Named Entities creates a standard for domain holders to put cryptographic certs under their zone, visible to DNS resolvers alongside their usual TYPE A or MX records. Initially it was made for TLS, so websites could securely offer their certificate along with their IP address for HTTPS when browsers resolve their domain. Certs on DNS could coexist with existing CA trust structures and PKIX validation, or simply rely on the trust derived through DNSSEC.

However, certs could also be for other named things that fall under a domain name. The perfect example of this is email addresses.

Consider how DANE neatly overcomes the key-learning problem despite organizational barriers:

It is no surprise then that DANE got protocol extensions to support certificates of popular email security protocols -- such as DANE S/MIME (RFC written in 2017).

However, there are challenges with maintaining a DANE zone for administrators. How does one operate a DNS zone for a new protocol which lacks mature tools and automation? Is the administrator to manage all the keys for her constituent email users? What if they wish to use their own keys, and manage them consistently across many email addresses and domains?

Despite DANE offering the ability for boundary-less E2E security, the realities of extra operational workload on admins and lack of autonomy for email users is a large barrier limiting uptake and interest.

Overcoming such barriers is the goal of DANEportal