Email addresses in DNS records? We'll make a hash of it, says IETF

Email addresses of domain-name admins should be encrypted one-way – aka hashed – when added to DNS records, an IETF working group has decided.

Following a lengthy exchange on the value of adding privacy safeguards for email addresses that are often readily available, Google's Warren Kumari told the group that "the privacy arguments for the hashing solution tip the scales in its favor, so we are instructing the authors to keep the hashing text."

In other words, if you own internetcats.org, and kieren@internetcats.org is the address you use to update your domain name's records, it should be hashed when stored in the DNS database so that someone trying to hijack your domain has to work a little bit harder to find and spoof your email address.

The decision is the latest in a new – and largely experimental – protocol that will use domain names as a key source of online security: DANE.

As a result of the expanding use of the related DNSSEC protocol, which protects against unauthorized tampering of internet traffic, internet engineers have been looking at how to use the domain-name system itself as an authenticator. The result is DANE, standing for "DNS-based Authentication of Named Entities."

Broadly, DANE will enable the owners of domain names to specify the type of security they are using, limiting the ability for outside hackers to break in. The protocol has already been highlighted as a foundation to the next generation of secure email.

As things stand, encryption and security of internet traffic are reliant on certificates created and provided by a number of certificate authorities (CAs). A default list of trusted CAs is included in almost all browsers and operating systems in order to make the system relatively universal.

However, the targeting and hacking of smaller CAs has in the past led to interception of emails and other sensitive data. Your data is only as safe as your CA's security.

What DANE hopes to do is insert an additional layer of security by including top-level domain operators into that process.

When implemented, it should be possible for the owner of a domain name to specify who has issued the SSL/TLS certificate for its website. So, if you own internetcats.org, and someone connects to https://internetcats.org with their web browser, the DNS records for the domain will specify the trusted CA that ultimately issued the certificate for that HTTPS connection.

That means the browser can bail out of the connection, and alert the user, if the certificate presented by the server does not match the details provided in the domain name's DNS records. It effectively cuts the large default list of CAs down to a much smaller, controlled group, and adds a "trust anchor."

Domain expansion

With many more companies entering the DNS operator space thanks to the generic top-level domain program that has seen 500 new dot-words added in the past year – all of whom are contractually obliged to install DNSSEC – the idea not only has merit, but potential business benefits.

A number of top-level domains, such as ".bank," are using promises of additional security as a way to differentiate themselves online. As well as ensuring that only specific organizations are allowed to have a particular domain name, in order to engender greater trust, the ability to add more security at the DNS level itself will, in theory at least, makes things much safer.

As just one part of that protocol's specification, the DANE working group has been discussing whether to supply additional security around email addresses that are then used to state which specific certificate(s) should be used. In other words, to protect the identity of the person who is specifying which certificates can be used in order to make it harder for a hacker to try to pretend to be that person, and then specify a different certificate.

Some in the working group noted that such email addresses are often easy to find, making the extra step an unnecessary additional complication. Others argued that it was still possible to break the suggested encryption around the email address, so its introduction was not solving a problem, just making it harder.

"Consensus has been hard to judge here," noted Kumari in an email to the list, "and seems to have evolved over time, which is a sign that people have been looking at things from different perspectives." But, he said, they had decided to add some security around the email address.

As another participant noted: "It is like having a closed door versus no door at all. No door communicates 'come in, no secrets, we're open,' while the closed door (even if it can be opened by minor force) communicates 'private space.'" ®