Subject: draft-farrell-perpass-attack architecture issue

From: Stephen Farrell <[email-masked]>
Date: Mon, 13 Jan 2014 19:28:41 +0000

Hi all,

Sam raised an issue that we didn't handle in the -03
version. [1] After some offlist mail between us I think
that his issue would be resolved with a change such as
the one below, adding a new paragraph.

Should text like this be added to the document? FWIW,
I'd be ok with that, or with leaving this out and for
a slightly longer discussion of the topic to be part
of Richard et al's problem statement draft. [2]

Please say what you think.

The proposed change in OLD/NEW form is:

OLD

   Those developing IETF specifications need to be able to describe how
   they have considered pervasive monitoring, and, if the attack is
   relevant to the work to be published, be able to justify related
   design decisions.  This does not mean a new "pervasive monitoring
   considerations" section is needed in IETF documentation.  It means
   that, if asked, there needs to be a good answer to the question "is
   pervasive monitoring relevant to this work and if so how has it been
   considered?"

NEW

   Those developing IETF specifications need to be able to describe how
   they have considered pervasive monitoring, and, if the attack is
   relevant to the work to be published, be able to justify related
   design decisions.  This does not mean a new "pervasive monitoring
   considerations" section is needed in IETF documentation.  It means
   that, if asked, there needs to be a good answer to the question "is
   pervasive monitoring relevant to this work and if so how has it been
   considered?"

   In particular, architectural decisions, including which existing
   technology is re-used, significantly impact the vulnerability of
   a protocol to pervasive monitoring.  For example, if a protocol
   uses DNS to store information, then a passive attacker can observe
   the queries made to the DNS. Those developing IETF specifications
   therefore need to consider mitigating pervasive monitoring when
   making these architectural decisions and be prepared to justify
   their decisions.  Getting adequate, early review of architectural
   decisions including whether appropriate mitigation of pervasive
   monitoring can be made is important.  Revisiting these architectural
   decisions late in the process is very costly.

Thanks,
S.

[1] https://www.ietf.org/mail-archive/web/ietf/current/msg84996.html
[2] https://tools.ietf.org/html/draft-barnes-pervasive-problem

---

From: Scott Brim <[email-masked]>
Date: Mon, 13 Jan 2014 14:36:38 -0500

>    decisions late in the process is very costly.

Not bad. FYI what got me started on privacy was when ILNP said
"Mobility? No problem, just keep your location updated in DNS".

This all looks good to me except for grammar in the first sentence:
"including which existing technology is re-used".  Do you mean
"including decisions on which existing technology to re-use"?
"including decisions where existing technology is re-used"?

Thanks ... Scott

---

From: Stephen Kent <[email-masked]>
Date: Mon, 13 Jan 2014 15:27:20 -0500

Stephen,
>     decisions late in the process is very costly.
Although I like including a good example, I worry that this example is
too narrow and may send the wrong message. I suggest using the rest of
Sam's text for para 2, but eliding the DNS example. (I say this because
a protocol may make use of the DNS in a way that I would not consider
to be "storing" info there, on behalf of the protocol.)

Steve

---

From: Dave Crocker <[email-masked]>
Date: Mon, 13 Jan 2014 12:32:39 -0800

> to be "storing" info there, on behalf of the protocol.)

For a topic this broad and this poorly understood -- poorly understood 
by me and folk like me, at least -- what I take from this exchange is 
that examples either need to demonstrate the richness and even nuance of 
concerns or else they need to be absent.

That is, there need to be a collection of examples that touch different 
parts of the space -- sufficiently to show how varied and challenging 
the space is -- or else the level of detail represented by examples 
needs to be deferred to a discussion piece.

Single, simple examples make sense for narrow, simple issues.  This one 
ain't that.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Sam Hartman <[email-masked]>
Date: Mon, 13 Jan 2014 16:04:52 -0500

I'd prefer to have an example present if we can come up with one, but
will be OK if we discover that's too hard.
I do beleive the example is the weakest part of the text I proposed

---

