Re: [perpass] On the perfect passive adversary

Brian Trammell <> Thu, 05 September 2013 12:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A63411E8190 for <>; Thu, 5 Sep 2013 05:17:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1g1AVkItu26P for <>; Thu, 5 Sep 2013 05:17:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E607111E818F for <>; Thu, 5 Sep 2013 05:17:36 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 163F3D9303; Thu, 5 Sep 2013 14:17:36 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id 3xA0asIfTB9W; Thu, 5 Sep 2013 14:17:35 +0200 (MEST)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by (Postfix) with ESMTPSA id D071BD9300; Thu, 5 Sep 2013 14:17:35 +0200 (MEST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Brian Trammell <>
In-Reply-To: <>
Date: Thu, 5 Sep 2013 14:17:34 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Stephen Farrell <>
X-Mailer: Apple Mail (2.1508)
Subject: Re: [perpass] On the perfect passive adversary
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Sep 2013 12:17:43 -0000

hi Stephen,

On 5 Sep 2013, at 12:32 , Stephen Farrell <> 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.