Re: [perpass] On the perfect passive adversary

[Stephen Farrell <[e-mail]>]

Hi Brian,

On 09/05/2013 01:17 PM, Brian Trammell wrote:
> hi Stephen,
> 
> On 5 Sep 2013, at 12:32 , Stephen Farrell <[e-mail]>
> 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.

I'm not sure how that maps to my comment, sorry;-)

So maybe there's a thing to discuss here and maybe we need a bit
of new terminology.

Part (by no means all) of the work here I think it to consider
an attacker who:

1) passively records traffic from loads of places, including
some that are within any security boundary you care to
mention

2) can sometimes get access to e.g. an RSA private key and
then decrypt recorded TLS non-PFS traffic

For (1) and/or (2), the passive monitoring may have to have
been preceded or succeeded by an active break-in to the
nodes that subsequently become part of the monitoring network.
(As a side question - maybe we should consider how much
monitoring a subverted node could really do without breaking
or otherwise getting caught.)

But the attacker doesn't MITM the traffic we're trying to
protect.

Does that fit with your model? I hope so:-)


> 
>> 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. :)

Cool,
S.


> 
>> 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 
> [e-mail] https://www.ietf.org/mailman/listinfo/perpass
>