Monthly Archives: January 2014

Celebrating Data Privacy Day

Today is International Data Privacy Day, and I wanted to let Alissa Cooper say a few words about how we are working on privacy topics at the IETF.

Jari Arkko, IETF Chair

Celebrating Data Privacy Day

Each year, Data Privacy Day is celebrated on January 28 to commemorate the signing of the first legally binding international data protection treaty. It is an opportunity to promote user empowerment and education about protecting personal data.

The IETF has seen the launch of many new privacy-relevant activities in recent months, including efforts that reflect the particular kinds of user empowerment that standards organizations such as ours can effectuate. Last year the IAB published RFC 6973, Privacy Considerations for Internet Protocols, one goal of which was to provide guidance to those working in the IETF about how to consider privacy threats and mitigations within their protocol designs. Since then, the IAB Privacy Program has been refining a privacy tutorial to help put RFC 6973’s guidance into practice. After several trial runs, the tutorial has been solidified and will be conducted for all IETF participants on Sunday, March 2, at the start of the next IETF meeting.

Recent revelations concerning pervasive monitoring have spurred work on empowering users in a different way, by re-emphasising the need for security and privacy technologies to be easier to deploy and use. At least some of the attacks that we’ve learned about in recent months could have been deterred or mitigated if technologies and standards that already existed had been deployed (for example, the use of transport layer security to encrypt traffic between mail servers or data centers). But we know far too well that the difficulty of deploying and using security technologies has often prevented their adoption, both by corporations and individual end users. One consequence of the pervasive monitoring revelations has been to re-focus the technical community’s attention on usable security.

This trend is apparent within many different IETF efforts. Using TLS in Applications (UTA) is a new working group that aims to (among other things) provide greater clarity for application developers about best practices for using transport layer security in their applications. There have been discussions in many different workings groups, mailing lists, and Internet drafts about whether and how to increase the use of opportunistic encryption, which can have fewer deployment barriers compared to fully authenticated encryption and could thereby help to mitigate passive traffic sniffing.

While these examples reflect a desire to make encryption more usable, encryption alone does not suffice for meeting all data protection needs. Even with payload encryption, meta-data collection and traffic analysis can still reveal sensitive information to intermediaries, and care must be taken to ensure that payloads themselves do not include personal data unnecessarily.

Tackling these sorts of problems requires adopting data minimization and anonymization techniques that in some cases have proved even more onerous to deploy and use than transport encryption. Making this class of solutions more usable will require significant effort going forward ­ meaning that there is plenty more work to be done both inside and outside the IETF.

The IETF has long been committed to building secure protocols (see RFC 3365, RFC 3552) and is currently debating extending that commitment to defending against pervasive monitoring. We still have a ways to go to make security more usable and to build in additional privacy protections beyond what security features already provide, but today we can celebrate our recent efforts and the renewed enthusiasm for privacy protection emerging throughout the IETF community. Let’s turn that energy into concrete solutions in the coming months and years.

Alissa Cooper, IAB

HTTP 2.0

I wanted to draw attention to Mark Nottingham’s excellent blog article about strengthening HTTP. The article is available from this link. Like his previous posts on the topic, he raises important issues about the design of HTTP 2.0 and how to ensure that we can provide as good security protection as possible for Internet users employing HTTP 2.0.

This is obviously extremely important for the Internet and its evolution. Such a large part of our Internet use happens on the web that its key building blocks matter. And the web protocol stack is not just used by us humans and our browsers; it is also used by countless applications. As an example, the world of intelligent objects around us is to a large extent being constructed on top of the web protocol stack. HTTP 2.0 is likely to see very widespread use as the standard becomes available later this spring.

And improving the security is not easy, as Mark points out. But it is important. Can we do more? How can the current thinking be improved? Please join the discussion at the HTTPBIS working group.

Jari Arkko, Chair of the IETF

IANA

