Last week the IETF held their face-to-face meeting in Tapei, Taiwan and privacy was on the agenda for discussion (among many other topics, of course). As reported earlier I am involved in two meta-documents that should help others in writing about privacy properties of Internet protocols.
The first document is a terminology document: draft-hansen-privacy-terminology-03.txt
A question I typically receive is “How does this relate to other privacy terminology efforts in other organizations?” When I started with the work on draft-hansen-privacy-terminology-00.txt the most complete terminology writeup was the work by Marit Hansen and Andreas Pfitzmann, with early versions of their writeup from before 2000. I called Marit and asked her whether she and Andreas would be OK with bringing the work to the IETF after I had realized that the IETF document authors regularly write about privacy properties but they all use different terminology. draft-hansen-privacy-terminology-00.txt was more or less a translation of the most recent MS Word-based terminology writeup by Marit & Andreas. It was a lot of work to translate the long document into the IETF ASCII format.
Guess what comments I received?
- This is too long.
- This is too scientific.
- There are too many terms – nobody is going to remember them.
While the terms Marit and Andreas introduced were a great match for the academic industry the regular IETF participants needed something different. If you believe that the audience matters for any form of document and presentation then you know what I am talking about.
When providing guidelines to engineers (rather than to lawyers, which many other privacy terminology publications seem to be aiming for – although they do not state it) it is important to keep the terms and the presentation relevant to them. Sounds easy; isn’t it? It is a bit tougher when you actually have the document in a text editor in front of you.
In a step-by-step fashion I have changed the writeup of the document to what it is today – a short and concise document. Still, it is by far not yet finalized. The feedback I got during this IETF meeting showed it. While I have received a lot of positive feedback various folks noticed bugs here and there.
Let me pick two examples from my presentation to the SAAG participants.
- Here is the definition of a pseudonym: “A pseudonym is an identifier of a subject other than one of the subject’s real names.” Sounds good but protocols do not really mandate a real name to be used to begin with. They contain a field, such as the ‘name’, but do not mandate that the text that it put in there is actually the subject’s real name. In fact, most protocols (if not all) work just fine when you put something else in there. One could argue that IETF protocols are using only pseudonyms. This is clearly an example of how the protocol engineering is different from the deployment of the finished protocol. Should we focus on other properties instead, such as the ability to protocols to mint identifiers and to recycle them?
- In the definitions we talk about the “attacker’s perspective“. Most people felt uncomfortable with the term attack in the case when we refer to the intended communication participant. For example, when I make a call to a friend but he leaks some conversation details then it is difficult to call him an attacker. The same is true for many other user to Web service provider interactions. But how should we call these entities?
These questions and a couple of others will have to be addressed in the upcoming draft update and hopefully we will be able to re-submit it as draft-iab-privacy-terminology-00.txt (if the approval process of the IAB completes within the expected time-frame).
The second document is the privacy considerations document: draft-iab-privacy-considerations-01.txt
This document is the main deliverable of the IAB privacy program and tries to offer guidance to engineers to write privacy related text in IETF documents when designing Internet protocols. It should also offer guidance to the members of the IETF privacy directorate. This directorate is a per-invitation only group that reviews IETF specifications with a focus on privacy. These reviews are typically triggered by the IETF security area directors during the IESG review phase.
As one can imagine, it is not easy to come up with useful guidance for those engineering systems. So, we looked at what was available to us. Here is a brief summary:
- Privacy Principles: There are lots of privacy principles published over the years. The most well-known principles are the Fair Information Practices (FIPs) but there are many others. They all make sense, sound intuitive, and great. The problem with them is that they are so high level that they do not provide a lot of guidance for engineers.
- Then, there are Privacy Impact Assessments (PIAs). They are also useful but they focus on those who deploy and are not ideally suited for engineers who design protocols and architectures. These engineers typically try to develop more generic systems and try to create building blocks that are not only useful for one single deployment.
- Finally, there are privacy engineering guidelines written by scientists for other scientists. Two good examples come to my mind, namely
(a) “Engineering Privacy” by Sarah Spiekermann, and Lorrie Cranor, and (b) “Engineering Privacy by Design” by Seda Guerses, Carmela Troncoso, and Claudia Diaz. While their work is great it assumes that those who design systems are in control of every component. This may be true for some clean slate designs but certainly an assumption that does not hold true for engineers in the IETF. There, the existing deployment has to be taken into consideration and a single protocol developed just forms one piece of larger distributed system. For this reason most engineers try to aim for a more generic design rather than developing for a purpose-built system suitable only for a single task. I tried to explain this issue in more detail in my writeup for the Berlin Group and as input to the Dagstuhl Online Privacy workshop, which took place February this year.
Having provided these three examples of why we couldn’t just reference existing work a group of people in the IAB looked into the way how we dealt with privacy in IETF protocols so far (in form of privacy reviews). Have a look at these example reviews; they took some time and I believe they are fairly useful examples. Those reviews helped to form the existing privacy guidelines found in Section 4 of draft-iab-privacy-considerations-01.txt.
I had used earlier versions of the guidelines in documents I worked on and I will certainly do that again for the current draft version to see whether they require further fine-tuning. I would obviously appreciate it if someone else tries to do the same.
Independently of these two documents described in this blog post there is lots of other IETF work that deserves more privacy discussion input. I will write about that topic later.
In any case, if you have feedback on these two documents please drop a mail to the IETF privacy discussion list.