From: Hector Santos <[email-masked]>
Date: Mon, 13 Jan 2014 16:12:47 -0500

>     decisions late in the process is very costly.

I agree with others that the example probably needs work. Its not 
generic enough.  If this is a BCP, that specific example can come back 
latter in debates as to what level of security/privacy needs to be 
considered, i.e. are we worry about storage (private data leaks) or 
the insecure transmission methods or both?   So IMO, keeping it makes 
the argument for informational status stronger.

-- 
HLS

---

From: Eliot Lear <[email-masked]>
Date: Mon, 13 Jan 2014 22:19:51 +0100

Hi Stephen,

I oppose the change for reasons I state below:

>    decisions late in the process is very costly.

While the sentiment isn't bad it's a bit of a truism, and the example
isn't good, since in large part the information shared through DNS can
often and more accurately (albeit not always) be gleaned through other
means (flow state, for instance).  Once again I return to what I have
said previously: developers of specifications should examine this on a
case by case basis (at least for now), weigh whatever tradeoffs they
uncover, and move forward from there.

Eliot

---

From: Scott Brim <[email-masked]>
Date: Mon, 13 Jan 2014 16:25:11 -0500

OK, if we're going to get stuck on the example, we should take it out.
As Sam said, it's the least necessary part.

I still think the phrase in the first sentence "including which
existing technology is re-used" could be better.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 14 Jan 2014 14:33:15 -0500

>>>>> "Scott" == Scott Brim <[email-masked]> writes:

    Scott> OK, if we're going to get stuck on the example, we should
    Scott> take it out.  As Sam said, it's the least necessary part.

    Scott> I still think the phrase in the first sentence "including
    Scott> which existing technology is re-used" could be better.

Yeah, let's lose the example at this point.

I disagree with Eliot: I don't think the general statement is a truism
especially not in a BCP.
In particular we're:

* saying what point in the process you need to evaluate the
  architectural implications on your ability to   mittigate pervasive
  monitoring

* Reminding people to get appropriate review 

* Indicating that PM needs to be considered at the architectural
  decision level, not just late in the process.

I believe all that is important in a BCP, and strongly support that sort
of statement being in a BCP now.
I definitely don't want to see the example used as an argument against
BCP so let's lose it.

---

From: Scott Brim <[email-masked]>
Date: Tue, 14 Jan 2014 14:41:04 -0500

> I definitely don't want to see the example used as an argument against

Yes, all true.

Please drop what I said about ambiguity in the first sentence. It's
not worth stopping progress for.

Are we ready to move forward?

Scott

---

From: Eliot Lear <[email-masked]>
Date: Tue, 14 Jan 2014 20:45:38 +0100

> I disagree with Eliot: I don't think the general statement is a truism

To test if it's a truism, replace perpass with anything else and see
what design consideration should be examined late in the process.

Eliot

---

From: Scott Brim <[email-masked]>
Date: Tue, 14 Jan 2014 16:02:34 -0500

Sorry, Eliot, I didn't understand it either, particularly about lateness.

