Subject: Re: [perpass] On the perfect passive adversary

From: Brian Trammell <[email-masked]>
Date: Wed, 4 Sep 2013 16:28:25 +0200

hi Stephen, all,

One update, inline...

On 19 Aug 2013, at 9:00 , Brian Trammell <[email-masked]> wrote:

> hi Stephen, all,
> 
> Yeah, sorry for the giant multitopic rant. I'll split this out into a few threads to continue...
> 
> On Aug 18, 2013, at 11:47 PM, Stephen Farrell <[email-masked]> wrote:
> 
>> 
>> Hi Brian,
>> 
>> First, thanks for the thoughtful post. You make some good points.
>> A few responses below. Might be better to follow up in separate
>> mails, since you raise too many interesting points probably:-)
>> 
>> On 08/18/2013 07:45 PM, Brian Trammell wrote:
>>> Greetings, all,
>>> 
>>> On the floor of my home directory, there are notes for a paper we
>>> never finished called "The Perfect Passive Adversary"; intended as a
>>> survey of the state of the network security and measurement
>>> literature and practice to explain what is possible if one assumes an
>>> adversary which can (1) observe every packet of every communication
>>> at every point within a network but (2) does not have access to the
>>> endpoints beyond the network interface (i.e. no keyloggers, and no
>>> bulk access to user data at a service provider) and (3) cannot
>>> influence packet forwarding. It grew to be rather too wide in scope
>>> and too paranoid in tone to have a realistic chance at publication,
>>> so we dropped it, which in retrospect seems a silly choice.
>> 
>> So publish it! As an I-D even:-) But if you have a version that
>> you're happy to share, that'd be great to see.
> 
> 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.

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.

Best regards,

Brian

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 05 Sep 2013 11:32:17 +0100

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

---

From: Brian Trammell <[email-masked]>
Date: Thu, 5 Sep 2013 14:17:34 +0200

hi Stephen,

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

> 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

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 06 Sep 2013 21:04:02 +0100

Hi Brian,

On 09/05/2013 01:17 PM, Brian Trammell wrote:
>> 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 
>> 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. 
>> 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.
> 
> (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:-)

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

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
>