Forwarding on behalf on Steve Kent. spt
> -------- Original Message -------- > Subject: My comments on aft-farrell-perpass-attack-02.txt seem to post > here, so ... > Date: Wed, 11 Dec 2013 11:13:20 -0500 > From: Stephen Kent <[email protected]> > To: perpass <[email protected]> > > 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. > > When pervasive monitoring is effected via passive wiretapping, or a mix of > active and passive wiretapping (e.g., using packet injection attacks) it is > not a new class of attack. It is precisely what we have long considered when > designing security protocols. Thus I believe this document should include > comments of the sort noted above, to help establish a context for this > declaration about “pervasive monitoring”. > > 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. > > Some of the reported forms of pervasive monitoring have involved the > cooperation of or subversion of application service providers. If attacks > take place at a point after which IETF protocols terminate, then it seems to > be largely outside of our purview as a protocol-focused standards > organization. For example, if I access e-mail via a web interface at an MSP, > IETF security standards largely do not seem to apply to vulnerabilities > associated with storage of the mail at the MSP; my mail can’t be protected > e-t-e because I’m not using S/MIME to read the mail. I can use TLS to protect > the HTTPS session via which I access messages, and we can recommend that TLS > be used with SMTP to deliver the mail to the MSP, but that seems to be the > limit of our security protocols. So, again, cooperation or coercion of app > service providers is not a new, unanticipated form of attack. > > I described this example because I think this document should acknowledge, > explicitly, that there are limits to the scope of what the IETF can/should do > in responding to pervasive monitoring. The IETF is not responsible for all > aspects of Internet security. To first order, we develop protocols and thus > we should focus on security mechanisms offered by implementations of those > protocols. We may choose to issue guidance that goes beyond our standards, > but we ought to be very careful in so doing. > > I believe this document should include a discussion about what we perceive to > be the scope of IETF standards for security in the context of pervasive > monitoring. You could note, for example, that the IEEE is responsible for > encryption standards for WiFi. ETSI and 3GPP have been responsible for over > the air encryption standards for cellular devices. The W3C may be the more > appropriate venue for some web security topics, e.g., beyond the scope of > HTTPS. I realize that we do, sometimes, generate RFCs that call for > security-relevant actions by hosts, e.g., random number generation guidance. > And we sometimes provide implementation guidance in support of security. But > these documents don’t address host security as their primary focus, so there > do seem to be limits to what we consider to be in scope. > > 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 > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
