Jari,
On 1/19/14, 10:21 PM, Jari Arkko wrote:
But I think both the IETF and even me have learned over the years to do this
a bit better. And we need to continue to watch for this, or perhaps even come
up with better processes to defend against it.
I'm certain you've learned, Jari, although I do find myself repeating
one particular point:
Organizations DON'T learn; (some) people do. We can build processes
into organizations that help us to either not repeat the mistakes we or
others have made, or to exacerbate matters. In my experience it is
usually both, by the way, and you just hope that on the whole you've
made matters better.
Those of us who have learned, recognize the danger in the proposed text
to wedge a group, not simply because it could seemingly be used as a
sledgehammer as my earlier anecdote demonstrated (and I modified that
only slightly from what happened in ISMS), but because in this specific
circumstance we do not have a handle on the problem of pervasive
surveillance – yet.
What do I mean when I make that statement? It deserves justification
itself ;-)
We have in draft-farrell-perpass-attack a definition of what pervasive
surveillance is to us. We do not yet understand, however, what our own
capabilities and limitations are in defending against it. By negative
proof, had we this understanding the IAB would not be holding a joint
workshop with the W3C to gain it. There is barely even a framework by
which we talk about pervasive surveillance. We know that encrypting
data between the end user and a service somewhere off in the Internet
*may* provide some confidentiality, depending on the strength of the
encryption and a host of other factors. We have some understanding of
the performance impact of encryption.
On the other hand, there is everyone's favorite catch-phrase:
meta-data. That is, the 5-tuple in packets, the timing associated with
transmission and delivery, their size, and reasonable *engineering*
assumptions to make about where people can and will monitor. We also
only have limited understanding of the performance impact on any
mitigations to avoid masking these qualities.
We also have but a limited understanding of when it is valuable to
encrypt and when such encryption would be negated by factors that we
find impractical to eliminate, such as traffic and timing attacks or
when the existence of later communication itself reveals the same
information (e.g., DNS queries followed by a connect()).
We have a limited understanding of how much of pervasive surveillance
should be addressed at the upper layers versus the lower layers.
Encrypting once has a cost. Encrypting several times has several times
that cost. Encrypting end-to-end using the mechanisms we have today may
itself facilitate collection of metadata.
It should not be surprising that we don't know as much as we would like,
as we are still at the beginning of this process, just as we began the
process for security considerations so many years ago. Right now our
job is to figure all of this out. By "our" I mean that we all need to
be thinking about this problem, identifying risks, and discussing ways
to reduce them, while exposing what tradeoffs there are. That's why I
like *most* of Stephen's draft (all of it but one paragraph, in fact),
and why I'm glad Stephen is chairing the workshop in London.
And while I'm glad you understand how ADs can go too far, you also have
to recognize that we have been down this path before with others, and it
has been very rocky. Working group chairs are in a fine position to
make a muddle of things, and we (I speak of myself as well) do an even
better job of muddling when there is not community understanding of the
above problems.
And this brings us to Sam's proposed text:
Those developing IETF specifications therefore
need to consider mitigating PM when making these architectural
decisions and be prepared to justify their decisions.
We don't have the people or knowledge in place to reasonably evaluate
such justifications at this point. The person who proposed this text
proposed an example that may well have been in error. That is no fault
of his, really, because we are all learning. But let's not encourage
huge architectural swings when we don't yet have a handle on what advice
should be given. Discussion and careful consideration are important
now. Getting ideas out there is good. Testing them is great! Nailing
some of the obvious bits, like asking why certain information is
exposed, is fantastic. Discussion about protocol selection is excellent.
But the words that are quoted are stronger than that. They can be used
by chairs and others to shift the burden onto the proponent of a
proposal when we have no shared understanding of what needs to be
addressed. That's too high a bar and will lead to well-intentioned –
but wrong – engineering decisions.
Eliot