Tuesday at IETF 90 seems to be “DNS Day” with two of the major DNS-related working groups, DNSOP and DANE, both meeting that day and addressing some major topics. There are, of course, other items related to DNSSEC and “DNS security” in general scattered throughout the week – let me walk through what the week looks like…
DNS Operations (DNSOP)
Tuesday morning from 9:00-11:30 EDT the DNSOP Working Group kicks off with a full agenda that includes a great amount of DNSSEC activity. Matthijs Mekking will be presenting a draft about DNSSEC key and signing policies. Daniel Migault will be tackling the topic of what the requirements are for DNSSEC validation so that DNS resolvers can always have validation enabled.
Of particular interest to folks looking to get DNSSEC deployed (as I am) will be the “DNSSEC Roadblock Avoidance” draft that explores what are the problems with DNSSEC validation in many common network environments – and how do we mitigate those problems.
As the agenda indicates, there will be a range of other topics covered in DNSOP, too. The biggest and most controversial discussion may be around how we optimize the distribution of root zone data, with Warren Kumari and Paul Hoffman offering one view of distributing the root zone and Paul Vixie and Xiaodong Lee offering another view of how to scale the root of DNS. Given that DNSSEC plays an important role in both scenarios we’ll be paying close attention to what I expect will be quite a passionate discussion!
Beyond those topics you can probably expect to see some of the many other documents under DNSOP (scroll down the page to see the full list) raised for consideration – unless, of course, the root optimization discussion consumes most of the time, as could easily happen.
DNS-based Authentication of Named Entities (DANE)
Later on Tuesday afternoon, the working group looking after the DANE protocol will be actively discussing how various other protocols can use DANE / DNSSEC to provide a higher level of security for TLS (SSL) certificates. We should see discussion around the “DANE and OpenPGP” draft as well as the “DANE and SMIME” draft. One of the DANE WG co-chairs, Olafur Gudmundsson, told me that the “SMTP security via opportunistic DANE TLS” draft and the “Using DANE with SRV Records” draft will both be going to Working Group Last Call and so that may or may not trigger some comments.
What may generate more discussion, though, is interest in changing the “DANE Operational Guidance” draft into a “DANEbis” document, i.e. looking at it as a replacement/update for RFC6698 that defines DANE. This should be an interesting discussion!
On a similar track, Paul Wouters will be speaking about standardizing how “Raw Public Keys” for TLS can be authenticated using DANE. As I understand it, Paul wants to extend the TLSA record used in DANE to support more than just PKIX-formatted certificates, allowing DANE to be used for applications that do not require PKIX certs.
I am also intrigued to learn more about ideas from Haixin Duan to use DANE to better secure the usage of HTTPS connections in content distribution networks (CDNs). Haixin Duan and some colleagues have written a paper that goes into more detail (search for “DANE” to jump to the relevant section).
If there is time Olafur tells me that the chairs also intend to kick off a discussion of “reverse DANE”, i.e. DANE records for clients, that might lead to some interesting applications and areas of work.
Other Working Groups
Beyond the two main DNSSEC-related working groups there will be a number of other DNSSEC-related discussions going on in other working groups. Here are some of the other groups that I’ll be monitoring:
SIPCORE – On Monday afternoon Olle Johansson is on the SIPCORE agenda to talk about how DANE can be used to improve the security of VOIP sessions using TLS and SIP. This is a very cool use of DANE / DNSSEC at an application layer and I’m looking forward to the discussion.
TRANS - On Friday morning the TRANS Working Group focused on “Certificate Transparency” (CT) will be having a discussion about whether there is a role for CT to play in logging DNSSEC information. There is not a draft associated with this idea but there was a lengthy discussion in the trans mailing list that began with a message from Nico Williams and continued on into great detail. My understanding is that the discussion will be mainly about what, if any, role CT might play with DNSSEC and DANE. Given some of the passions involved with this whole topic I expect there to be a great amount of discussion.
HOMENET - At the exact same time as TRANS on Friday morning, the HOMENET Working Group has on its agenda two documents from Daniel Migault that that look at two different aspects of DNSSEC interaction with customer-premise equipment (CPE). The first draft outlines an architecture in which a CPE device could manage some of its naming services and then outsource other naming services, such as DNSSEC management, to external services. The second draft proposes new DHCP options that would provide a means to update the trust anchors used in DNSSEC and also provide a way to update the time of a CPE device. These are both definitely important work as we need CPE devices to provide solid DNSSEC support if we are to get DNSSEC validation happening everywhere.
DNSSD – The DNSSD working group is looking at how to extend “DNS service discovery (DNS-SD)” and “multicast DNS (mDNS)” outside of a simple local network. This kind of service discovery is what happens when you, for instance, look to add a local printer or file server and your computer “discovers” the devices available on your network. The question is how to extend this beyond your local network to other networks to which you may want to connect. There hasn’t been a great amount of attention to DNSSEC here, but in both the DNSSD base requirements document and also the mDNS threat model document there are discussions of security and potential places where DNSSEC may potentially play a role.
UTA – Finally, the Using TLS in Applications (UTA) working group agenda doesn’t directly mention DNSSEC, but we definitely pay attention to UTA given that the drafts all focus on securing TLS and that DANE could potentially play a role here. (We also have an interest for our “TLS For Applications” section of Deploy360.) Unfortunately UTA is scheduled Tuesday morning at the exact same time as DNSOP, which will make it quite challenging for those of us who want to be in two places at once!
All in all it will be a very busy week for those of involved with strengthening the Internet through improved DNS security!
P.S. For more information about DNSSEC and DANE and how you can get them deployed for your networks and domains, please see our Deploy360 site:
Relevant Working Groups at IETF 90:
DNSOP (DNS Operations) WG
(Tuesday, July 22, 2014, 0900-1130 EDT, Ballroom)
DANE (DNS-based Authentication of Named Entities) WG
(Tuesday, July 22, 2014, 1640-1840 EDT, Canadian)
DNSSD (Extensions for Scalable DNS Service Discovery) WG
(Thursday, July 24, 2014, 1520-1720 EDT, Canadian)
TRANS (Public Notary Transparency) WG
(Friday, July 25, 2014, 0900-1130 EDT, Manitoba)
UTA (Using TLS in Applications) WG
(Tuesday, July 22, 2014, 0900-1130 EDT, Ontario)
HOMENET (Home Networking) WG
(Friday, July 25, 2014, 0900-1130 EDT, Canadian)
SIPCORE (Session Initiation Protocol Core) WG
(Monday, July 21, 2014, 1300-1500 EDT, Territories)
There’s a lot going on next week, and whether you plan to be there or join remotely, there’s much to follow. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see http://dev.internetsociety.org/rough-guide-ietf90.