> We know what to look for in a security review. We know somewhat less well, > but in a vague way what to look for in terms of privacy. I have no idea what to > look for to counteract pervasive surveillance. Just as an example, let's look at > a particular draft, and assume that it is ready for last call, and I need to write > the shepherd's write-up. A checklist of things to look for would be a useful addition to the draft, of course. But being realistic, we need to start with something much more generic, like: == - Does this protocol proposal provide for ways to hide the information being transmitted between two parties, if applicable? There are some instances where this is not applicable, such as routing protocols, or information about useable resources in CDNI. OTOH, there are many instances where this is applicable, such as specific orders for specific content within the CDNI realm. This question, by the way, is also a relevant security question. - What information must be protected in order to protect the confidentiality of the information being transmitted on the wire (if confidentiality is provided for in the first question)? This is something we should be thinking about anyway, but uncovering the assumptions is a useful exercise. Once we uncover a number of these assumptions, we could well find a common set of things that would then become BCPs, or impact the actual design and operation of systems. - What risks does this protocol pose in terms of metadata for an attacker who can access the packet flow (without specifically seeing the contents of those packets)? This might, at first, be speculative, but as our body of knowledge in this area grows, we will understand how to answer this question better. - Are there known ways for user to protect themselves against these risks? The point of this exercise would be to expose and think about the risks at hand first. Once we start thinking about what the risks are, maybe we can start fashioning protections against them. Right now, since we don't have a lot of information, it's best to start with thinking through the problem space. Once we understand the problem space better, we can start thinking about protection. == It's useful to note that privacy and security are often (but not always) intertwined, and to consider whether pervasive monitoring isn't just a subset of security issues. It took years for the community to develop a strong understanding of security. Things acceptable ten years ago are no longer acceptable, and things acceptable today might not be acceptable in ten years. Does that mean we give up? No. It means we start with broad general goals, and refine those goals over time as we explore the space. But to have that discussion, we need to decide that defense against pervasive monitoring is a worthwhile goal -- what I'm seeing on list right now is, "it's not a worthy goal because we don't know how to do it," and, "it's not a worthy goal because it's a political goal." I don't agree with either line of reasoning. > Also, what if we can hide more information out of a protocol, but at the > expense of another roundtrip or more processing power. Who gets to > balance the two goals? This same objection can be raised against data integrity, security, and even the correctness of a routing protocol's view of the physical topology. I could ask, "if it takes one more round trip, or a bit more processing, to make certain there are routing loops, then who gets to balance between the goals of no routing loops and the use of more processing power?" It's not a silly question -- I can imagine systems with such low packet rates that temporary routing loops with timed out packets are an acceptable solution against sending more control plane state, or using more processor. As another example, UDP verses TCP already makes a clear distinction between the willingness of the protocol to lose data on the wire or not verses additional state. The bottom line is this: to move forward, we must start someplace. Russ