So there I was eating my lunch and reading a treeware version of Information Week (you know, those paper things we called “magazines” before everything went to e-something?). Having always been interested in encryption, I started reading the “2012 Data Encryption Survey: Progress and Pain” (sadly, free registration is required to read the whole article) expecting it to be, well, all about data encryption…
… and it was – particularly starting off talking about the the challenges of using SSL/TLS with all the attempts to break SSL, and the multiple compromises at SSL certificate companies that have resulted in attackers successfully getting bogus, but valid, certificates asserting they were someone else.
Then all of a sudden I stopped eating my sandwich as the article took a sharp turn into the world of DNSSEC (and yes, I added some emphasis at the end):
Enter DNSSEC. The DNS Security Extension spec provides the capability for a domain owner–the IT team–to place additional encryption validation at the DNS layer. First it will verify that the SSL certificate is valid. But it also will verify that the DNS server that is authoritative for the domain being requested actually belongs to the certificate owner.
In our example, if a user went to the breached Hotmail.com site and got a Hotmail.com certificate, it wouldn’t validate with the DNS server hosting Hotmail.com, because the certificate generated by the attacker using the hacked CA wouldn’t match. The browser could display a big red box telling the user he’s going to an invalid site. Currently, Google’s Chrome supports DNSSEC natively, and there are plug-ins for Firefox. Internet Explorer 9 doesn’t support DNSSEC, but version 10 is expected to.
The other benefit of DNSSEC is that DNS queries are validated by all servers–from the domain’s authoritative server to the local DNS server to the browser–which means that even man-in-the-middle attacks on DNS queries will be caught.
DNSSEC isn’t perfect, and it’s not a complete replacement for SSL/TLS. But it is a step in the right direction to put control of certificate verification into the hands of certificate owners, instead of the CAs. Furthermore, using DNSSEC is a great solution for organizations with their own internal CAs that don’t want to deploy certificates to every possible device. Most of our respondents, 55%, have their own internal CAs; an additional 15% plan to within 24 months.
Having the keys to your own castle is an important step in controlling your encryption destiny, and if you plan to leverage cloud services securely, it may just be a requirement.
Here, in just a few paragraphs, was a great explanation of an important role DNSSEC can play as another layer in the security infrastructure. In this case, DNSSEC can be used to check the validity of the certificates being used for SSL/TLS.
More importantly, me being the control-freak that I am, the article points out the incredible importance of being in control of your own security. You, as the domain owner, can be the one inserting the appropriate keys directly into the DNS infrastructure. Or you can have someone do it on your behalf… but the point is that you are in control.
That’s a powerful capability!
What do you think? Have you started looking at DNSSEC yet? If not, check out the DNSSEC resources we’ve listed so far – and if you don’t find exactly what you need, please ask us about it and we’ll see if we can find something to help you.
P.S. For those wondering, the rest of the article provided some interesting discussion and statistics around encryption within cloud computing platforms and with the use of mobile devices such as tablets and smartphones. Oh, and I did eventually finish my sandwich. 
