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