Along with pod (who posted his introduction on the topic on this blog recently) and some others I also went along to the UKUUG conference in March. As we’ve come to expect it was a well-organised event, and this time it was held in a very nice location which made it all the more enjoyable; although we did suffer occasionally from oversubscribed talks with people sitting in the aisles!
One strong theme in the conference this year, which I will explore in this blog entry, was DNSSEC. There were three separate talks by Jan-Piet Mens, starting with a general introduction to the technology for those familiar with DNS, followed by a pair of talks discussing techniques and tools for signing and validating names with DNSSEC. I won’t repeat any of the content of the talks here; there are plenty of general resources about DNSSEC out there, and you can get the slides for these talks from the UKUUG web site:
This topic has been of interest to me for some years, and I recently implemented full DNSSEC validation on the team’s standard server configuration (based on Debian ’Squeeze’). However as with all technologies, it’s good to be reminded of the basic principles in technologies you work with. This serves to challenge any doubtful assumptions or misunderstandings you may have (unwittingly) absorbed, as well as gain fresh insights on how to solve some of the more tricky problems. I was, therefore, pleased to see that Jan-Piet’s presentation on validation focused on unbound, which I’ve used as a validating resolver on our Debian systems.
Probably the biggest open question in my mind as a result of that talk was how we should expect end-user machines (be they desktops, laptops or mobile devices) to have access to a fully end-to-end secure DNS channel at all times. For example, if I recall correctly, the venue’s wireless facility offered a DNS server which did not pass through the required parts of the DNS response to allow a local validating resolver to function; and if (as many access networks do) external DNS connections had been blocked, there would have been no way to receive secured DNS responses at all, without recourse to a VPN. There are clearly some interesting autoconfiguration challenges here, and I found myself musing over how I’d like my laptop to behave when faced with these various restricted networks. Perhaps there is an enhancement request for Network Manager to condense out of those thoughts.
The other part of this problem lies in default OS configuration; at the moment, the channel between the traditional stub DNS resolvers and their nominated recursive resolvers is unsecured, and represents a significant attack surface (depending, of course, on the local network topology). One answer would simply be to install DNSSEC validating resolvers on all hosts, but this represents a big change compared to the tiny, unmanaged stub resolvers which exist on nearly every client platform to date. It will be interesting to see what becomes recommended practice here; whether there are other plausible alternatives to securing that channel; and which OS vendor will be first to make a local validating resolver part of their default configuration, given the above concerns (and rapidly evolving landscape of DNSSEC configurations in the wild, and software to support this: an oft-repeated point in the talks was that one should always be using the latest and greatest DNSSEC tools because of the rate of change in this area).
Further up the stack, towards user applications, there are clearly lots of opportunities for application-level DNSSEC validation, and the Firefox DNSSEC Validator extension is just one.
The signing talk was also of great interest; among many other useful pieces of advice, I learnt that BIND’s built-in tools appear to have become much more user-friendly and automatic than the last time I looked; however I have yet to have a chance to sit down and start signing any zones of my own (DNS is managed by a separate team, so there will be less scope for experimentation with signing here at OUCS).
Coincidentally, during this conference, the Comodo CA rogue certificates incident came to light, and this provided a nice reminder of how critical security mechanisms such as SSL and DNSSEC are becoming, and the importance of limiting exposure to incidents of this sort. Ironically, one of the rogue certificates issued was for addons.mozilla.org, which distributes the above Firefox extension!
This tied in quite nicely with some remarks from the talks about other opportunities DNSSEC provides, over and above the traditional names and numbers: now we are beginning to develop a global, distributed and verifiable database, publishing trust anchors such as SSH and X.509 certificate fingerprints in the DNS becomes realistic. SSHFP has actually existed as a DNS resource type for some time, but perhaps now becomes much more useful.
DANE is an standardisation effort to specify a way of doing the same with X.509 certificates and TLS. This is an interesting political, as well as technical point; some may feel that with such technologies on the horizon, the reign of the traditional certificate authorities is drawing to a close, and that systems like DANE can actually provide greater assurances than we’ve come to expect from commercial CA providers (and the problems distributing CA certificates for smaller, organisation-scoped CAs). The conspiracy theorists may claim that DNSSEC with DANE is no better than the small number of commercial X.509 CAs, and that both could easily be subverted by government or other powers, but DNSSEC has one powerful ability which counters this argument at least to some extent; anyone who is validating names with DNSSEC is at liberty to insert trust anchors relating to any part of the DNS tree they choose (so, for example, Sysdev obviously has a significant interest in the ox.ac.uk DNS subtree; we might therefore configure our resolvers with the DS records of ox.ac.uk if they existed and we could retrieve them securely — in our case, by popping round to the next office).
By way of closing, I note that this year saw a new academic workshop on DNS security: SATIN. I haven’t yet had a chance to explore the papers on this site, but there are several topics of possible interest there. It seems like interest in this area will continue to increase over the next couple of years.
I highly recommend reading of the papers published during the SATIN conference; most of them are excellent.