|
Folks, I've been unsubscribed from this list for a while because of mail filtering problems, which delayed my successful submission of these comments. I'll be reviewing the archives to see if there are messages to which I should reply, as part of this thread. ---- I have several concerns about this I-D (draft-farrell-perpass-attack-02.txt), as currently written. I do not support publication of the document in its current form. I think this document should include a clear description of what the IETF considers to be “pervasive monitoring” (PM) and how it differs form the informal security model we have (often implicitly) used for many years. Even the term “pervasive” needs to be clarified here, as there are two definitions one finds via a quick search: Merriam-Webster: “existing in or spreading through every part of something” Oxford Dictionaries: “… spreading widely throughout an area ..” If we mean to imply the former definition, we leave ourselves open to criticism by those who will argue that the monitoring of which we have been made aware is not literally through every part of the Internet. The second definition seems more appropriate, i.e., the sense of widespread monitoring. For many years the IETF security community has used an attack model that envisions an adversary who can engage in passive and active wiretapping at any point along a communication path. We commonly also attribute the ability to engage in MiTM attacks to such an adversary. Thus we have long believed that plaintext communications are vulnerable to passive wiretapping along a communication path if the content is not protected via encryption. We also have noted that, for staged delivery applications, e.g., mail, content is vulnerable to disclosure and modification in storage, especially en route. In response to this model we have developed a set of security protocols, (e.g., IPsec, TLS, DTLS, S/MIME, SSH, etc.) that can be used to protect transmitted content against passive wiretapping, based on use of encryption. These protocols also usually incorporate data integrity and authentication mechanisms, and, where appropriate, anti-replay mechanisms, to address MiTM attacks. Thus we have offered users and system designers a set of tools that address the adversarial capabilities based on our model. Having established this context, the next task is to explain why pervasive monitoring is significantly different from our long-standing model. The extent of such monitoring seems much bigger in scope than folks may have imagined, given that intelligence services of numerous countries have been identified as carrying on such monitoring. I think this document needs to explain, in a technical context, why what pervasive monitoring is qualitatively different, and thus merits this declaration. We ought not lead readers to believe that we have not tended to consider passive and active wiretapping as likely attacks in the past. Some of the reported forms of pervasive monitoring may have involved the cooperation of or subversion of an ISP or a telecom provider. This is not a qualitatively different form of attack from the generic passive wiretapping that out informal security model has always assumed. If we had articulated a threat model, in which we discuss adversaries, motivations and capabilities, we could either cite it here or cite the need to revise it based on recent revelations. Unfortunately, I don’t recall the IETF having ever published such a document :-). Anyway, here too it is important that readers be told that this way of effecting a passive wiretapping attack is not new, relative to the attack model we adopted long ago. The security focus of most of our security protocols has been protection of (application layer) content. A few security protocols, e.g., ESP, do offer optional traffic flow confidentiality security, but most do not. We have considered it a secondary concern, one that we believe most users would not see as important. Few of our security standards address confidentiality of communication metadata. So, this document could state that, in light of revelations about pervasive monitoring, the IETF will revisit our assumptions about the need for metadata confidentiality in our architecture. That might be a good justification for why pervasive monitoring is qualitatively different from our previous security model. The discussion of the term "attack" is necessary and useful. However, the document elects to refer to pervasive monitoring as one attack, even while acknowledging that it may require multiple, coordinated attacks of different sorts. This muddies the discussion, from a technical perspective. I'd prefer to see a discussion of the sort I outlined above, which is a bit more precise. While I agree that we ought to consider commercial privacy-violating activities at the same time that we explore countermeasures to nation-state and criminal violations of confidentiality, I believe that the document, as worded, conflates the two too much. Others have already commented that the term "mitigate" is overused here. I agree. We're going to develop new countermeasures, or remind folks of existing ones that are not being used. The use of these countermeasures will help mitigate attacks. Countermeasures are not all encompassing, contrary to what the text states. A protocol may have one or more vulnerabilities, in its design and/or implementation. An attack exploits one or more vulnerabilities. A countermeasure thwarts one or more types of attacks. It does not cause vulnerabilities to go away, nor does it thwart all possible attacks. The security considerations section says that privacy is the focus of the document, but does not define the term or provide a cite. I think security should be the primary focus of this document, emphasizing confidentiality, a term with a technical definition that typically used in well-written IETF security standards. If this document is going to stand as a declaration of principle in terms of an IETF response to pervasive monitoring, it needs to be carefully worded, technically accurate, and persuasive. Steve |