Hi Wes, On 12/05/2013 05:26 PM, Wesley Eddy wrote: > On 12/4/2013 8:09 AM, Stephen Farrell wrote: >>> >>> It is good to have the consensus recorded in a document like this, >>> but I think the current draft is too vague to be usefully cited >>> and not just abused as a club against ourselves in the future. >> >> That's a fair comment, and there are at least two ways one could >> have gone about documenting the consensus - the "bare" approach >> taken in this draft or one where we included many more details >> of the threat and mitigations. >> >> ... > > > Ok; thanks for explaining, and I buy your motivations. Great. >>> - examples of instances and general cases where incorporating >>> mitigations is not a concern >> >> Hmm. Trickier. See below. >> > > I decided I can live without this, assuming there is at least some > clear recognition included that this BCP is intended to inspire the > IETF to think about pervasive monitoring in its protocol designs, > and do at least a few things to improve the state of the art, but > that it is not to be used as a club to force every new RFC to have > some mandatory-to-implement anti-snooping capability. > > I have a couple pieces of suggested text helping with this below > that you might consider if you understand my concern. > > As a start, I would suggest we be clear that this is not an attack > against the protocols, but rather against the users. It's not > causing the protocols to break, cease to function, give incorrect > results, etc. Well, it appears that that's not always the case. For example the explanation for the petrobas story [1] that's been offered does seem to involve protocol attacks, as does the quantuminsert stuff apparently. [2] Though of course, we don't have full information in any of these cases. [1] http://g1.globo.com/fantastico/noticia/2013/09/nsa-documents-show-united-states-spied-brazilian-oil-giant.html [2] http://arstechnica.com/tech-policy/2013/11/uk-spies-continue-quantum-insert-attack-via-linkedin-slashdot-pages/ That said, see below... > Mitigating it, then depends on assessing for a given > protocol (or deployment), who the users are and what they're using > it for. SNMP or NTP probably don't need mitigations for pervasive > monitoring, for instance. So, maybe it would be good to have a > clear statement in Section 2 like: > > "The target of pervasive monitoring attacks on the Internet is > not the Internet protocols themselves, but it is the users of > the protocols and the general utility of the Internet itself as > a medium of communications for specific applications that are Was there a bit garbled here? > "IETF RFCs already contain a mandatory 'Security Considerations' > section intended for discussion of the threats and available > mitigations relevant to the technologies described in the RFC. > As a type of potential attack, if pervasive monitoring is > relevant to a particular protocol, then the threat that it poses, > and the available mitigations are expected to be considered in > new IETF work. It is possible for certain technologies that > pervasive monitoring may not be viewed as a significant > threat."monitored. The protocol mitigations that are useful need to > be applied in ways that benefit the user-oriented applications, > and not necessarily other protocols in the network such as those > that may be used for network management, measurements, services > not linked to specific users and groups, control plane functions, > or some machine-to-machine or sensor communications, for instance. > IETF protocols need to assess the threat that pervasive monitoring > poses to their users and usage models on a case-by-case basis, and > implement appropriate mitigations, if any." Modulo the likes of [1,2] above I think some text along those lines could work. But I'd expect more discussion of this topic during IETF LC so its maybe a bit soon to push out a -03 with changes. I'll respond again to this mail later on when/if Jari tells me a new rev would be good or at the end of IETF LC at latest. (I'll keep a list of mails with text suggestions to go back to so I don't forget 'em at [3].) Sound ok? [3] http://down.dsg.cs.tcd.ie/misc/ppbcp-text-suggestions.txt Cheers, S >> Personally, I think its important that we not have this BCP have >> a massive get-out-of-jail clause that effectively neuters the >> impact we want it to have. And I'd be worried that the kind of >> text you're implying might have that effect. (Or did you mean >> something else?) >> >> But I do think this is an important discussion for the IETF LC. >> > > > Understood, and I agree. Probably, rather than a "get out of jail" > clause, what I think we should clarify is that this attack could > merely be considered another piece that's part of the security > considerations we already produce to explain on a case-by-case basis > what mitigations are available for the perceived threats of a given > protocol and its envisioned usages. > >>> As an example, would we expect MPLS to do anything about>>> pervasive monitoring or can new MPLS extensions keep moving >>> through the IETF without heeding to this BCP? >> >> I don't think this would affect MPLS extensions. (Although I >> did ask about that for the last one that went by the IESG:-) >> I'd love to see some more security mechanisms defined for MPLS. >> It'd be even better if those were likely to be defined. > > > Good that we agree! I think the text that I suggested above, or > something like it, would be helpful in making this clear. > > >>> It's also not clear to me whether it's intended to only apply >>> to protocol behavior "on the wire" or also to logging behaviors, >>> log formats, and other privacy-defeating factors of implementations. >> >> Both, IMO. But in many (though not all) cases our specs are >> silent about what has to be logged. >> > > > Right; and I guess my point is that if we want that to change, > then it should be mentioned here as one type of possible mitigation, > with corresponding tradeoff in the potential log usages by admins > that would need to be made on a case-by-case basis. > > I guess my real point is that when the protocols are privacy-preserving, > but the implementations aren't as careful, then it just shifts the > focus of the attack. > > >>> It specifically says that this is about privacy, and that requires a >>> lot more than just wire protocol work in order to create. I think >>> it would be good to mention these aspects, if this as a BCP will >>> really be referenced by the community in the future. >> >> Thanks for the thoughtful comments, > > > Thanks for writing up this document, so we can record consensus > beyond the simple hum statements. >