In this article I wanted to highlight an important but often hidden part in the IETF ecosystem: Internet Assigned Numbers Authority (IANA).  What is IANA, how does it work, how is it related to the IETF, and how has it evolved over time?

Protocols need a common vocabulary to communicate in an interoperable manner. For example, the TCP port number 80 denotes HTTP service. Most IETF protocols used in the Internet make use of registries in some form, either in using constant or well-known values, or communicating with addresses or names assigned through a registry. These registries are naturally critical to the operation of the Internet. Consequently, their management must be done in a predictable, stable and secure manner.

IETF relies on IANA registries of protocol parameters: protocol numbers, port numbers, TLVs, MIME types, and so on. The role of the IETF is to set the policy on how allocations in these spaces can be made. The role of an operator performing the IANA function is then to make the actual allocations, following the policy, and maintain a public web site that shows what values have been allocated. Thus, IETF sets policy which the IANA operator implements. In addition, Internet Architecture Board (IAB) is responsible for the oversight of the IANA function. This role includes appeals, selection of the registry operator, and keeping the overall framework up to date.

This system has served the Internet well, but has also evolved quite a bit over time. As part of the formation of the Internet Corporation for Assigned Names and Numbers (ICANN) and transfer of functions to it, the US Department of Commerce awarded ICANN a contract to perform the IANA function. That contract still exists, but it is important to understand the role that the Internet community has taken on in running the system. For instance, 2000, the IETF and ICANN signed a contract about the protocol parameters aspect of the IANA function (RFC 2860) and specified the role of the IAB in its oversight (RFC 2850). Service-level agreements have been written on a yearly basis since 2007; these agreements specify expected service levels and detailed operational procedures. A more detailed specification of the role of the operators that perform protocol parameter IANA function was written in 2011 (RFC 6220). IANA reviews all drafts that are up for approval, making sure that the IANA policy specified in them is understandable and implementable.

I think that the system works remarkably well today. For instance, requests related to IETF standards process – such as IANA review of drafts – are fulfilled quickly. Statistics are used to track the process. I think that the system has grown up, just like the Internet itself. IANA function continues to be a professionally managed operation that keeps improving itself, and is supported by documented procedures and agreements.

Note that IANA handles two other important registries beyond protocol parameters. They are the top-level registry for IP addresses, and coordinate the allocation of the unicast address space further to Regional Internet Registries (RIRs), such as RIPE or ARIN. The RIR community sets the actual allocation policies. IANA is also the registry for top-level domain names. Domain-name policies are set by ICANN.

And the evolution of the system continues. As the Internet continues to support even more applications and technology, the system needs to do more. And we need to ensure that the overall framework continues to match what the global Internet needs. In my view, this means further evolution towards the central elements in the above RFCs, i.e., normal contract relationship, supported by relevant specifications and community processes. Of course, the details and those specifications continue to change. IAB’s oversight role is important here. For instance, Olaf Kolkman has written a new draft for the IAB’s IANA evolution program. This informational draft explains the oversight-policy-implementation framework as it applies to not just protocol numbers but also addresses and top-level domain names. Documenting this model is helpful to ensure that we all understand what roles different parties have in the overall system, and also helps to discover areas where further work is needed. I know Olaf and the IAB would be grateful for feedback; please use the internetgovtech@iab.org list for discussion.

The IETF also needs to ensure that various policies governing IANA allocations are well specified. In addition to doing this for new protocols, we also have to maintain old number spaces and their rules and definitions as the practices evolve. For instance, we recently went through the Internet numbers registry system to make sure its definition is up to date. See RFC 7020 and draft-housley-number-registries (currently in last call). Please help review ongoing revisions and tell us if you have identified something that needs an update.

All these operations and the work supporting them is thanks to many committed professionals and volunteers at IANA, at the IAB IANA evolution program, and at the IETF. In particular, many volunteers are serving as expert reviewers of allocation requests. Thank you all for this work.

Jari Arkko, Chair of the IETF