The point of the paragraph is to declare PM to be something that
should be considered at architecture time, i.e. early in the design
process, when the fundamentals are worked out. (Personally I would
prefer to make it a general statement about "privacy", not just PM,
but I'm glad to get whatever I can.)  The statement is not that
architectural issues need to be considered early (that just begs the
question), but rather that PM needs to be considered an architectural
issue.

Scott

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 14 Jan 2014 21:45:31 +0000

On Jan 13, 2014, at 11:28 AM, Stephen Farrell <[email-masked]> wrote:

>  It means

Just a thought - that might be a good question to add to the shepherd's report.

In that case, I might suggest a minor change, however. We discuss "Pervasive monitoring" in a "big brother is watching" sense, and (at least in perpass) concern ourselves with data that could have been hidden had encryption or some other code used. I'll argue that, however dreadful Big Brother might be, location-based services can be a lot scarier.

http://online.wsj.com/news/articles/SB10001424052702303453004579290632128929194?mg=reno64-wsj&url=http%3A%2F%2Fonline.wsj.com%2Farticle%2FSB10001424052702303453004579290632128929194.html

Data point: a lot of these operate without specific knowledge of an individual, but can. For example, the article talks a lot about aggregating information and providing it without identifying information. However, it goes on to say that if someone logs into a service using, for example, a Facebook identifier, they can remain identified to the system as they wander around in it. The messages themselves contain no identifying information per se, but they contain information that can be correlated back to that login. And the login wasn't "data in flight", it was "creating state with a service at rest".

So the question in the shepherd's report should not be "tell me you thought about the EU Data Retention Initiative and whether your protocol's data identifies an individual". It should be "what personal, equipment, or session identifiers, encrypted or otherwise, are carried in your protocol? How might they be correlated with offline data or otherwise used to infer the identity or behavior of an individual?"

---

From: Scott Brim <[email-masked]>
Date: Tue, 14 Jan 2014 17:09:36 -0500

> So the question in the shepherd's report should not be "tell me you thought about the EU Data Retention Initiative and whether your protocol's data identifies an individual". It should be "what per…

The main problem is that: privacy issues are deeper than that, the
question could be misunderstood without a larger context, and there's
already a set of documents discussing most of that larger context (RFC
6973, the perpass problem statement draft, etc.).

The Document Shepherd Write-Up currently doesn't reference security
guidelines directly. Instead of asking a few specific questions in the
shepherd's writeup as you suggest, consider adding the privacy/perpass
docs to BCP 72 (which already includes RFC 3552) as they are approved,
and then optionally add a question to the shepherd's writeup that
refers to it, in order to emphasize the increased attention to the
issue.

Scott

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 15 Jan 2014 06:46:42 +0100

Thanks Fred,

The draft must include your questions, so that it can become a clear
initial-BCP, or a clear plan draft. IMHO, the initial-BCP draft is not
clear or not direct if it does not mention your questions,

AB

On 1/14/14, Fred Baker (fred) <[email-masked]> wrote:
> In that case, I might suggest a minor change, however. We discuss "Pervasive
> monitoring" in a "big brother is watching" sense, and (at least in perpass)
> concern ourselves with data that could have been hidden had encryption or
> some other code used. I'll argue that, however dreadful Big Brother might
> be, location-based services can be a lot scarier.
>
> Data point: a lot of these operate without specific knowledge of an
> individual, but can. For example, the article talks a lot about aggregating
> information and providing it without identifying information. However, it
> goes on to say that if someone logs into a service using, for example, a
> Facebook identifier, they can remain identified to the system as they wander
> around in it. The messages themselves contain no identifying information per
> se, but they contain information that can be correlated back to that login.
> And the login wasn't "data in flight", it was "creating state with a service
> at rest".
>
> So the question in the shepherd's report should not be "tell me you thought
> about the EU Data Retention Initiative and whether your protocol's data
> identifies an individual". It should be "what personal, equipment, or
> session identifiers, encrypted or otherwise, are carried in your protocol?
> How might they be correlated with offline data or otherwise used to infer
> the identity or behavior of an individual?"
>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 15 Jan 2014 08:00:55 +0000

On Jan 14, 2014, at 9:46 PM, Abdussalam Baryun <[email-masked]> wrote:
> The draft must include your questions, so that it can become a clear initial-BCP, or a clear plan draft. IMHO, the initial-BCP draft is not clear or not direct if it does not mention your questions,

I'm just one. But from my perspective, it must not only ask them, but answer them or outline how the answers might be arrived at.

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 15 Jan 2014 13:36:26 +0100

I agree with you but it seems like many ADs want this draft passed as BCP
(without stating it as initial or clear directions), so I may see many
others want to state directions, not much details, therefore, making strong
principle questions will make the initial draft effort clear and understood
to all participants and all directors ( I think that directors should work
more hard to make directions in the draft more clear to community).

AB

On Wednesday, January 15, 2014, Fred Baker (fred) wrote:

>
> On Jan 14, 2014, at 9:46 PM, Abdussalam Baryun <[email-masked]<javascript:;>>
> wrote:
> I'm just one. But from my perspective, it must not only ask them, but
> answer them or outline how the answers might be arrived at.
>

---

From: Sam Hartman <[email-masked]>
Date: Wed, 15 Jan 2014 11:40:22 -0500

>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:

    Eliot> On 1/14/14 8:33 PM, Sam Hartman wrote:

    >> I disagree with Eliot: I don't think the general statement is a
    >> truism especially not in a BCP.

    Eliot> To test if it's a truism, replace perpass with anything else
    Eliot> and see what design consideration should be examined late in
    Eliot> the process.

I absolutely agree that general guidance of this form would be valuable
either in some general security BCP that the other security BCPs
reference or restated in the security BCPs.  Its lack in 4107 and BCP 61
is something that causes me problems as a WG chair and cause significant
difficulty for me as an AD.

we're not working on such a BCP now, so I'm trying to add the advice I
need to this BCP in order for it to work for me as a WG chair and
document author.

It's not so much a truism that we all agree to it.  I've definitely
worked with WGs that didn't want to consider these sorts of issues when
choosing technology and didn't seem to agree that they had to.  I do
hope it's enough of a truism that we can agree to say it in a consensus
document.  The idea that we should not say something because we agree
with it confuses me greatly.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 15 Jan 2014 09:00:49 -0800

On 1/14/2014 1:02 PM, Scott Brim wrote:
> process,

Over the years, my own interest in the potential influence of security 
concerns in protocol development work has been less due to security 
benefits -- not that those aren't important -- but due to the increased 
discipline it ought to require in the development process.

Note that I said 'ought'.  Working groups are pretty erratic about doing 
architecture initially, then followed by details.  Not never, but also 
far from always.

In other words, a nice unintended consequence of PM concerns might be to 
press more regularly for that early, clear architecture work, if only to 
get that early, clear PM consideration...

d/

---

From: Jari Arkko <[email-masked]>
Date: Thu, 16 Jan 2014 07:27:54 +0100

I like the proposed addition (but would also like to avoid the example, which had several issues people have already pointed out).

Jari

---

From: Eliot Lear <[email-masked]>
Date: Thu, 16 Jan 2014 08:16:18 +0100

> reference or restated in the security BCPs. 

It is a basic precept of engineering that the earlier you spot a design
flaw, the less costly it is to address.  We needn't teach such basic
precepts in our series.

> need to this BCP in order for it to work for me as a WG chair and

And as a working group chair you must balance ALL considerations and not
just this one.
> choosing technology and didn't seem to agree that they had to.

And I've seen participants all but derail working groups by solely
focusing on one design consideration.

Eliot

---

From: Scott Brim <[email-masked]>
Date: Thu, 16 Jan 2014 15:07:40 -0500

> flaw, the less costly it is to address.  We needn't teach such basic

Then where should they be taught? Personally I prefer having the
fundamentals taught again and again rather than being in a single
place that most people have forgotten about. There are new people in
the IETF all the time, many of whom are new to this level of design. I
don't want to depend on ad hoc osmosis and "common knowledge" to get
the basic principles across.

> And as a working group chair you must balance ALL considerations and not

Yes of course.

> focusing on one design consideration.

If I'm understanding correctly, you're echoing the concern expressed a
week or two ago that the Security ADs were being given a Big Hammer
and tyrannical authority over every working group. No one is saying
this is the only architectural consideration - we have other RFCs on
protocol architecture. The text just says it really should be
considered. No?

Thanks ... Scott

---

From: Jari Arkko <[email-masked]>
Date: Sun, 19 Jan 2014 15:03:43 +0200

> refers to it, in order to emphasize the increased attention to the

FWIW, I do not feel strongly about this topic but my personal opinion is that if we do something with the shepherd write-up, it should be on the general level outlined by Scott above. (But I think the documents themselves are more important than the write-ups. A few years down the road, I'm sure the reader like to know what the thinking on security was on such and such RFC. On any aspect of security, PM or otherwise. When there's something to say, of course, which isn't always.)

Jari