On 12/16/2013 02:08 PM, Sean Turner wrote: > Forwarding on behalf on Steve Kent.
Ta. That did make it to the ietf list over the weekend and I replied, but whatever's gumming up the system for Steve also hit my reply;-) The IETF list is the right place for the discussion though rather than this list I think so if folks can wait a while until we unstick whatever's gummed up that'd be good. I'll send mail when I think that's done. (I figure there's some spam filter somewhere that's messing up or something, based on the ticket I saw generated.) S. > > 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 atta cks. 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 >> >> > > > > > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass > _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
