Hi Steve, A couple of points... On 01/02/2014 04:03 PM, Stephen Kent wrote: > I commented earlier to Stephen (off list) that BCP status seemed a bit > out of place for > a position statement, so I'm heartened to see others have a similar > concern. I concur > with the suggestion that this be (IAB stream) Informational. > > If published as Informational, I don't worry that this doc does not lay > out details > for what WGs are expected to do. At the behest of two IAB members, I am > working on a > doc that examines keying options for major IETF security protocols, and > discusses what > changes could be made to facilitate anonymous encryption as a fallback > from authenticated encryption. This is just one aspect of an overall > response to PM, but it will yield concrete proposals. Other folks are > working on an updated threat model doc. > > I have also noted that the document refers to PM as "indistinguishable" > from an attack, > which IMHO seems too polite. PM is effected via passive and active > wiretapping attacks, and > thus it IS an attack. I fully agree its an attack, but the point of indistinguishable is not to be polite, but rather to counter those who'd declare that it is not an attack because their government only ever do good things. That is also important. (And is the main reason for this response as its a new point, I think most of the stuff below is repetitive. > Tim Bray's message characterized the current draft > as saying "The perpass-attack draft says that pervasive monitoring has > the characteristics of an attack, ..." This suggests that a reader > doesn't interpret the text as saying that PM _is_ an attack. > We should avoid words that may lead a reader to believe that PM is > /equivalent/ to an > attack. Its easy to make a case that PM is an attack. I provided (off > list) feedback a > few weeks ago suggesting a different way to present the issues here, and > have updated that text: I think I responded to that (wasn't it on list too? but anyway...). > For many years the IETF security community has used an attack/threat > model [RFC3552] that envisions an adversary who can engage in passive > and active wiretapping at any point along a communication path. "a path" != many paths which is what we've now seen to be the case > We > commonly 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. Sorry, no - those are fine tools but they do not fully protect. For example S/MIME doesn't cover mail headers etc. > 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. If that last is meant to mean that we've already done enough then I don't share that view. > 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. I don't think that's defensible to be honest if you mean that we've long considered this scale and kind of attack and designed countermeasures accordingly. > 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. However, > RFC 3552 states: > > By contrast, we assume that the attacker has nearly complete control > ofthe communications channel over which the end-systems communicate. Again, that talks about "the" channel though. > This means that the attacker can read any PDU (Protocol Data Unit) on > the network and undetectably remove, change, or inject forged packets > onto the wire. This includes being able to generate packets that > appear to be from a trusted machine. Thus, even if the end-system > with which you wish to communicate is itself secure, the Internet > environment provides no assurance that packets which claim to be from > that system in fact are. > > This statement is pretty clear. I think the PM document needs to > explain, in a technical context, why pervasive monitoring is > qualitatively different, and thus merits this declaration by the IETF. I don't agree to be honest that that is needed. The fact of the attack is sufficient justification, compared to previous consideration of potential, not actually exploited, threats. > We ought not lead readers to believe that we have not considered passive > and active wiretapping as likely attacks in the past. I agree we did consider those. But in too limited a way as it turns out. > 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 our security model has always assumed. > > Some of the reported forms of pervasive monitoring have involved the > cooperation of or subversion of application service providers. This does > represent a major deviation from > the 3552 model: > > The Internet environment has a fairly well understood threat model. > *In general, we assume that the end-systems engaging in a protocol** > ** exchange have not themselves been compromised.* > > So we should acknowledge this as one asp[ect of PM that is different > from our threat model. However, 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. I strongly disagree with that last point. If we are ever to succeed with end-to-end email security for example (which I doubt), then that would have to encompass web-UAs as an inherent part of the overall system. Thus the security of the message store and submission server would be intimately related to any e2e confidentiality mechanism. And of course, we'd also need to counter spam somehow. Those are real requirements that show that our threat models do need to extend to some (but not all) aspects of host security. Regards, S. > > > > > >