Re: [perpass] On the perfect passive adversary

[Stephen Farrell <[e-mail]>]

Hi Brian,

Great start, thanks!

On 09/04/2013 03:28 PM, Brian Trammell wrote:
>> I dusted this off and had a look at it last night, and it's in
>> worse shape than I'd thought as a coherent piece of work. But
>> completing it (to -00 I-D quality, at least) and publishing an I-D
>> -- especially given the scope of the conversation on this list --
>> seems like a great idea. I'll get started.
> 
> This is now available at
> http://www.ietf.org/id/draft-trammell-perpass-ppa-00.txt; the current
> revision works mainly on the definition of the threat model and the
> justification thereof. There are notes on what's observable and
> what's inferable and some initial guidance, but mainly the point of
> this revision is to determine whether we think it's a useful
> definition of the adversary and a good structure for guidance to take
> from that definition.

Can others on this list read and comment?

I'd say that suggested chunks of text for sections 5 and 6 would
be really great to get. If we can get a bunch of those then maybe
Brian can try to figure out how to organise 'em. (Or even better,
Brian plus whoever else is willing to help, and please let Brian
know if you're willing.)

> On review of RFC 6973, I see it addresses many of the points relevant
> to the threat posed by pervasive surveillance. The main difference is
> that its definition of surveillance (section 5.1.1.) makes an
> assumption that there is a given target of surveillance, which in
> pervasive surveillance is not necessarily the case: one "advantage"
> of pervasive surveillance is the ability to select targets after the
> fact of the communications capture. But in general, surveillance is
> an attack against privacy, and 6973 presents a very good framework
> for talking about privacy in a protocol design context. So, if we
> move forward with this document, I'd like to see it grow as an
> extension of 6973.

Sounds reasonable.

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.

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. 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?

Cheers,
S.

> 
> Best regards,
> 
> Brian
> 
> 
> _______________________________________________ perpass mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/perpass
>