Today seems to be “DNS Day” here at IETF 90 in Toronto with the two major DNS-related working groups we follow here at Deploy360, DNSOP and DANE, both meeting on the same day. We’ve also got V6OPS meeting again (as they did yesterday), have several IPv6-security drafts in OPSEC and have routing discussions happening in IDR. Oh, and we’ll be splitting ourselves 3 ways in the first time slot (and wishing we had clones!). Plus, we’ll have the “ISOC@IETF” briefing panel at lunch time looking at security and privacy issues. It’s going to be a busy day!
If you’d like to join the DNSOP or DANE sessions (or any of the others) remotely to hear the discussion you can follow the instructions on the IETF 90 Remote Participation page or use the “tools-style” agenda page that provides easy links to the audio stream, jabber chat room documents and more for each of the sessions.
DNSOP, DANE and UTA
As I mentioned in my Rough Guide post about DNSSEC/DANE at IETF 90, there is a great amount happening in both DNSOP and DANE. Here is the relevant excerpt from that post:
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 bepresenting a draft about DNSSEC key and signing policies. Daniel Migault will betackling 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 aroundthe “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.
Unfortunately at the same time as DNSOP from 09:00-11:30, the Using TLS in Applications (UTA) working group will be meeting. While the UTA agenda doesn’t directly mention DNSSEC, 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.
IPv6
Beyond DNS, today the IPv6 Operations (V6OPS) working group is back with an agenda once again looking at the operational aspects of running IPv6. The first document on running multiple IPv6 prefixes was actually addressed in yesterday’s session so there may be more time available for other discussions. I’m personally intrigued by the discussion about power consumption due to IPv6 multicast on WiFi devices. I’ve not been directly following that draft so I’m intrigued to learn more.
Outside of V6OPS, IPv6 will also feature prominently on today’s OPSEC agenda with two drafts from Fernando Gont being presented that talk about how firewalls interact with IPv6. First he’ll be discussing how many firewalls drop IPv6 extension headers (EH) and his thoughts about that. Second, he’s got a draft on “Requirements for IPv6 Enterprise Firewalls” that looks quite interesting.
(As an aside, having lived in Canada from 2000-2005, I’m very pleased that there is at least one draft (Fernando’s) being presented here in Toronto that includes “eh” in it, given that this is a very common Canadian verbal expression, as in “It’s going to be a great day, eh?” 
)
Routing and Securing BGP
Today is also the day one of the major routing working groups we track will be meeting, unfortunately in that same 9:00-11:30 am block as DNSOP and UTA. The Inter-Domain Routing (IDR) working group has an extremely packed agenda full of all sorts of drafts related to securing BGP and improving the security of our routing infrastructure. As our colleague Andrei Robachevsky wrote in his Rough Guide post, IDR “continues to work on better handling of malformed BGP attributes that may cause serious outages, and even cascading effects for other networks. Because of the timing conflict, I won’t personally be in IDR, but you can expect to find Andrei there.
ISOC@IETF90 Briefing: Internet Security and Privacy: Ten Years Later
In the midst of all the working groups today we’ll spend our lunch time from 11:45-12:45 at the traditional “ISOC@IETF Briefing Panel” that happens every Tuesday of an IETF meeting. The theme this time is “Internet Security and Privacy: Ten years later” and the abstract begins:
Many fundamental Internet protocols and architectural elements were designed for relatively closed and controlled networks and later used in a fairly trusted environment. Then came explosive Internet growth that changed its very nature – the Internet became a global, open communication medium to which anyone could connect and contribute.
At the same time, the Internet model was also changing. Concentration and centralization of certain functions at various Internet architecture layers created new types of vulnerabilities and, consequently, facilitated new threats such as pervasive monitoring. These vulnerabilities manifest themselves in different ways – for instance, in lack of diversity in implementations of critical security protocols, like TLS.
The number and nature of connected devices is also changing dramatically – sensors, controllers, appliances, etc., all communicating without human intervention.
The Internet continues to change and this evolution will continue. How will security and privacy challenges be addressed ten years from now? What are the missing building blocks that need to be developed? Will current approaches allow us to catch up or is a change of paradigm required?
There are a great set of panelists and this should be a great discussion. It will be live streamed over YouTube and anyone is welcome to watch. (Unless they are trying to view the stream from Germany, where apparently they can’t.)
And after all that is done we’ll probably be going to the IETF Social event tonight to talk to more people about how we might be able to help them… before eventually getting to bed to get ready for Day 3…
The information about the relevant working groups today is:
DNSOP (DNS Operations) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/dnsop/
Documents: https://datatracker.ietf.org/wg/dnsop/
Charter: http://tools.ietf.org/wg/dnsop/charters/
(Tuesday, July 22, 2014, 0900-1130 EDT, Ballroom)
UTA (Using TLS in Applications) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/uta/
Documents: https://datatracker.ietf.org/wg/uta/
Charter: http://tools.ietf.org/wg/uta/charters/
(Tuesday, July 22, 2014, 0900-1130 EDT, Ontario)
IDR (Inter-Domain Routing Working Group) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/idr/
Charter: https://datatracker.ietf.org/wg/idr/charter/
(Tuesday, 22 July, 0900-1130 EDT, Tudor 7/8 Room)
OPSEC (Operational Security) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/opsec/
Charter: https://datatracker.ietf.org/wg/opsec/charter/
(Tuesday, 22 July, 1300-1400 EDT, Territories Room)
V6OPS (IPv6 Operations) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/v6ops/
Documents: https://datatracker.ietf.org/wg/v6ops/
Charter: https://datatracker.ietf.org/wg/v6ops/charter/
(Tuesday, July 22, 2014, 1420-1620 EDT, Ontario)
DANE (DNS-based Authentication of Named Entities) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/dane/
Documents: https://datatracker.ietf.org/wg/dane/
Charter: http://datatracker.ietf.org/wg/dane/charter/
(Tuesday, July 22, 2014, 1640-1840 EDT, Canadian)
For more background on what is happening at IETF 90, please see our “Rough Guide to IETF 90″ posts on the ITM blog:
If you are here at IETF 90 in Toronto, please do feel free to say hello to a member of the Deploy360 team. And if you want to get started with IPv6, DNSSEC or one of our other topics, please visit our “Start Here” page to find resources appropriate to your type of organization.
