|
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 |