Deploy360 6 January 2012

What is the correct “user experience” for DNSSEC in a web browser?

By Dan YorkDirector, Internet Technology

How do we get to the point where end-users can actually see correct DNSSEC validation? After all, getting a zillion zones signed with DNSSEC will do very little if users can’t know that a site has been secured with DNSSEC.

An obvious starting point is with the web browsers and today I wrote up a step-by-step tutorial of how you can enable DNSSEC support in Firefox using the DNSSEC-Validator add-on:

How To Add DNSSEC Support To Mozilla Firefox

The end result is that you get a “key” icon in the Firefox address bar that tells you if the site has been secured with DNSSEC:

Deploy360 dnssec

Now, the obvious next question in my mind is:

how can we get similar DNSSEC visibility in Google Chrome, Safari, Internet Explorer, Opera, etc?

The follow-on question, though, is this:

is having a key icon (or something similar) the correct user experience for showing DNSSEC validation?

It turns out, for instance, that Google Chrome has had DNSSEC validation built in since version 14. As Googler Adam Langley wrote about back in June 2011,  if I go to using Chrome and then click on the lock icon, I will see that DNSSEC has correctly been verified:

Now there is a rather huge caveat here.  The message shown above ONLY occurs if you connect to a site and:

  1. you are connecting using HTTPS versus HTTP
  2. the domain has been signed with DNSSEC
  3. the server uses a self-signed SSL certificate (versus one issued by a trusted Certificate Authority (CA))

For instance, if I go to the Deploy360 site using Chrome, there is no indication whatsoever that the site is signed with DNSSEC.  If I connect to our site using SSL, I get a lock icon that indicates there is a problem because there is a mixture of secure and insecure content on the page… but nothing about DNSSEC as the SSL messages have taken priority.

The issue, of course, is “overloading” that lock icon, i.e. using it for multiple purposes.

Adam Langley wrote about his concern that a “DNSSEC-stapled” certificate could be more easily spoofed than a full CA-signed SSL certificate. He notes that someone could easily sign a domain with DNSSEC, set up a self-signed certificate and wind up with a green “lock” icon in Chrome… and do so with a domain name confusingly similar to another site.

The user might then think they are in fact connected to the correct site.

Which goes back to the question of what is the correct user experience for users to know that they are reaching a site secured with DNSSEC.

Is it a separate icon like the key icon used by the Firefox Add-on?

Is it overloading a lock icon in some way?

Way back in July 2010, the question was raised to the Google Chrome team of supporting a DNSSEC icon, and one of the concerns raised (in fact by Adam Langley) was:

It is vanishingly unlikely that there will ever be any UI indication about DNSSEC specifically. Users don’t understand the current UI without adding any more to it.

Is the current browser interface already too complicated for users?  Would adding a key icon or something similar just create too confusing of a user experience?

If so, how, then, can we help users obtain the benefits offered by DNSSEC in knowing they are reaching the correct site?

Particularly for sites that do not require SSL certificates, but where an assertion of identity would still be useful.

Thoughts? Comments? Suggestions?

P.S. And yes, it looks like someone made a version for Google Chrome of the DNSSEC Validator for Firefox, but in looking at the subversion repository the source code appears to have not been modified for over a year so the current status is unclear.

UPDATE: There were a few points of discussion on Hacker News related to this post.

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related articles

Improving Technical Security 15 March 2019

DNS Privacy Frequently Asked Questions (FAQ)

We previously posted about how the DNS does not inherently employ any mechanisms to provide confidentiality for DNS transactions,...

Improving Technical Security 14 March 2019

Introduction to DNS Privacy

Almost every time we use an Internet application, it starts with a DNS (Domain Name System) transaction to map...

Improving Technical Security 13 March 2019

IPv6 Security for IPv4 Engineers

It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a...