Hi Steve, Thanks for the comments. (Steve sent me an earlier version of his comments, so my responses are partly pre-cooked based on our earlier off-list discussion.) As you'll see I don't agree with most of what I guess you'd like to be done. The main problem I'd have with your suggested approach is the significant number of ratholes into which we'd be required to delve. And I don't see any benefit accruing from any of those to be honest. Nor from the huge delay that'd ensue. On 12/15/2013 08:31 PM, Stephen Kent wrote: > 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. I think the word pervasive is entirely clear and the draft does define pervasive monitoring. I'm sure the definition in the draft can be improved and concrete suggestions are welcome. > For many years the IETF security community has used an attack model that Yes we have. Recent events would appear to indicate though that the attacker here has significantly increased deployment within much more recent times, and we should respond to that. > envisions an adversary who can engage in passive and active wiretapping > at any point along a communication path. Yes. But "at any point" != "at many points" and we didn't properly consider the latter IMO. > 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 Again "a path" != "many paths" which appears to be the case. And that's relevant e.g. see this thread [1] on the perpass list. [1] http://www.ietf.org/mail-archive/web/perpass/current/msg01387.html > 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. As you note below, those leave some meta-data available for monitoring. But S/MIME in particular leaves very significant monitoring potential since it doesn't protect important header fields such as To, From and Subject. We have also not succeeded in getting these security protocols used sufficiently widely to counter the level of attack that is now clearly happening. There are many reasons for that that are outside the IETF's control, but we really do need to think some more about those that are not outside our control. I don't think its credible for us to say or imply that the IETF or the security area of the IETF has done wonderfully well, and all that's needed is for people to listen more to us and go use what's already been defined. > These protocols > also usually incorporate data integrity and authentication mechanisms, > and, where appropriate, anti-replay mechanisms, to address MiTM attacks. We have interesting debates ahead of us in terms of figuring out whether or when we were wrong in requiring authentication mechanisms be used before a protocol can get confidentiality. I think a lot of that will turn out to be 20-20 hindsight, but that we'll decide that we overdid things in some cases resulting in security protocols being too hard to deploy. I say 20-20 hindsight, because I do think that many of the designs done in the mid-late 1990s were fit for purpose then. With a much bigger Internet, now used for more things, its not a huge surprise we need to revisit some assumptions that were quite reasonable 15 years ago. > Thus we have offered users and system designers a set of tools that > address the adversarial capabilities based on our model. We do have some great tools in the toolbox. But I think we'll need more and some changes to current ones, e.g. to make them more easily deployable and get better usage. And all of that is for the future, and is the kind of work that this BCP is intended to help cause happen. The BCP itself cannot and should not be expected to include the details since many of them are tricky. And by details I mean both new tools and the analyses that are needed to figure out changes that might help with current tools. > > 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". I don't agree. I don't think we need that and do think we'd run into a large number of ratholes if we try. But it could be a good thing to add a sentence referring back to 3552 since that does contain a lot of that kind of text. I think that could be added to the end of the 1st para of section 2 where we say that we'll deal with this threat in the same way we deal with others. Say something like: OLD: The IETF also has consensus to, where possible, work to mitigate the technical parts of the pervasive monitoring attack, in just the same way as we continually do for these and any other protocol vulnerability. NEW: The IETF also has consensus to, where possible, work to mitigate the technical parts of the pervasive monitoring attack, in just the same way as we continually do for these and any other protocol vulnerability. [RFC3552] provides some useful background and guidance on how the IETF handles security considerations, but doesn't specifically consider the pervasive monitoring attack, for example by considering the security of meta-data that is exposed even if the security mechanisms described are used. > Having established this context, Again, I don't think establishing that context is necessary, and is a potential source of ratholes. > 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. I do not agree that this document needs to explain why pervasive monitoring is qualitatively different. This document merely needs to record our consensus that it is an attack that we will try to mitigate. If however, there are ways in which pervasive monitoring is qualitatively different that will be a good discussion to have e.g. at the workshop in London and beyond. > We ought not lead readers to believe that we have not > tended to consider passive and active wiretapping as likely attacks in > the past. We have not considered the pervasive monitoring attack in the past. If you can find RFCs where we explicitly did, I'd love to get pointers to those. An assertion that that was properly considered for even e.g. IPsec (which is probably closest to being true) would also I'd say cause needless and unproductive controversy. (BTNS anyone? ;-) I think we're far better off not spending cycles debating who did what right or wrong in the past, but rather in working on the problems we face today and tomorrow. > 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. I don't agree that that is needed. > 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. Does that assume that S/MIME is an adequate e2e protection against pervasive monitoring? If so, I don't agree. And one could envisage the IETF having a role if say there were to be work done on how to turn on S/MIME or PGP (or something better) even while using a web UA. Indeed any e2e mail security solution developed today would take support for web UAs as a core requirement. That wasn't the case when S/MIME and PGP were developed, but it sure is today. > 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. Disagree. See above. > So, again, cooperation or coercion of app service providers > is not a new, unanticipated form of attack. True. However, the scale of the problem is new, especially now that so much e.g. mail is centralised in a few providers. > 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. I agree. And in fact it explicitly does that already. We could I guess wordsmith that some more but I doubt we'd improve things much. > 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 agree that care would be needed when doing that. But this document does not do that - it does focus only on IETF work. > 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. That sounds to me like another potential rathole, and one from which we'd emerge with little or no benefit gained. > 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. Interesting idea and tempting, but I suspect we'd be irritated if some other SDO told us to get our act together so I think while you're right, that'll have to be done liaison-wise and/or via chats between people. I've been chatting with W3C folks (as have others) and they're starting to do stuff now. Not sure about IEEE but it'd be a fine thing if they could e.g. find a way to make MAC addresses less identifying, though that's tricky. Might be a thing to ask them about next time we have a liaison call. (Security hasn't been a topic for recent IETF/IEEE liaison calls, but maybe it should be.) As for 3GPP, I guess I'd be surprised but pleased if they had much interest. > 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 inscope. Again, I don't see that there's anything related to that in this BCP, and I don't think there should be. If we dived into some of the ratholes above there might be but not going there seems like a much more effective way to handle that to me. > The security focus of most of our security protocols has been > protectionof (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. Good point. Something along those lines might fit well, and not take us down a rathole. I added that to the text around the 3552 reference above, it seems to fit well as a qualification that the reader following the reference ought keep in mind. > 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 disagree. Its pretty clear. Feel free to point out what is confusing. > 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. I don't believe that, nor do you say why you do. > Others have already commented that the term "mitigate" is overused here. I don't recall that comment actually. Can you give me a pointer in case I've missed it? > 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. The text does not state that. If it did, it'd be wrong. But if you want to suggest some wordsmithing please do. > 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. I agree. But don't see any change needed. > The security considerations section says that privacy is the focus of > the document, but does not define the term or provide a cite. Hmmm. That seems entirely wrong. Don't you think 6973 is a citation? But do feel free to suggest more/better ones. > 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. Putting the emphasis on any particular mitigation would be wrong here. We should not make the mistake of assuming that confidentiality is the answer, no matter what the question. > > 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. I agree. And think it is. But sure it can be improved and we've accumulated some edits that will be made during last call. I don't however think that we should make most changes along the lines you suggest above. And I strongly believe that we should avoid ratholes. Regards, S. > > > Steve >