hi Stephen, On 5 Sep 2013, at 12:32 , Stephen Farrell <[email protected]> wrote:
> Two initial comments on the -00 version:- > > 1) I guess the scope here of purely considering passive monitoring > is useful enough, but maybe we need to think about that some, if > we consider it likely that some of the monitoring is being done > from compromised hosts. While that attacker isn't actively MITMing > application traffic, they are sort of active in that they're > putting their code onto devices, and some of those can be in what > might otherwise be considered "trusted" parts of the network. Maybe > a good scope might be to assume here that the endpoints are not > compromised but that e.g. routers, switches, DHCP servers etc. > might be part of the monitoring network. Would that be worth > thinking about for this document or would that be better left > out, or left for another document? I'm not sure but would be > interested in folks' thoughts. There's a very minor difference in terms of detectability between: (1) someone who can look at any of the packets on their way into and/or out of any of the endpoints on the network between the initiator and recipient, and (2) someone who can do that plus can observe internal state / stored messages at any of the intermediate systems. The main practical difference is that confidentiality from eavesdropping from adversary (2) requires end-to-end encryption, while transport encryption is sufficient against adversary (1) assuming you use it everywhere. Since we're already discussing this on the list, it seems like we believe the additional threats in (2) to be in scope. I think that if we assume any capabilities beyond that (e.g., DNS cache poisoning, selective modification of traffic at an intermediate system), we're not really talking about surveillance anymore. > 2) While I fully agree that the "benefits" of pervasive monitoring > ought be out of scope, I'm not sure I agree that analysis of the costs > of pervasive monitoring ought be entirely out of scope. Presumably > our goal here includes helping protocol designers increase those > costs, hopefully to the point where Yoav is no longer in the top > 100k cost-effective targets:-) So some consideration of the costs > of monitoring would seem to be called for. The text here is poorly phrased; what I want to say is "we assume this to be bad a priori and therefore advice protocol designers to do the following to avoid it; we're not going to examine the (social) cost-benefit analysis." i.e., we agree completely here. :) > We can't of course consider > that in detail, but ruling it out of scope seems a bit wrong. Maybe > we can consider the kinds of protocol features and deployment > choices that would noticeably increase that cost, without getting > into an analysis of what those costs might be? Indeed, the document already kind of does this by noting if you want packets, you need to buy new 4TB disk per 10G link every 50+ minutes. Cheers, Brian _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
