Subject: RE: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive Monitoring is an Attack) to Best Current Practice

From: "Russ White" <[email-masked]>
Date: Wed, 1 Jan 2014 05:32:30 -0500

>       We should not approve an IETF policy statement
>      until we have a good idea of the way we will use it.

I'm struggling a bit with this statement -- it seems just as broad as the
draft under discussion, and just as much of a "policy" as the draft under
discussion. 

What does a "good idea," actually mean? That we have a fairly well defined
way to accomplish any particular goal before going about stating those
goals? That we should not go about trying to accomplish something until we
already have a good idea of how to accomplish it? If so, I don't think this
is a good result. The point of engineering seems, to me, to be that you
choose a goal, then you find a way to get to that goal. You might, on
stating the goal, find there's no obvious way to fulfill the goal, but
that's when you turn to research and lots of thinking, rather than simply
declaring the goal unreachable, and hence not worth articulating.

As for the politics piece -- I don't read this draft as political. The
problem is, rather, a more practical one -- if the Internet is made up of
systems and protocols that are essentially completely open to anyone reading
anything you send, post, or otherwise place into an IETF designed protocol
at any time by anyone, then the Internet isn't a place where anyone is going
to want to actually do much of anything at all. The general objections to
this are twofold:

- If you've not done anything wrong, you have nothing to hide. Refuted on
multiple occasions. You can begin by observing that "wrong," is, in the
modern world (and unfortunately), a completely relative term. It might mean
something completely different tomorrow than what it means today, but the
electronic record, as things stand today, is generally permanent.

- If you don't want to hide it, then don't put it on the Internet. Ten years
ago, no-one thought information about who your friends are (or what you eat
for dinner on a regular basis) had any economic worth. Today, this
information is considered valuable, and hence information you might actually
want to be careful to control in some way. What will suddenly be discovered
to be valuable in ten years' time? We can't even guess, so the better
statement is -- you should hide everything unless you've made a conscious
decision to unhide it. The default shouldn't be, "let everyone see," the
default should be, "let no-one see." 

There is an elephant in the room that I think needs to be brought out and
recognized: people don't make millions/billions on this information just by
knowing it. No-one pays a search engine provider to find out what's in your
email just because they want to know. They pay to know what's in your email
so they can (hopefully) change your behavior in some way (buy this rather
than that, you need that even though you hadn't thought of it before), or
your beliefs (vote for Joe rather than John). We are playing with something
that's more than just "I don't want people to know stuff about me," here.
This comes down to a fundamental level of trust -- who am I revealing
information to that might be used to shape my thoughts and actions in the
future, and how can I control the revelation of that information?

The fact is that the IETF has designed a suite of protocols that are mostly
unsecure, and widely used in a world where we're just starting to see the
importance of security around not only your credit card number, but also
your address book. That the IETF should make a statement saying, "we seem to
have something backwards here, and it's about time we reverse our
assumptions," isn't a political statement at all -- it's a facing of
reality. That the facing of reality has come about through any particular
political situation shouldn't imply that the statement is generally
political -- reacting to a political situation with a statement of a change
in policy isn't a political reaction, nor even (necessarily) a reaction
against the politics. Rather, it's just saying, "hey, we didn't think about
this problem before now, but now that we've thought about it, we need to set
some new goals."

Don't confuse the on list argument about politics with the actual point of
the draft; they're two different things entirely.

Anyway, that's my 2c. I've read the opposing arguments, and I'm still in
support of this draft.

Russ

---

From: Yoav Nir <[email-masked]>
Date: Wed, 1 Jan 2014 11:41:57 +0000

On Jan 1, 2014, at 12:32 PM, Russ White <[email-masked]> wrote:

> What does a "good idea," actually mean? 

I guess a "good idea" would be a checklist for document authors, document shepherds, and IESG members on what they need to consider in a document to ascertain whether it complies with this BCP nn. 

We know what to look for in a security review. We know somewhat less well, but in a vague way what to look for in terms of privacy. I have no idea what to look for to counteract pervasive surveillance. Just as an example, let's look at a particular draft, and assume that it is ready for last call, and I need to write the shepherd's write-up.

I'll choose draft-ietf-httpauth-hoba-02.

The draft is about an authentication method for HTTP, where an asymmetric per-origin key pair is used to authenticate the user (or rather, the user agent) to an HTTP server. 

So now we have to make assumptions about our pervasive surveyor (is that the word?):
 1. Can they decrypt TLS? 
 2. Can they see the plaintext of the authentication process?
 3. Can they see the plaintext of the registration process?
 4. Can they retrieve the public key database at the server?
 5. Can they plant entries in the public key database, using perhaps the procedure in section 6.2, allowing them to impersonate the user?

If they can do #1, they may be able to do #2 and #3, and then #4 is superfluous. If they have access to the public key (through #3 or #4) and access to the authentication plaintext (#2) then they can track where the user is logging in from. 

There are so many capabilities we can imagine that the nation state adversary may have, and we only have a vague notion of what information must be prevented from leaking to such an adversary. I don't think that I can check a document to make sure it won't be smacked down in IETF LC or at the IESG for not complying with BCP nn.

Also, what if we can hide more information out of a protocol, but at the expense of another roundtrip or more processing power. Who gets to balance the two goals?

Yoav

---

From: Eliot Lear <[email-masked]>
Date: Wed, 1 Jan 2014 12:08:56 +0000

(Apologies for dups)

Lloyd,

I share many of your concerns, especially in light of the fact that some - but no means all - security ADs have had a dodgy record in the past. 

As Yoav infers, there is considerably more work to be done on the threat analysis that has been ably begun by Brian & co.  Discussion and development of our understanding of the problem is what is called for.  If this draft has that effect, it has served a useful purpose.  If some are able to eliminate threats, all the better. 

If, on the other hand, developers of a specification discussed the matter in earnest and there was consensus on the way forward, even if some pervasive threats were not eliminated, and if that work is held up by claims relating to this draft, then this draft will have caused harm.

That is nothing more or less than common sense.

As to whether this draft is political, it cannot be stressed enough that if one group of people can subvert our architecture, others can as well. Our political statement, such as it is, is that in order to maintain confidence in the Internet, our protocol suite should be resistant to this sort of thing, but within the bounds of pragmatism. 

Eliot

> On Jan 1, 2014, at 6:08 AM, "[email-masked]" <[email-masked]> wrote:
> 
> what it means for work moving through the IETF process
> is that any work becomes subject to security veto.
> 
> if security types don't like your work - tough. it's
> going nowhere. draft-farrell really widens that scope.
> and this is going to mean arguments about
> much more than the tradeoffs of using MD5.
> 
> for a self-described technical organisation that
> does not make policy pronouncements (which is
> itself a very political position, but never mind)
> this draft is awfully political.
> 
> Lloyd Wood
> http://about.me/lloydwood
> ________________________________________
> From: ietf [[email-masked]] On Behalf Of Melinda Shore [[email-masked]]
> Sent: 01 January 2014 05:38
> To: [email-masked]
> Subject: Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive Monitoring is an Attack) to Best Current Practice
> 
>> On 12/31/13 3:23 PM, Dave Crocker wrote:
> I think this is a critical point and I agree quite strongly
> with it.  I've mostly been baffled by the IETF response to
> revelations about internet eavesdropping, to be honest,
> and it's struck me that work on some of the problems that
> need to be solved to provide better privacy guarantees (for
> example, fixing PKI and providing better keying) have been
> pushed to a back burner in a scramble to make grandiose
> pronouncements.  It's not that draft-farrell is a bad
> document on its own merits, it's just that I cannot for
> the life of me understand what it specifically means for
> work moving through the IETF process.
> 
> Melinda

---

From: "Russ White" <[email-masked]>
Date: Wed, 1 Jan 2014 08:56:27 -0500

> We know what to look for in a security review. We know somewhat less well,
> but in a vague way what to look for in terms of privacy. I have no idea
what to
> look for to counteract pervasive surveillance. Just as an example, let's
look at
> a particular draft, and assume that it is ready for last call, and I need
to write
> the shepherd's write-up.

A checklist of things to look for would be a useful addition to the draft,
of course. But being realistic, we need to start with something much more
generic, like:

==
- Does this protocol proposal provide for ways to hide the information being
transmitted between two parties, if applicable? 

There are some instances where this is not applicable, such as routing
protocols, or information about useable resources in CDNI. OTOH, there are
many instances where this is applicable, such as specific orders for
specific content within the CDNI realm. This question, by the way, is also a
relevant security question.

- What information must be protected in order to protect the confidentiality
of the information being transmitted on the wire (if confidentiality is
provided for in the first question)?

This is something we should be thinking about anyway, but uncovering the
assumptions is a useful exercise. Once we uncover a number of these
assumptions, we could well find a common set of things that would then
become BCPs, or impact the actual design and operation of systems.

- What risks does this protocol pose in terms of metadata for an attacker
who can access the packet flow (without specifically seeing the contents of
those packets)?

This might, at first, be speculative, but as our body of knowledge in this
area grows, we will understand how to answer this question better.

- Are there known ways for user to protect themselves against these risks?

The point of this exercise would be to expose and think about the risks at
hand first. Once we start thinking about what the risks are, maybe we can
start fashioning protections against them. Right now, since we don't have a
lot of information, it's best to start with thinking through the problem
space. Once we understand the problem space better, we can start thinking
about protection. 
==

It's useful to note that privacy and security are often (but not always)
intertwined, and to consider whether pervasive monitoring isn't just a
subset of security issues. It took years for the community to develop a
strong understanding of security. Things acceptable ten years ago are no
longer acceptable, and things acceptable today might not be acceptable in
ten years. Does that mean we give up? No. It means we start with broad
general goals, and refine those goals over time as we explore the space. But
to have that discussion, we need to decide that defense against pervasive
monitoring is a worthwhile goal -- what I'm seeing on list right now is,
"it's not a worthy goal because we don't know how to do it," and, "it's not
a worthy goal because it's a political goal." I don't agree with either line
of reasoning.

> Also, what if we can hide more information out of a protocol, but at the
> expense of another roundtrip or more processing power. Who gets to
> balance the two goals?

This same objection can be raised against data integrity, security, and even
the correctness of a routing protocol's view of the physical topology. I
could ask, "if it takes one more round trip, or a bit more processing, to
make certain there are routing loops, then who gets to balance between the
goals of no routing loops and the use of more processing power?" It's not a
silly question -- I can imagine systems with such low packet rates that
temporary routing loops with timed out packets are an acceptable solution
against sending more control plane state, or using more processor. As
another example, UDP verses TCP already makes a clear distinction between
the willingness of the protocol to lose data on the wire or not verses
additional state.

The bottom line is this: to move forward, we must start someplace. 

Russ

---

From: Dave Crocker <[email-masked]>
Date: Wed, 01 Jan 2014 07:45:08 -0800

On 1/1/2014 4:08 AM, Eliot Lear wrote:
> As to whether this draft is political, it cannot be stressed enough that
> if one group of people can subvert our architecture, others can as well.
> Our political statement, such as it is, is that in order to maintain
> confidence in the Internet, our protocol suite should be resistant to
> this sort of thing, but within the bounds of pragmatism.

Let me suggest that this is exactly the wrong way to talk about the 
issue, in the IETF.  Again, it's not that the statement is wrong, but 
that it is not the way engineers need to approach work.

Here's engineering phrasing that gets us doing the same work, but 
without worrying about the human factor of "confidence".  That is, it 
uses phrasing that matches all the other work we do, rather than placing 
us into some sort of social protection task:

      There is a substantial community in the Internet wishing to have 
its data and activities protected against pervasive monitoring.  The 
IETF needs to design specifications and practices (existing and new) 
with the means to ensure such protection.

Another reason of why we should stay out of the more exciting language 
about pervasive monitoring is that it leads us into making technical 
statements that are wrong.  Pervasive monitoring has not 'subverted' any 
architecture.  It has simply taken advantage of holes in the architecture.

There is a strong market request that we close those holes.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Wed, 01 Jan 2014 11:52:29 -0500

Russ and others,

Just as an example of where we get ourselves sideways in talking
about what the draft says and means...

--On Wednesday, January 01, 2014 08:56 -0500 Russ White
<[email-masked]> wrote:

> ==
> - Does this protocol proposal provide for ways to hide the
> information being transmitted between two parties, if
> applicable? 

That isn't what it says.  By saying "hide", you are accidentally
making the same encryption or encryption-like assumption I made.
For the reasons you give below, I think that assumption is
usually reasonable, but I think we really mean "ways to make the
information hard to intercept and interpret" or which "hidden"
is only one family of techniques.  For those who know the story
and with apologies to those who don't, "how is your Navajo"?

> There are some instances where this is not applicable, such as
> routing protocols, or information about useable resources in
> CDNI. OTOH, there are many instances where this is applicable,
> such as specific orders for specific content within the CDNI
> realm. This question, by the way, is also a relevant security
> question.

Indeed.
    john

---

From: Randy Bush <[email-masked]>
Date: Wed, 01 Jan 2014 08:03:45 -1000

the violations of trust in the internet are on the front page every day
for months.  but we don't need no stinkin' policy or architectural
response.  we just need a mailing list on which to blather endlessly
while rome burns.

what are you gonna do to make the internet a better and safer place
today?

randy

---

From: Tim Bray <[email-masked]>
Date: Wed, 1 Jan 2014 11:01:32 -0800

On Wed, Jan 1, 2014 at 4:08 AM, Eliot Lear <[email-masked]> wrote:

If, on the other hand, developers of a specification discussed the matter
> in earnest and there was consensus on the way forward, even if some
> pervasive threats were not eliminated, and if that work is held up by
> claims relating to this draft, then this draft will have caused harm.
>

This paragraph seems ridiculous to me.  The perpass-attack draft says that
pervasive monitoring has the characteristics of an attack, and that the
protocols we design SHOULD include appropriate mitigation measures. I quote
from the draft:

  "Mitigation" is a technical term that does not imply an ability to
completely prevent or thwart an attack.

There are very few (any?) absolutes in any of the protocols we build, just
a wealth of often-conflicting design criteria, which force us to trade off
and make judgment calls.  draft-perpass-attack says that mitigation of
pervasive surveillance should be seen as one of the design criteria, and
it’s not OK to ignore it. A reasonable take is that a specification could
be held up if there are plausible arguments that this criterion has not
been given appropriate consideration, and I see nothing wrong with that.
Similar hold-ups regularly occur when there are concerns that there hasn’t
been appropriate consideration for efficiency or error-handling or, well,
lots of other criteria.

> confidence in the Internet, our protocol suite should be resistant to this
> sort of thing, but within the bounds of pragmatism.
>
> Eliot
>
> Subject: Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive
> Monitoring is an Attack) to Best Current Practice
>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Jan 2014 08:15:37 +1300

> I guess a "good idea" would be a checklist for document authors, document shepherds, and IESG members on what they need to consider in a document to ascertain whether it complies with this BCP nn. 

IMHO that is exactly the wrong goal for this draft, which is a statement of
aspiration. I would expect the checklist to come from much more technical
documents to be developed over time.

I'm close to concluding that the present draft should not be a BCP at all,
just as RFC 1984 and RFC 2804 were not BCPs. Since it is derived from an
IAB-organised plenary, why not just make it an IAB stream Informational
document co-signed by the IESG? (With a few cosmetic text changes.)
Just get it published so that we can do the real work, as Randy says.

   Brian

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 01 Jan 2014 20:09:41 +0000

(While still on holiday...)

> Just get it published so that we can do the real work, as Randy says.

I disagree. I think if we constantly desist in taking any action
because there are inevitably a number of nay-sayers, then we've
lost. And in this particular case, a BCP is exactly the right thing.
(I'll respond in more detail tomorrow, but do have to say that
there looks to be a lot of repetition in the last day's mails.)

S.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 01 Jan 2014 12:13:31 -0800

> lost. And in this particular case, a BCP is exactly the right thing.

He did not say take no action.  He suggested publishing it, but without 
standards status.  (bcp is standards status.)

It is clear from the list discussion that there is no broad, shared 
understanding of how this policy statement will be applied.  In other 
words, we do not have rough consensus about what the document /means/.

Having rough consensus about a basic emotion about the social aspects of 
the topic is not enough.

As a rule, the IETF tends to avoid standardizing specifications that it 
knows it does not understand.

d/

ps.  My own suggestion is Experimental.  It demonstrates IETF 
encouragement for developing exactly the understanding we currently lack.

---

From: "Russ White" <[email-masked]>
Date: Wed, 1 Jan 2014 15:24:47 -0500

> understanding of how this policy statement will be applied.  In other
words,
> we do not have rough consensus about what the document /means/.

The problem with publishing as an informational is, as an information, it
has no standing within the community. 

I think we might be mixing what something means with what action to take
based on that meaning. I would agree there are no clear cut actions in the
draft as it stands, but we're not really certain what those actions might be
right now, at any rate. So the question becomes:

Should it be a standard of some sort -- a draft with some standing other
than "information" -- to find a way forward in building the questions,
rules, and ideas around protecting the internet protocols designed here
against pervasive monitoring? Should the IETF treat it as a standard that we
should work towards this goal?

If not, then don't bother writing it down at all, no matter the status. If
so, then it's worth saying in a way that drives us forward into other work
in this area.

> As a rule, the IETF tends to avoid standardizing specifications that it
knows it
> does not understand.

There is a difference between standardizing a specification in the technical
sense, and saying, "this is a community goal we've agreed to work on." 

My concern, in the end, is that we publish an informational, and then say:
"See, we've done something. Now we can get back to our regularly scheduled
arguments over whether this should be a bit field or an integer."

I don't think that's the right response. Pick the stronger vehicle, even if
it's not "perfect." As with many other things in the IETF, the perfect is
often the enemy of the good.

Russ

---

From: Melinda Shore <[email-masked]>
Date: Wed, 01 Jan 2014 11:29:47 -0900

> lost. And in this particular case, a BCP is exactly the right thing.

I really don't think so, at least not in its current form.  I
think it's fine to publish it as-is as an opinion piece but it seems
to me that if it's going to be published as a "BCP" it really needs
to be clearer about specifically what is going to change in the
current document development and publication process.  I'd be a little
alarmed if somebody today decided that there's IETF consensus on
publishing as a BCP and that the inevitable nay-sayers can be
ignored; there seems to me to be significant dissent.

Melinda

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 1 Jan 2014 15:34:53 -0500

On Wed, Jan 01, 2014 at 12:13:31PM -0800, Dave Crocker wrote:
> ps.  My own suggestion is Experimental.  

Please, no.  That status has been abused enough.  What would you be
trying to learn by this experiement?  What would the conditions be
that you would conclude you knew the answer?  If you can't answer
those questions, "Experimental" is just wrong.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Melinda Shore <[email-masked]>
Date: Wed, 01 Jan 2014 12:18:45 -0900

> those questions, "Experimental" is just wrong.

I'd actually be fine with experimental, to the extent that it
provided background for some experiments with trying to find
a workable framework for evaluating snoop-resistance in IETF
specifications.  I'm less good with publishing a BCP that's
neither "best" nor "current" nor "practice."

Melinda

---

From: Ted Lemon <[email-masked]>
Date: Wed, 1 Jan 2014 17:08:59 -0500

On Dec 31, 2013, at 3:48 PM, John C Klensin <[email-masked]> wrote:
> No matter what
> assurances are made to the contrary, we've seen example after
> example, general guideline after general guideline, turned into
> rigid rules during or after Last Call on particular documents
> because some AD decides that a document that doesn't match his
> (usually -- I think we've yet to have a really abusive,
> testosterone-poisoned, woman AD) ideas of how things should work
> and should therefore be blocked until the authors or WG either
> conform to whatever "requirement" supports his conclusion or
> produce an overwhelming proof that should not be necessary.

This argument boils down to "ADs can abuse process, so we ought not to ever publish a document that might provide process for them to abuse."   Forgive me, but this is just bad logic: if ADs are abusing process, the problem is the ADs, and the solution has to be addressed through the AD nomination and/or recall process.   There are already plenty of processes to abuse—if I really want to scuttle a document, I don't need another BCP with which to do it.

On Jan 1, 2014, at 12:38 AM, Melinda Shore <[email-masked]> wrote:
> I've mostly been baffled by the IETF response to
> pronouncements.

Fixing PKI doesn't address the pervasive surveillance problem at all.

> It's not that draft-farrell is a bad

It means that, if the IETF winds up having consensus to say so, we agree that document authors and working groups ought to consider the problem of pervasive surveillance: that considering these issues is documented best practice in the IETF.

On Jan 1, 2014, at 9:37 AM, Abdussalam Baryun <[email-masked]> wrote:
> So if you support, could you just state directly how this document
> will be used?

It will be used by working group chairs and document authors to understand the IETF's expectations with respect to whether their work needs to address the problem of pervasive surveillance on the internet.   I expect that ADs will also have this in mind when reviewing documents, and may ask questions about documents if the documents appear not to have addressed the problem, and don't say why.   In some cases, further consideration in the working group will be called for.   In other cases, adding some explanatory text may suffice.   In still other cases, explaining the situation to the AD will be enough.

But the real goal of a document like this is to get working groups to think about this, not to create more tail-end process.   ADs can _already_ ask these questions, and can _already_ send documents back to the working group if the answers aren't satisfactory.   What this document does is to clearly state an IETF consensus (assuming one is reached), which might result in more consistency both across the process of developing a specific document, and also across time as the makeup of working groups and the IESG changes.

On Jan 1, 2014, at 10:45 AM, Dave Crocker <[email-masked]> wrote:
>     There is a substantial community in the Internet wishing to have its data and activities protected against pervasive monitoring.  The IETF needs to design specifications and practices (existing and new) with the means to ensure such protection.

It sounds like you are saying that the IETF does not lead, but rather follows the market.

On Jan 1, 2014, at 3:29 PM, Melinda Shore <[email-masked]> wrote:
> current document development and publication process.

This document is advice, not code.   It is indeed "best practice" in the sense that, if the IETF gains consensus on it, it is saying that we should make a habit of thinking about pervasive monitoring when writing our documents.   I think it would be harmful to be more specific than that.   One the one hand, formal process may be applied when good judgment would have argued otherwise, because "that's the process."   On the other hand, formal process may well accidentally exempt documents where a more general "you ought to think about this" would have clearly applied.

---

From: John C Klensin <[email-masked]>
Date: Wed, 01 Jan 2014 17:33:56 -0500

--On Wednesday, January 01, 2014 12:18 -0900 Melinda Shore
<[email-masked]> wrote:

>> Please, no.  That status has been abused enough.  What would
>> you be trying to learn by this experiement?  What would the
>> conditions be that you would conclude you knew the answer?
>> If you can't answer those questions, "Experimental" is just
>> wrong.
> 

I have to agree with Andrew.  The most important parts of the
document are, to me, the statement that there is an issue, that
the IETF community recognizes that issue, and that there is a
general sentiment that considering it and doing something about
it is generally a good idea.

Where I start having problems is where it seems to specify
constraints on protocols or criteria that could be used to block
standardization of protocol specs that don't meet someone's
theory of what is possible or good enough.   As others have
said, we shouldn't be approving things (and claiming the
existence of consensus about them) that call for action but that
aren't actionable without new rounds of debate about what those
actions are or that seem to specify, a priori and for most or
all protocols, that some tradeoffs and constraints are more
important than others without careful examination of the others.

Identifying a document as experimental doesn't help with that in
any way unless, as Andrew suggested, we are prepared to specify
the experiments and the corresponding evaluation criteria.

I've deliberately avoided making concrete suggestions, but let
me give that up and suggest two alternatives:

(1) Many years ago, in a discussion of formal models of various
types of systems, Joe Weizenbaum [1] suggested the most of the
value in such models lay in the thinking, hypothesis testing,
and topic examination that went into their creation; "running"
the models was less often significantly useful.  Perhaps this
topic is much like that: the community, and especially those of
its members who have been following the discussions and thinking
about the various comments, have learned a great deal.  Maybe
publishing it, especially with claims of consensus, would be
anticlimax at best and an invitation, not just to abuse but to
additional versions of the endless process debates that, as I
think Randy Bush was suggesting, because a blocking factor and
substitute for getting actual work on the Internet done in the
IETF.  That isn't a good tradeoff, so maybe it is time to just
stop.

(2) Perhaps it is useful to the community that we make a strong
statement that pervasive surveillance is an attack on the
Internet, its openness, and the ability to use the network with
confidence.  I don't have a problem with such a statement
although, if we make it, I think we should also be considering
statements about patent abuses, competitiveness among ISPs and
other "open access" and "net neutrality" issues, and a
collection of other issues and areas.  But, if we do that, let's
do that and issue it as an informational statement or RFC, not
pretend that it is a standard, much less a best current
practice.   If that document wants to call for actions or
experiments, that would be great, as long as it isn't written in
a way that can easily be confused with such actions or
experiments.

best,
   john

[1] For those of you who don't recognize the name, look it up --
probably would be good for you.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 01 Jan 2014 22:41:50 +0000

On 01/01/2014 10:33 PM, John C Klensin wrote:
> theory of what is possible or good enough.

Can you quote text please?

S.

---

From: "Russ White" <[email-masked]>
Date: Wed, 1 Jan 2014 17:58:20 -0500

> It means that, if the IETF winds up having consensus to say so, we agree
that
> document authors and working groups ought to consider the problem of
> pervasive surveillance: that considering these issues is documented best
> practice in the IETF.

Precisely.

Consider the alternative. In a year, we have a draft on the table that
seriously compromises privacy, or opens a huge door to surveillance. We can
point to an informational about why such a draft needs work, an experimental
about why such a draft needs work, or a BCP. Which one is the draft authors
going to take seriously, or pay attention to? "You really want me to change
my draft completely to meet the demands of an experimental draft? Since when
do we care about experimentals and informationals?"

IMHO, this draft, as it sits, explains the problem, leaves process questions
open to discussion, and yet says -- we should be seriously thinking about
this. 

Russ

---

From: Melinda Shore <[email-masked]>
Date: Wed, 01 Jan 2014 14:07:30 -0900

> do we care about experimentals and informationals?"

I'm sorry, but when we get to the point where we need to point to an
RFC to stop progress on a document that has obvious vulnerabilities,
our brains have fallen out.

Melinda

---

From: <[email-masked]>
Date: Wed, 1 Jan 2014 23:07:45 +0000

Actually, no, similar holdups do not occur for concerns of error-handling. Examples:

in DTNRG (which, though IRTF, is highly relevant, being chaired as it is by the now security AD):
- LTP was developed with no error detection: RFC5326. Managed to get some shoehorned in at
the last moment in the NULL bits of RFC5237, but that was not a holdup.
- the bundle protocol was developed with no error detection, and no following of the
end-to-end principle. That took ten years or so, a lot of researchers, a national space agency...

but in DTNRG, security was paramount in the design (and focused on by the chairs). Those are the results.
The judgement calls come down in favour of security concerns above all else.

In the IETF:
RFCs 6935 and 6936, which relax the endpoint payload and pseudoheader check by
allowing zero checksums in IPv6, because tunnelled payloads with their own checks 
just don't need it. (That other applications do because IPv6 itself is lax on
reliability checks, has no header-only check and the closest it would get to an endpoint
header check would be UDP-lite, and the applications can be polluted by mis-arriving
errored  zero-checksum UDP packets, is neither here nor there. This is arguably the
predictable outcome of some poor design decisions in IPv6 twenty years ago.)

I'd welcome counterexamples where errors forced a holdup and rethink. I know of none.

We're heading into a world where security is paramount, and the only reason we have
any reliability in protocols at all is as a sideeffect of the security rejecting perceived attacks,
and not because we actually know how to design error-rejecting protocols. (How many
people here could design a CRC? How many design secure systems?)

There will be no further internet engineering (which, given that 6935/6936 are
proposed standards, never mind the horse-designed-by-committee IPv6 camel,
may actually not be a bad thing); any internet engineering done, or any
reliability obtained in implementations, will just be an unintended sideeffect
of security as a discipline.

Lloyd Wood

http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf
________________________________________
From: Tim Bray [[email-masked]]

> There are very few (any?) absolutes in any of the protocols we build, just a wealth
> of often-conflicting design criteria, which force us to trade off and make judgment calls.
>  draft-perpass-attack says that mitigation of pervasive surveillance should be seen as
> one of the design criteria, and it’s not OK to ignore it. A reasonable take is that a specification
> could be held up if there are plausible arguments that this criterion has not been given appropriate
> consideration, and I see nothing wrong with that. Similar hold-ups regularly occur when there are
> concerns that there hasn’t been appropriate consideration for efficiency or error-handling or, well, lots of other criteria.

---

From: <[email-masked]>
Date: Wed, 1 Jan 2014 23:08:28 +0000

DTNRG work suggests that they already have...

Lloyd Wood
Sent: 01 January 2014 23:07

Melinda

---

From: <[email-masked]>
Date: Wed, 1 Jan 2014 23:15:20 +0000

Ask not what you can do for the IETF mailing list. 
Ask what the IETF mailing list can do for you.

good one, Randy.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [[email-masked]] On Behalf Of Randy Bush [[email-masked]]
Sent: 01 January 2014 18:03
To: IETF Disgust
Subject: Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive Monitoring is an Attack) to Best Current Practice

randy

---

From: Scott Brim <[email-masked]>
Date: Wed, 1 Jan 2014 19:42:34 -0500

> those questions, "Experimental" is just wrong.

Right. This is not a protocol that needs field testing, it's a
statement of policy.

The thing that needs to be clarified is apparently what the policy is.

Scott

---

From: Scott Brim <[email-masked]>
Date: Wed, 1 Jan 2014 20:17:13 -0500

> neither "best" nor "current" nor "practice."

I don't believe finding a "framework for evaluating snoop-resistance
in IETF specifications" describes the goal. That would be very very
difficult. Providing background for such an effort? Sure, but again I
don't think that's a primary goal. We want to establish guidelines for
WGs in doing security considerations ... but IMHO specific statements
of guidelines are beyond the scope of this draft. I believe this draft
is just establishing a fundamental principle on which to take the next
steps. Maybe it should just be informational because there's very
little actual practice in it?

Scott

---

From: Ted Lemon <[email-masked]>
Date: Wed, 1 Jan 2014 22:11:16 -0500

> our brains have fallen out.

This is counterfactual.   We used to routinely handwave about security.   We've gotten better about that.   RFC3552 is why.   RFC3552 does not discuss the threat of pervasive monitoring.   So we need a document that does.  This is that document.   RFC3552 is a BCP.   It makes sense that this document would also be a BCP.   The fact that we needed RFC3552, and that we need this document, is not evidence that our brains have fallen out.   It is simply evidence that it is good to state expectations formally rather than hoping that everybody is on the same page but not making any attempt to actually get them there.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 01 Jan 2014 19:27:55 -0800

On 1/1/2014 7:11 PM, Ted Lemon wrote:
> We used to routinely handwave about security.   We've gotten better about that.   RFC3552 is why.

No it's not.

It's useful, but had nothing at all to do with the strategic change. 
That came much earlier and was the result of policy changes in IESG 
requirements on specs.

The real lesson from that was the remarkably vague and obstructionist 
process that took place for years, until we started getting concrete.

The RFC is the result of that realization.  In other words, it's not 
that it enabled less handwaving but that the realization we needed to 
stop handwaving that enabled it.

Note that the current draft lacks any specificity and, therefore, leaves 
us with a similar vagueness as we used to have about security 
considerations.

To repeat from earlier:  the draft's goal and the draft are worthy for 
pursuit, but we are currently clueless about how to apply it.

Clueless.

d/

---

From: Melinda Shore <[email-masked]>
Date: Wed, 01 Jan 2014 18:39:41 -0900

On 1/1/14 6:11 PM, Ted Lemon wrote:
>> I'm sorry, but when we get to the point where we need to point to
>> an RFC to stop progress on a document that has obvious
>> vulnerabilities, our brains have fallen out.
> 
> This is counterfactual.   We used to routinely handwave about
> security.  

We still routinely handwave about security.  It's an afterthought
in entirely too many cases.  Drafts are adopted by working groups
while still having security considerations sections that consist
in their entirety of "TBD."  3552's impacts have been, I think,
on how documents are reviewed more than on how documents are
developed.

One of the reasons I'm somewhat annoyed about the wave of
gasbaggery and pontification that has followed truly disturbing
revelations about the extent to which the US government has
undermined privacy and compromised security technologies is
that work which might have helped provide tools to mitigate
some of the soft spots in IETF work has been backburnered in
favor of no small amount of unfocused grandiosity that doesn't
actually change much.

At any rate this draft is not RFC3552.  3552 provides very specific
guidelines for what needs to be considered in
writing^H^H^H^H^H^H^H^Hreviewing security considerations.

It is tempting to just let this through last call in hopes that
once it's done we can come back around to prioritizing work like
fixing PKI but I'd be very sorry indeed to see this published as a
BCP.

Melinda

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 1 Jan 2014 22:42:02 -0500

> The thing that needs to be clarified is apparently what the policy is.

+1

The problem here in my view is that the appropriate privacy protections
depend on what level of the stack a protocol sits. And so it is not
appropriate to say that 'every protocol must do <splunge> because it is
only appropriate to address certain concerns at certain layers.

For example, attempting to address traffic or meta data leakage at the
application layer is generally a bad plan because that information is
needed to route the data packets.

It is not clear to me that the IETF can actually address traffic privacy
because that probably requires changes at the link layer. Yes, I know about
TOR but the privacy protections come at a huge cost in efficiency and use
of TOR is sufficiently limited that when Harvard had the bomb scare the
other week, the authorities simply brought the five people using TOR on
campus in for questioning to find the culprit.

If I am giving packets to a carrier and expect them to route them to their
destination then I kind of expect them to know where they are being sent.

We could certainly propose link layer schemes that would allow the carrier
to avoid leaking the information to a third party but those seem to be
'IEEE' territory rather than IETF territory.

Where I see the document being useful is not necessarily as a pass/fail
criteria for standards proposals but as a basis for chartering new WGs. I
have some proposals and so do others. Should we be looking for one working
group, two, many? How should the effort relate to past work, etc?

For the past 20 years the bulk of IETF work has been driven by enterprise
and government security concerns rather than end user concerns. So one
consequence is that the protocols we have are only 'good enough for
government work'. IPSEC and S/MIME work about as well as my Palm Treo did.
The Treo was certainly adequate for my business needs at the time but it
was not an iPhone and not even close.

IPSEC could have worked so much better, so could S/MIME and PGP. There
isn't an enterprise business case to do that but the work is essential if
we are going to get a billion people using a security protocol.

I now have running code (incomplete but it does run) that demonstrates that
'frictionless cryptography' for email is achievable using existing clients
(no plug ins) and a few slight changes in approach. By frictionless I mean
that sending and receiving encrypted mail requires absolutely no more
effort than normal mail. That is ZERO additional mouse clicks.

We could have done this ten years ago but the enterprise market that buys
S/MIME and OpenPGP products does not demand frictionless cryptography. Only
the general public is that demanding.

-- 
Website: http://hallambaker.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 1 Jan 2014 22:58:40 -0500

On Tue, Dec 31, 2013 at 3:48 PM, John C Klensin <[email-masked]> wrote:

To take an example I hope is not taken as a proposal, the
> security of SMTP against in-transit interception and monitoring
> of messages could a considerably improved by eliminating
> relaying  (i.e., the application-level store and forward design
> of the protocol).

I like that idea a lot actually.

A lot of the limitations on mail come from the assumption that I will
accept a 4Mb mail message (current Gmail max) from anyone who wants to send
it to me.

If we were designing a new mail protocol for sending huge blobs of data we
would probably start with the rule that the sender is responsible for
storing the bulk of the message until the recipient has decided that they
want to accept it.

Essentially this would be merging dropbox type capabilities into mail.

>  That would have a number of profoundly bad
> effects, at least IMO, but it would enable some rather simple
> methods of mitigating the threat that are of arguable or complex
> utility if relaying is permitted.

I can't see that it would have bad effects. It would only be possible in a
completely different mail infrastructure that was not SMTP.

OK, it is technically possible to do just that with current SMTP
extensions, all that would be required is for an SMTP server to start
accepting some options that are currently reserved for SUBMIT.

But I would not want to do that in SMTP because the only infrastructure
that could benefit from the change in the model would have to be written
from scratch anyway (But it is still significant prior art.)

 If the Apps ADs ever get
> around to getting back to me about a months-old request to
> discuss practical methods of moving RFCs 5321 and 5322 forward
> to Internet Standard, I don't think it is reasonable to
> legitimize an attempt to impose a requirement that starts with
> "RFCnnnn says that monitoring threats should be mitigated where
> possible, so we have to return to first principles and debate
> whether SMTP should have relaying" when, without such a
> statement, we'd be able to say "widely deployed, useful, and
> working that way for a few decades, we just don't need to have
> that discussion about the base protocols".
>

I think trying to retrofit such features to SMTP would be a very bad plan.
There are times to start from a clean slate and this would be one of them.
Every part of a privacy protected email transport would have to be audited
for privacy protection. There would be no way to leverage the legacy base.
So it would be an entirely new protocol. Probably building on JSON/REST
style of design rather than RFC821.

Now we could argue over whether such a scheme is practical at all. But I
don't think building on top of SMTP would help in this particular case.

So no, I don't see that the pervasive surveillance document should impact
RFC5381 going to STANDARD. Just do it already.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 01 Jan 2014 20:06:50 -0800

On 1/1/2014 7:39 PM, Melinda Shore wrote:
> work which might have helped provide tools to mitigate

For all of our combined verbosity about privacy  abstractions and 
policy, I haven't noticed folk trying to propose specifics and getting 
ignored or backburnered.

I fear that we are indulging in a cause/effect error.  The probably 
reason we aren't pursuing needed specifics is that we don't know how to.

d/

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Jan 2014 17:31:24 +1300

> That came much earlier and was the result of policy changes in IESG

Yes. As I mentioned in Vancouver, it was RFC 2316 that stated an aspiration
and RFC 3365 that set technical requirements (whereas 3352 set writing
requirements; I should have mentioned that too). Surely the present draft
is only trying to state the aspiration - there's a lot more work to do before
the rest is ready to publish.

    Brian

---

From: Melinda Shore <[email-masked]>
Date: Wed, 01 Jan 2014 19:34:18 -0900

> reason we aren't pursuing needed specifics is that we don't know how to.

That may be the case, and that this draft is a Something Must
Be Done document.  That is fine, and we all more-or-less seem
to be in agreement that something must be done.  I think,
however, that a Something Must Be Done document probably does
not belong on the standards track.  A This is What We'll Do
document does.  Concern about unforeseen consequences from
publishing a vague document seems appropriate to me.

Melinda

---

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Jan 2014 00:02:03 -0500

Melinda Shore <[email-masked]> wrote:
    >> This is counterfactual.  We used to routinely handwave about security.

    > We still routinely handwave about security.  It's an afterthought in
    > entirely too many cases.  Drafts are adopted by working groups while
    > still having security considerations sections that consist in their
    > entirety of "TBD."  3552's impacts have been, I think, on how documents
    > are reviewed more than on how documents are developed.

I don't disagree that we still handwave.
I want to address the second part of the above statement.

I don't think it's a problem that a draft gets adopted as a WG item that is
incomplete in a variety of ways, including security considerations.

Let's not continue the trend to having a WG design team prior to having a WG.

One of the *KEY* things that a too well baked draft coming in to a WG messes
up is fixing the security issues; from ambiguous and arbitrarily different
encodings, to assumptions about what "Use IPsec" might mean.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: <[email-masked]>
Date: Thu, 2 Jan 2014 05:05:09 +0000

> Let's not continue the trend to having a WG design team prior to having a WG.

perpass is not a WG, and draft-farrell-perpass-attack is not an adopted WG item.

I mean, it's incomplete, and it's circumventing what process we have.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [[email-masked]] On Behalf Of Michael Richardson [[email-masked]]
Sent: 02 January 2014 05:02
To: IETF Discussion
Subject: Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive Monitoring is an Attack) to Best Current Practice

---

From: t.p. <[email-masked]>
Date: Thu, 2 Jan 2014 09:39:21 +0000

----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: <[email-masked]>
Cc: "IETF Discussion" <[email-masked]>
Sent: Thursday, January 02, 2014 4:31 AM
> the rest is ready to publish.

And which stream, to use modern jargon, published RFC2316 and at what
status?

Gosh, shock horror:-)

Tom Petch

p.s.
2316 Report of the IAB Security Architecture Workshop. S. Bellovin.
     April 1998. (Format: TXT=19733 bytes) (Status: INFORMATIONAL)

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 Jan 2014 12:23:43 +0000

John,

In a number of places below, you appear to make hugely
misleading and inaccurate characterisations of the text
of the draft, to the point where I think you seem to be
spreading FUD. Can you please explain how I'm wrong in
that conclusion? Ideally via reference to the actual
text, and justification for how you make the gigantic
leaps from that text to your vastly overstated
mischaracterisations below.

Or, since I'll separately address what I guess might be
the potential concerns behind the FUD that is here, you
can if you like ignore this message and just respond to
a mail I'll send later today.

On 12/31/2013 08:48 PM, John C Klensin wrote:

> That principle is that I do not believe the IETF should be
> making statements supporting any particular religion or set of
> religious principles or, as we might say on this side of the
> pond, expressing strong support for motherhood and apple pie.

I'm sorry but I think the term religion above is purely
being used as a pejorative, and wrongly in this case. Or
maybe you can justify the use of the term via at least
some reference to the actual text of the draft?

> Statements of general concern are ok, but apparent commitments
> to action without specifics seem to me to be ill-advised.  

Disagree. Ted Lemon put it well. This draft represents the
high-order bit but there's more work on going and to be
started.

> To
> me, your document, and much of the discussion, reflects the
> reason why that principle is important: No matter what

I think that's spreading FUD to be honest. I can't see how its
anything else.

And again, as Ted said, if some AD wanted to be a pain in that
way, there's plenty of ammunition available today for that (see
the 2119 references in 3552 for an example of such ammunition
that is not used). Indeed 3552 is a fine example of why we do
not want BCPs that contain too much detail - that detail will
go out of date or not apply to new situations and overall
adds to the potential ammunition that a misguided AD could use
to badly affect ongoing work. Any such detailed guidance should
be based on reality and not be theoretical IMO and so should
emerge from what we find can actually be deployed.

This BCP will not change the potential for any AD to abuse the
IETF. Not a whit. And it really doesn't matter what happened
10 years ago or whenever you care to pick.

> I think much of that case had been made by others and was
> writing my note in that context (see below).  But maybe not.
> 
> So, at the risk of repeating something others have said, I don't
> want to see a Last Call (or, worse, post-Last Call) debate about
> whether the authors of a document that isn't seen to be secure
> enough against persuasive surveillance has done everything that
> might be possible to mitigate that risk.  

"Everything that might be possible" is a serious mis-reading of
the draft and *nothing like* what's stated in the draft. I can't
see how you get that from the text. If there is text there that
could really be mis-read that badly then please point at it so
we can fix it.

> I'm in favor of
> mitigation being considered an important consideration, just as
> I'm in favor of privacy considerations more generally being
> considered important considerations.  But I'm also in favor of
> congestion control, operational reasonableness, security
> considerations that don't directly relate to privacy including
> strong authentication when it is warranted,
> internationalization, and a slew of other things that I think we
> should be considering when protocols are adopted... and
> considered without the impediment of someone saying "well, the
> IETF adopted a formal statement that says 'Particular issue XYZ
> should be mitigated where possible' so that consideration should
> dominate the others."

"Dominate the others" is another serious mis-reading. Again, please
point at the text that has so confused you. (To be honest, I don't
think its there so am mystified that you can get this meaning
from the current text.)

> 
> My problem with going in that direction interacts with your
> draft in many ways even though I'm in agreement about the
> high-level issue.  As a description of an issue, I think it is
> fine.  When you describe and rely on the consensus reached at
> IETF 88, I start having objections because I think the questions
> were stated in a way (and context) that made disagreement with
> them, or examination of the implications and details, nearly
> impossible.

You expected to examine all the implications and details in a
room with ~1000 people?

In any case, this draft does not, and should not, try to
examine all the implications since we don't know them all yet.
Nonetheless if we don't have this BCP then we will have to
re-litgate the overall discussion many times, which will
(I predict) effectively prevent us from making progress on
the more substantive issues with protocols. That is one harm
in your position and those of others who want to wait and
do nothing until everything is "clear."

> of the protocol).  That would have a number of profoundly bad
> utility if relaying is permitted.  If the Apps ADs ever get

I have no idea how that is relevant. Are you suggesting that
this BCP will suddenly mean that bad ideas get airtime when
they previously would have been discarded? That seems silly.

> 
>>From that point of view, when you say "Those developing IETF
> specifications need to be able to describe..." [Section 2,
> paragraph 4], I get the chills because, despite the mitigating
> (sic) second sentence, the third, and the subjectiveness of "a
> good answer", allows someone with the inclination to block
> almost any application-layer protocol until it is encumbered
> sufficiently with privacy decorations to make it unattractive
> and unlikely to be adopted in practice.  I would like the 5th
> paragraph of Section 2, except that I don't look forward to the
> pain I believe this document is likely to cause as that
> "appropriate balance" emerges and is visited and re-visited.

See above. I think that's a frankly weird mis-reading of the text
which is pretty clear that pervasive monitoring is to be addressed
in the same way as any other vulnerability.

> 
> Now to put my earlier note and your questions about it and its
> relevance in context...
> 
> 
> --On Wednesday, December 11, 2013 21:19 +0000 Stephen Farrell
> <[email-masked]> wrote:
> 
>> I've a question about the relevance of your comment
>> John:
>>
>> On 12/11/2013 08:53 PM, John C Klensin wrote:
>>>  if encryption
>>> were pervasive
>>
>> The draft in question does not call for that. It calls
>> for proper consideration of the pervasive monitoring
>> attack and work to mitigate that.
> 
>> Use of encryption for confidentiality will be a relevant
>> mitigation for various protocols, but to comment as if
>> this draft called for ubiquitous confidentiality seems
>> very odd if one has read the draft.
> 
> Oh, I had read the draft, and read the newer version this week.
> What I tried to do was to think about making the broad and
> general statements in the draft actionable and what that would
> mean.  Remembering that I work at the application layer where
> almost all data that users might consider sensitive occurs
> directly rather than by side-effect, our toolkit is rather
> limited.    At least at the application level, if there are ways
> with most protocols to significantly mitigate pervasive
> surveillance that do not replace it with ubiquitous
> confidentiality (or with pervasive encryption, which is what I
> actually said) and that fall within the scope of IETF protocols,
> I don't know what they might be.    

Eh... not sending PII when its not needed in a protocol? I
believe I answered that last month. [1] What's not clear
about that answer?

   [1] http://www.ietf.org/mail-archive/web/ietf/current/msg84918.html

> 
> Actually, I do, but I think the IETF would find them
> unpalatable, and that brings me back to my concern about this
> document and its apparent attempt (whether you intended it or
> not) to move mitigation of pervasive surveillance to the front
> of the tradeoff line.  

That is not an accurate description of the text. You are
radically mis-interpreting what it says. There is nothing
in the draft that moves anything to front of any line.

> For example, effective surveillance of
> traffic content by monitoring of Internet links would become
> considerably more difficult if we (pervasively) went back to
> routing at the packet (or datagram) level and optimized our
> routing algorithms to prefer diverse paths within a stream or
> flow.  At least as I understand it, that would largely eliminate
> the use of MPLS 

Saying that this BCP would eliminate MPLS approaches being
purely FUD.

> and would slow things down overall unless ISPs
> started engineering their networks for more path diversity
> between any two endpoints (presumably increasing costs for the
> amount of traffic handled).   But it would make interception of
> a single flow for surveillance purposes a lot more unpleasant
> and costly for the monitoring body without requiring encryption.
> There are other examples but, as far as I know, they are equally
> unattractive... unless frustrating pervasive surveillance
> becomes out primary objective (and, as you point out in the last
> paragraph of Section 2, that of others).  

"Primary objective" bears no resemblance to the draft at all.

>> John - can you say what part of the draft caused you to
>> incorrectly conclude that "pervasive encryption" (whatever
>> that means) is even being discussed never mind recommended?
> 
> I hope that the above responds to that question, whether we
> agree about the conclusions or not.

The above does not quote any text and IMO hugely mis-states
what is in the draft. I have no clue how you could interpret
the text as you claim to have above.

S

> 
> best regards and best wishes for the new year,
>    john
> 
> 
> 
>

---

From: Dave Crocker <[email-masked]>
Date: Thu, 02 Jan 2014 04:33:25 -0800

> 10 years ago or whenever you care to pick.

Stephen,

I think this assessment is incorrect, based on the earlier history with 
Security Considerations.

For years, we were faced with a requirement to do these Considerations, 
but had no guidance about what would satisfy it and what wouldn't.  As a 
consequence, working groups had to play a guessing game -- sometimes for 
months -- as to what would satisfy the blocking AD.

Of course, that potential is always present, and not just for Security 
Considerations.  But it is exacerbated by a document with formal status 
that makes broad requirements but affords working groups no guidance 
about how to satisfy those requirements.

Again, this is why I think your document should be issued with 
non-normative status.

It's good to have the statements it makes.  It's bad to give them 
normative force until we have experience trying to apply it.

d/

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 Jan 2014 12:47:55 +0000

Hi Dave,

> I think this assessment is incorrect, based on the earlier history with

We disagree about the assessment, though not the history.

> Again, this is why I think your document should be issued with

I do get the concern.

> normative force until we have experience trying to apply it.

I think someone else pointed out yesterday that the normative
force here is only to the effect that pervasive monitoring needs
to be considered, but nothing normative is stated here about how
that is to be done. That latter is being worked on but will take
quite a while before we can really claim its based on reality.
I also think waiting until we have that experience will be
damaging.

- It would take years.
- The result would likely be this statement plus some details
  that will be relatively quickly be out of date.
- In this space, it will be hard to know which mitigations have
  really been effective.

So waiting would not be a good approach.

As to status: 2026 section 5 says:

   The BCP subseries of the RFC series is designed to be a way to
   standardize practices and the results of community deliberations.  A
   BCP document is subject to the same basic set of procedures as
   standards track documents and thus is a vehicle by which the IETF
   community can define and ratify the community's best current thinking
   on a statement of principle or on what is believed to be the best way
   to perform some operations or IETF process function.

This draft is precisely a statement of principle and hence ideally
suited to be a BCP.

I just don't think it'd be sane to require every statement of
principle to be accompanied by all the assembly instructions. And
it'd be wrong to never state principles.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 Jan 2014 12:56:46 +0000

Melinda,

> publishing a vague document seems appropriate to me.

The draft is not vague. Its high-level, which is quite
different. If there are parts that are vague please point
those out and we can try to fix them.

Waiting until we have a set of (not one!) this-is-what-we'll-do
documents would be a bad outcome for at least the reasons I
outlined in response to Dave just now.

Calling this a "Something Must Be Done" document seems
needlessly dismissive. Can you say how that's intended to
help?

I think we have a proof by demonstration that we have not
sufficiently considered this attack. The proposed BCP is
a first, high-level step in remedying that situation. And
if we can get WGs to properly consider the attack to be a
real current practice, then the draft will become a fine
BCP in all senses of the term.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 Jan 2014 13:17:40 +0000

Melinda,

> on how documents are reviewed more than on how documents are

Agreed.

> favor of no small amount of unfocused grandiosity that doesn't

I think the above is gasbaggery and, to me at least, quite
annoying.

I should update [1] but its a list of what's being done that
was up to date in mid Nov.

   [1] https://down.dsg.cs.tcd.ie/misc/perpass.txt

Feel free to join in those discussions some more.

> writing^H^H^H^H^H^H^H^Hreviewing security considerations.

When'd you last re-read 3552? Is has all sorts of MUSTs that
we routinely do not and should not force draft authors to
conform to, for example:

   Authors of internet standards MUST describe which denial of service
   attacks their protocol is susceptible to.  This description MUST
   include the reasons it was either unreasonable or out of scope to
   attempt to avoid these denial of service attacks.

Is that still reasonable? I think not, there are too many DoS
vectors in the world now. The non-normative parts of 3552 are
very good though, but I think many of the normative instructions
are outdated. That BCP would have been better with far fewer or
no references to 2119 IMO.

And so with this one - stating only the high level requirement
is the right thing to do for now.

Leaving the high-level requirement unstated would mean that a
lot of IETF work in the coming years would not address this
attack.

> fixing PKI but I'd be very sorry indeed to see this published as a

"Fixing" PKI is neither terribly relevant here nor being ignored.

For TEMPORA PKI seems mostly irrelevant. For QUANTUMINSERT et al
some of the active attacks do depend on problems with the Web PKI
but I'd guess mixed-content is much more important in terms of
successful attacks than are PKI abuses, for now at least.

On the latter point, there is a wpkops WG that could do with more
help. We have also started discussion about chartering a CT WG. And
the uta WG might make some recommendations about TLS that help
there too. And the httpbis WG have seriously debated TLS for
HTTP/2.0 (that debate's not over but is real). If you have other
ideas for "fixing" PKI then I'd be glad to hear about them and
to try help make 'em happen, as appropriate.

On the whole I think your criticism is, to use your words,
gasbaggery and annoying. And wrong.

S.

---

From: Scott Brim <[email-masked]>
Date: Thu, 2 Jan 2014 08:26:46 -0500

On Jan 2, 2014 8:18 AM, "Stephen Farrell" <[email-masked]> wrote:
> is the right thing to do for now

Would it be better to leave this one informational and not make it a BCP?
There's extremely little in it that is Practice.  The next level down is
where we would add more specific guidelines and BCPs.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 Jan 2014 13:35:40 +0000

> where we would add more specific guidelines and BCPs.

See the quote from 2026 in my response to Dave - what is wrong
with following that and making a statement of principle as a
BCP?

There should be no need for all BCPs to have lots and lots of
detail surely.

And FWIW, I do think it'll be easier to get WGs to properly
consider the attack/threats if this is a BCP.

I also think it'll be cleaner to update as a BCP, if and
when we wanted to add more detail, but that's a minor detail.

S.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 02 Jan 2014 14:35:57 +0100

>those out and we can try to fix them.

The part where it says the IETF will work to mitigate Google's pervasive
monitoring. Also the part where it says Google's pervasive monitoring is
an attack on Internet communications. And the part where it says there's
a consensus on both points. There is no mention of Google in the draft,
so read that as any perpetrator of mass surveillance attacks.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Ted Lemon <[email-masked]>
Date: Thu, 2 Jan 2014 09:25:35 -0500

On Jan 2, 2014, at 8:35 AM, Bjoern Hoehrmann <[email-masked]> wrote:
> monitoring.

Are we talking about the same document?   I just googled it for the word "google" and got zero hits.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 2 Jan 2014 09:29:41 -0500

> Are we talking about the same document?   I just googled it for the word "google" and got zero hits.

Dialing in a little closer, consider this snippet from the actual text of the document:

   In the Internet,
   the term ["attack"] is used to refer to a behavior that subverts the
   intent of a communicator without the agreement of the parties to the
   communication.

So in the case of Google, the parties seem to have agreed to the communication, which suggests to me that this document is specifically not talking about Google.   Unless Google is in the habit of eavesdropping on communications to which it is not a party.

---

From: t.p. <[email-masked]>
Date: Thu, 2 Jan 2014 15:32:57 +0000

---- Original Message -----
From: "Melinda Shore" <[email-masked]>
To: "Ted Lemon" <[email-masked]>
Cc: "IETF Discussion" <[email-masked]>
Sent: Thursday, January 02, 2014 3:39 AM
> > On Jan 1, 2014, at 6:07 PM, Melinda Shore <[email-masked]>
<snip>

Melinda

I note your explicit reference to the US government.  I note, too,
recent postings (e.g. on the TLS and UTA lists) which cast doubt on the
integrity of the (American) NSA which, in turn, reminds me that I see
the
USA as a country of small government (starting with the Founding
Fathers), something to be distrusted, subverted even, and I think that
that is colo(u)ring this discussion (whether or not the proponents of
this I-D are American citizens).

Elsewhere, I believe that governments are more trusted, so when the head
of a (non-American) national security agency says that the world is now
a more dangerous place, that successful terrorist attacks are more
likely because of recent revelations, then that consideration, of
personal security, outweighs my concern that someone is reading my
messages to, say, a secret lover.  I have been close to terrorist
attacks - doubtless some on this list have been directly affected by
them - and while I see them as probability low/impact high, I am more
concerned about that risk than that of the state seeing something I
would rather it did not.  And, as I said before, if there is any breach
of privacy that concerns me, and again it is one that I see echoed in
the national media, it is that of the assembling of personal profiles by
large, quasi-monopolistic websites, something which the aspirations
of this I-D would seem to make more likely.

Tom Petch

---

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Jan 2014 10:46:49 -0500

<[email-masked]> wrote:
    >> I don't think it's a problem that a draft gets adopted as a WG item
    >> that is incomplete in a variety of ways, including security
    >> considerations.
    >>

    > perpass is not a WG, and draft-farrell-perpass-attack is not an adopted

I think that Melinda is making a general statement about WG processes, not
one related to perpass.  Perhaps I'm wrong here.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting for hire =-

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 02 Jan 2014 16:48:02 +0100

* Ted Lemon wrote:
>So in the case of Google, the parties seem to have agreed to the 
>communication, which suggests to me that this document is specifically 
>not talking about Google.   Unless Google is in the habit of 
>eavesdropping on communications to which it is not a party.

The draft specifically calls out "legal but privacy-unfriendly purposes
by commercial enterprises" "no matter how benevolent some might consider
them to be" causing "through correlation with other communication
events, [revelation of] information the communicator did not intend to
be revealed"; that is a description of "behavioral advertising".

If you put Google "+1 button" scripts on your web site, that does not at
all mean first time visitors have somehow consented to Google being a
party to their communication, before they had a chance to become aware
of that. Indeed, many German web sites disable such "buttons" by default
('Two clicks for more privacy') for this reason.

If Google Analytics is somehow not pervasive monitoring then I do not
see how I could personally be affected by pervasive monitoring? "NSA
'spied on porn habits to target" does not seem different from "Google
'spied on porn habits to target" if I ignore that Google is no formal
part of the U.S. military. Is pervasively spying on porn habits an
attack? Yes if it's done by tapping undersea cables, no if it is done
through CDN server logs? How do you tell which CDNs are party to your
communications?
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Ted Lemon <[email-masked]>
Date: Thu, 2 Jan 2014 10:55:38 -0500

> be revealed"; that is a description of "behavioral advertising".

It might be helpful to quote the text without strategic elisions!   It's true that something like the G+1 button can be used for pervasive monitoring, but that's a bit different than saying that this document is specifically targeting Google and Google's general business model.   The point is that if by happenstance certain applications like the G+1 or FB Like button become less valuable as a result of IETF being more proactive in preventing pervasive monitoring, that would be an acceptable outcome.

Do you disagree with that?

---

From: Stephen Kent <[email-masked]>
Date: Thu, 02 Jan 2014 11:03:12 -0500

I commented earlier to Stephen (off list) that BCP status seemed a bit 
out of place for
a position statement, so I'm heartened to see others have a similar 
concern. I concur
with the suggestion that this be (IAB stream) Informational.

If published as Informational, I don't worry that this doc does not lay 
out details
for what WGs are expected to do. At the behest of two IAB members, I am 
working on a
doc that examines keying options for major IETF security protocols, and 
discusses what
changes could be made to facilitate anonymous encryption as a fallback 
from authenticated encryption. This is just one aspect of an overall 
response to PM, but it will yield concrete proposals. Other folks are 
working on an updated threat model doc.

I have also noted that the document refers to PM as "indistinguishable" 
from an attack,
which IMHO seems too polite. PM is effected via passive and active 
wiretapping attacks, and
thus it IS an attack. Tim Bray's message characterized the current draft 
as saying "The perpass-attack draft says that pervasive monitoring has 
the characteristics of an attack, ..." This suggests that a reader 
doesn't interpret the text as saying that PM _is_ an attack.
We should avoid words that may lead a reader to believe that PM is 
/equivalent/ to an
attack. Its easy to make a case that PM is an attack. I provided (off 
list) feedback a
few weeks ago suggesting a different way to present the issues here, and 
have updated that text:

For many years the IETF security community has used an attack/threat 
model [RFC3552] that envisions an adversary who can engage in passive 
and active wiretapping at any point along a communication path. We 
commonly attribute the ability to engage in MITM attacks to such an 
adversary. Thus we have long believed that plaintext communications are 
vulnerable to passive wiretapping along a communication path if the 
content is not protected via encryption. We also have noted that, for 
staged delivery applications, e.g., mail, content is vulnerable to 
disclosure and modification in storage, especially en route.In response 
to this model we have developed a set of security protocols, (e.g., 
IPsec, TLS, DTLS, S/MIME, SSH, etc.) that can be used to protect 
transmitted content against passive wiretapping, based on use of 
encryption. These protocols also usually incorporate data integrity and 
authentication mechanisms, and, where appropriate, anti-replay 
mechanisms, to address MITM attacks. Thus we have offered users and 
system designers a set of tools that address the adversarial 
capabilities based on our model.

When pervasive monitoring is effected via passive wiretapping, or a mix 
of active and passive wiretapping (e.g., using packet injection attacks) 
it is not a new class of attack. It is precisely what we have long 
considered when designing security protocols. Thus I believe this 
document should include comments of the sort noted above, to help 
establish a context for this declaration about "pervasive monitoring".

Having established this context, the next task is to explain why 
pervasive monitoring is significantly different from our long-standing 
model. The extent of such monitoring seems much bigger in scope than 
folks may have imagined, given that intelligence services of numerous 
countries have been identified as carrying on such monitoring. However,
RFC 3552 states:

    By contrast, we assume that the attacker has nearly complete control
    of the communications channel over which the end-systems communicate.
    This means that the attacker can read any PDU (Protocol Data Unit) on
    the network and undetectably remove, change, or inject forged packets
    onto the wire.  This includes being able to generate packets that
    appear to be from a trusted machine.  Thus, even if the end-system
    with which you wish to communicate is itself secure, the Internet
    environment provides no assurance that packets which claim to be from
    that system in fact are.

This statement is pretty clear. I think the PM document needs to 
explain, in a technical context, why pervasive monitoring is 
qualitatively different, and thus merits this declaration by the IETF. 
We ought not lead readers to believe that we have not considered passive 
and active wiretapping as likely attacks in the past.

Some of the reported forms of pervasive monitoring may have involved the 
cooperation of or subversion of an ISP or a telecom provider. This is 
not a qualitatively different form of attack from the generic passive 
wiretapping that our security model has always assumed.

Some of the reported forms of pervasive monitoring have involved the 
cooperation of or subversion of application service providers. This does 
represent a major deviation from
the 3552 model:

    The Internet environment has a fairly well understood threat model.
*In general, we assume that the end-systems engaging in a protocol**
**   exchange have not themselves been compromised.*

So we should acknowledge this as one asp[ect of PM that is different 
from our threat model. However, if attacks take place at a point after 
which IETF protocols terminate, then it seems to be largely outside of 
our purview as a protocol-focused standards organization. For example, 
if I access e-mail via a _web_ _interface_ at an MSP, IETF security 
standards largely do not seem to apply to vulnerabilities associated 
with storage of the mail at the MSP; my mail can't be protected e-t-e 
because I'm not using S/MIME to read the mail. I can use TLS to protect 
the HTTPS session via which I access messages, and we can recommend that 
TLS be used with SMTP to deliver the mail to the MSP, but that seems to 
be the limit of our security protocols.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 02 Jan 2014 16:10:29 +0000

On 31/12/2013 20:48, John C Klensin wrote:
> For example, effective surveillance of traffic content by monitoring 
> of Internet links would become considerably more difficult if we 
> (pervasively) went back to routing at the packet (or datagram) level 
> and optimized our routing algorithms to prefer diverse paths within a 
> stream or flow. At least as I understand it, that would largely 
> eliminate the use of MPLS and would slow things down overall unless 
> ISPs started engineering their networks for more path diversity 
> between any two endpoints (presumably increasing costs for the amount 
> of traffic handled). But it would make interception of a single flow 
> for surveillance purposes a lot more unpleasant and costly for the 
> monitoring body without requiring encryption.

Actually John, I think some MPLS implementations did this across equal 
cost paths, but TCP performance went through the floor and so a lot of 
effort now goes into the maintenance of flow order. Some protocols are 
much more sensitive than TCP in this regard and can never be subjected 
to misordering. However if the transport protocols could cope with out 
of order delivery, we could get MPLS to spread flows across pretty much 
every available path. As well as having anti-surveillance properties, 
such an approach would have the anti-congestion properties of spread 
spectrum and so could be quite an interesting area of research.

Stewart

---

From: Dave Crocker <[email-masked]>
Date: Thu, 02 Jan 2014 08:13:18 -0800

On 1/1/2014 2:08 PM, Ted Lemon wrote:
> This argument boils down to "ADs can abuse process, so we ought not
> to ever publish a document that might provide process for them to
> abuse."

A normative document that requires action, but does not characterize the 
action, inherently encourages idiosyncratic interpretation.  That's an 
invitation -- possibly even a demand -- for ADs to develop their 
personal preferences rather than to reflect a shared community sense of 
what is needed.

> It will be used by working group chairs and document authors to
> understand the IETF's expectations with respect to whether their work
> needs to address the problem of pervasive surveillance on the
> internet.

The problem here is your certitude about how it will be used.

The one thing that is certain about the document is that it does not 
specify that activity for those people.

And at this stage I don't think it should, because we don't know enough.

> I expect that ADs will also have this in mind when
> reviewing documents, and may ask questions about documents if the
> documents appear not to have addressed the problem, and don't say
> why.

A reasonable expectation.  But since we have no community understanding 
of what the specific questions should be and even less community 
understanding of what the answers will be, making the current draft 
normative essentially requires a deadly embrace in the standards 
process, as each occurrence produces an ad hoc negotiation over an 
extended period of time.  (This is exactly what happened for years with 
Security Considerations.)

All of this gets exacerbated by the likelihood of personal whim amongst 
ADs.  (It's not a question of intent; everyone intends well.  It's the 
lack of community guidance, at this stage.)

> But the real goal of a document like this is to get working groups to
> think about this, not to create more tail-end process.

Then don't make it normative, yet.

>  ADs can
> _already_ ask these questions, and can _already_ send documents back
> to the working group if the answers aren't satisfactory.   What this
> document does is to clearly state an IETF consensus (assuming one is
> reached), which might result in more consistency both across the
> process of developing a specific document, and also across time as
> the makeup of working groups and the IESG changes.
>
>> its data and activities protected against pervasive monitoring.
>> The IETF needs to design specifications and practices (existing and
>> new) with the means to ensure such protection.
>

Since I don't see anything in that statement of mine about the market, I 
can't guess what took you to that interpretation.

>> I really don't think so, at least not in its current form.  I think
>> it's fine to publish it as-is as an opinion piece but it seems to
>> me that if it's going to be published as a "BCP" it really needs to
>> be clearer about specifically what is going to change in the
> This document is advice, not code.

"Advice" is not normative.

>   It is indeed "best practice" in
> the sense that, if the IETF gains consensus on it, it is saying that
> we should make a habit of thinking about pervasive monitoring when
> writing our documents.

Ted, a recurring problem in many folks' posting on this topic is that 
they seem to be applying invoking themselves as the model of what will 
happen with the document, rather than considering the community's 
history, including how different ADs have operated over the years.

And then there is the well-demonstrated variability already showing up 
in the current discussion.  It makes clear that we don't yet have shared 
community understanding of what we should be doing in terms of technical 
specifics.

The document really has nothing to do with best current practices 
because it is not about practices at all.  It is about concerns.  We 
don't make statements about concerns normative.  Especially when we do 
not have any history of working on a topic.

d/

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 02 Jan 2014 16:23:08 +0000

On 01/01/2014 22:08, Ted Lemon wrote:
> This argument boils down to "ADs can abuse process, so we ought not to 
> ever publish a document that might provide process for them to abuse.
Ted, I believe the point is that the AD concerned would not be abusing 
the process, they would simply be making a different judgement call, or 
a stricter interpretation (for what ever reason) of the in place PM 
requirements than the authors and preceding reviewers of the text.

The  -03 text is a significant improvement, but I still fear the impact 
of single issue technical politics on the output of our document stream.

Stewart

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 02 Jan 2014 17:24:34 +0100

* Ted Lemon wrote:
>It might be helpful to quote the text without strategic elisions!

You mean http://www.ietf.org/mail-archive/web/ietf/current/msg85172.html
should have quoted "There is no mention of Google in the draft, so read
that as any perpetrator of mass surveillance attacks"?

>It's true that something like the G+1 button can be used for pervasive 
>monitoring, but that's a bit different than saying that this document is 
>specifically targeting Google and Google's general business model.   The 
>point is that if by happenstance certain applications like the G+1 or FB 
>Like button become less valuable as a result of IETF being more 
>proactive in preventing pervasive monitoring, that would be an 
>acceptable outcome.
>

Stephen Farrell asked which parts of the document are "vague". The point
is that the document is vague in explaining what "The IETF will work to
Mitigate" exactly. I think your question is entirely besides the point.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Rene Struik <[email-masked]>
Date: Tue, 31 Dec 2013 14:02:11 -0500

Dear colleagues:

While I do agree with some of the underlying sentiments of the draft, I 
am not that happy with the somewhat sloppy exposition of the draft, in 
particular to what problem one really wishes to address (see #1, #2 
below). Moreover, I feel that the implicit suggestion of the draft that 
one should take an almost binary approach to addressing passive attacks 
may be detrimental at achieving a solid security architectural design 
(it should be a proper balancing, rather than 0-1 thinking w.r.t. one of 
many security architectural considerations).

In my mind, the draft needs to be more carefully written, so as to make 
intent and grey scales of proposed design metrics clearer. More details 
below.

Some technical comments:

1) In Section 1, 3rd para, the term "attack" (in the context of 
pervasive monitoring) is too broadly defined: pervasive monitoring is 
(an extreme form of) monitoring and, thereby, an attack form that has 
been dubbed (decades ago) in the cryptographic literature as an attack 
by a *passive* adversary. (The fact that this may happen on a massive 
scale does not change its nature.) In the draft, though, one seems to 
lump this together with other attack forms, where a passive adversary 
may exploit insights gathered from passive attacks to subsequently 
facilitate an active attack (witness the use of "to enforce the 
opponent's will on the attacked party" in 3rd para, 3rd line or "that 
subverts the intent of a communicator without the agreement of the 
parties to the communication" in 3rd para, 6th line). The latter is an 
*active* attack, which is not part of pervasive monitoring itself (but 
only may take advantage of this). With passive attacks, in most cases 
(e.g., when using wireless communications) the presence or absence of an 
passive adversary cannot be distinguished. I would strongly suggest 
using proper notions and avoiding confusing and ill-defined terms (for 
definitions, see, e.g., Definition 12.15 of the Handbook of Applied 
Cryptography (CRC Press, 1995)). Shouldn't one simply change the title 
of Section 1 to the (somewhat obvious) statement "Pervasive monitoring 
is Indistinguishable from a Passive Attack" or "Pervasive Monitoring 
Cannot Be Distinguished From Non-Monitoring, So One Should Prepare For 
the Worst"?

2) In Section 1, 4th para, if the intent of the draft is to also raise 
awareness of active (pervasive) attacks, it should say so clearly and 
not suggest, as it seems to do right now, that this is due to "pervasive 
monitoring" (since, as already said, this is a misnomer). Here, again, 
though, this is nothing new by itself: security services need to be in 
place where the interests of communicating parties, including the 
communicating networks used by these parties (and lurking adversaries 
therein) are not aligned. I would suggest emphasizing, far more than 
currently done, the role pervasive monitoring could play in paving the 
way towards providing useful insight to make a subsequent (or 
interactive) active attack more successful, since that seems to be one 
of the underlying currents of the draft.

3) In Section 1, 1st para, it is stated that " [...] that this was an 
attack that should be mitigated where possible via the design of 
protocols that make pervasive monitoring significantly more expensive or 
infeasible". While I wholeheartedly agree that protocol design should 
include privacy-relevant objectives (such as hiding header info and 
meta-data), to me it seems this should always have been in the security 
services objective list with security and communication protocol design 
and it is somewhat surprising to see that this apparently is something 
new (or, do I read this in the wrong way?). Isn't the main change 
between the pre-Snowden and post-Snowden era that one is now aware that 
would should attach more weight to security objectives one may very well 
have unrightfully ignored in the past??? I am really concerned that this 
becomes now a single quest at the detriment of other security objectives 
one may wish to cater to. After all, with security and communication 
protocol design, one should balance different objectives according to 
deployment scenario at hand and there are many, many considerations that 
could play a role. To this point, I already expressed concern in an 
email of September 6th (see
http://www.ietf.org/mail-archive/web/perpass/current/msg00099.html) 
that, e.g., trying to avoid traffic analysis by making all frames the 
same size would be disastrous for applications in a highly constrained 
setting ("internet of things", "smart objects", and the-like); I also 
epressed some other concerns with respect to binary thinking here (see 
the link). I would therefore suggest to express the desire of IETF-88 
somewhat more intelligently and stipulate, e.g., that protocol should 
properly consider security objectives and weigh these and allow security 
policy settings to be picked so as to, indeed, enable more privacy-aware 
deployments. This is mostly a security policy issue, though, and should 
less so be a fixed setting of a security protocol itself. One could dub 
this "security policy agility" vs. "crypto agility" if one wishes.... 
(Note: TLS is an example of a somewhat unfortunate design here, where 
one has no security policy agility to hide lots of parms in the protocol 
flows at all). The main point of post-Snowded would then be that the 
"security policy agility" should include the policy to enable privacy 
protection to one's heart content.

4) Section 2, 2nd and 3rd para, seems to be a somewhat hidden admission 
that, perhaps, IETF itself may in the past not have done as good a job 
as it could have in considering and weighing all security objectives. 
After all, notions of passive and active attacks have been around for 
decades, but apparently some of this has been not taken too seriously 
for a while, or would have been considered "too expensive" to 
implementers or vested interests? It can hardly be considered news that, 
e.g., if one does not use adequately secured packets, then visible parts 
may be eavesdropped upon, etc. Right now, it reads as if one is 
indignified even in case one sends entirely unsecured packets and that 
this, surprise, surprise, may be vulnerable to attack. To some network 
people, it may be considered news if protocol messages do not behave as 
specified. To security people, this should be second nature: after all, 
all networks and network components should be considered as gigantic 
security engines, without constraint on actors on the communication channel.

5) Section 2, 5th para, seems to be an admission that protocol design 
should intelligently weigh design objectives (e.g., so as not to rule 
out monitoring for network monitoring purposes). So, if this means one 
wishes to cater for "security policy agility" as I alluded to above, so 
much the better.

Best regards, Rene

On 12/3/2013 12:48 PM, The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Pervasive Monitoring is an Attack'
>    <draft-farrell-perpass-attack-02.txt> as Best Current Practice
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2013-12-31. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>     The IETF has consensus that pervasive monitoring is a technical
>     attack that should be mitigated in the design of IETF protocols,
>     where possible.
>
>
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-farrell-perpass-attack/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-farrell-perpass-attack/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Wed, 1 Jan 2014 11:40:57 +0000

Lloyd,

I share many of your concerns, especially in light of the fact that security ADs have had a dodgy record in the past. 

In my opinion, there is considerably more work to be done on the threat analysis that has been ably begun by Brian & co.

Discussion and development of our understanding of the problem space is what I believe is called for.  If this draft has that effect, it has served a useful purpose.

As to whether this draft is political, I don't think it can be stressed enough that if one group of people can subvert our architecture, others can as well. Our political statement, such as it is, is that in order to maintain confidence in the Internet, our protocol suite should be resistant to this sort of thing, but within the bounds of pragmatism. 

Eliot

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Thu, 2 Jan 2014 00:24:42 +0000

Tim,

This paragraph seems ridiculous to me.

Then you've not the history to have seen reasonable protocols be held up- or worse mangled- to satisfy unreasonable decisions by ADs based on their interpretation of their authority.   We have been down this road before. And again, I'm not concerned about the current ADs, mind you. We've a good lot.

 The perpass-attack draft says that pervasive monitoring has the characteristics of an attack, and that the protocols we design SHOULD include appropriate mitigation measures.

Well it doesn't say that (at least in -03) and let's not suppose it did.

There are very few (any?) absolutes in any of the protocols we build, just a wealth of often-conflicting design criteria, which force us to trade off and make judgment calls.  draft-perpass-attack says that mitigation of pervasive surveillance should be seen as one of the design criteria, and it’s not OK to ignore it.

In fact I've argued all if this myself.  It presumes we understand the threat well enough.  One concern at the moment is that a group will take an action in response that actually ENABLES more pervasive surveillance.  That may be unavoidable as there will be trade offs.

A reasonable take is that a specification could be held up if there are plausible arguments that this criterion has not been given appropriate consideration, and I see nothing wrong with that.

Sure. But now you've actually rung in another problem with the draft. Most participants in the IETF don't know how to address the threat and those who think they do probably won't agree on either it's nature or the remediation.

We're simply not there yet.

The IETF should take this threat seriously and do what we can when we know what to do.

Eliot

---

From: Hector Santos <[email-masked]>
Date: Thu, 02 Jan 2014 13:49:05 -0500

> when we wanted to add more detail, but that's a minor detail.

The key problem is to get the WG to consider anyway despite any BCP or 
document of any status.  We should not have to be told what is "right 
or wrong" to consider when it comes ethical engineering.   We all know 
what is "bad" when we see it.  Right?

Well, perhaps not.  I will use an example with this whole effort to do 
the "right thing" when it comes to privacy and security.

Consider the super fast track APPS-DISCUSS WG draft proposed standard 
that is currently in LC:

http://tools.ietf.org/html/draft-ietf-appsawg-rrvs-header-field-05

This RRVS idea deals with an extremely risky potential concept to 
REUSE EMAIL ADDRESSES/IDS. The RRVS proposes an unclear method with 
claims it can offer a secured and safe way to allow email hosting 
sites the ability to offer reusable email addresses.   There are 
claims that this is in production mode, yet, there is no means to do 
general broad mail network interop testing.  There are no interop 
reports as far as I can see.  However, that are published (google 
reseached) reports and concerns for:

    - Privacy, Security Leaks and
    - (Email) Identity Lost

I will add:

    - Increased SPAM that are currently blocked but accepted for
      transferred ids.

All that, and I'm accused of bringing "Layer Nine" (whatever that 
means) to the table. If so, so be it.  I feel I am doing my job 
product manager and as a potential implementator of this RRVS proposal.

I believe this is what Stephen Farrell's draft is all about -- to get 
people to better consider what are the potential issues.   In the case 
of RRVS, as it is written as a proposed standard but an experimental 
status proposal to be further explored before the IETF accepts and 
advocates any idea that has a high potential to leak private, secured 
information, a risk for identity lost and reopens SPAM to transferred 
targets.

Isn't the purpose of this draft to get people to better engineer IETF 
sanctioned protocols in secured, safe ways without hampering progress? 
  Sure, we all know there is a balance, but some are so obvious such 
as this RRVS that it is already filled with "Layer Nine" and as 
"conflict of interest" rush to completely track that is mind numbing. 
Its become too overwhelming and you risk getting the negative label to 
speaking up.  The fact is, the concept is good, but it still needs 
more work.

So be it.

I guess we can use a strong document to throw at people when they 
begin to ignore you.  Hopefully, its shouldn't have to come to that 
each and every time. Its exhausting.

I vote to make any new document related to better IETF engineering a BCP.

-- 
HLS

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 Jan 2014 19:23:16 +0000

Hiya,

> many security architectural considerations).

Sorry - what text suggests a binary approach? Please do give
quotes, as that is not the intent, and nor is it expressed.
In fact the draft says:

  "The IETF will work to mitigate the
   technical parts of the pervasive monitoring threat, just as we do for
   other protocol vulnerabilities."

I really don't see how that can be mis-interpreted as a
"binary" approach. Can you explain?

> by a *passive* adversary. 

No. We are not defining pervasive monitoring as being purely passive,
since it is not. And nor is it an active attack entirely. So its
correct that the definition is that broad and differs from either
passive or active attacks.

I think a perhaps lot of your other comments hang on this
misunderstanding. But I'll comments on bits of those below. But
what you call a misnomer is deliberate, and is needed IMO.

I'd welcome a better definition if we can find one.

> (The fact that this may happen on a massive
> only may take advantage of this). 

The active aspect is also a part of pervasive monitoring as
defined here, and needs to be considered as such. For example,
if an RSA private key is exfiltrated via an active attack in
order to later decrypt non-PFS ciphertext. (As in the Belgacom
case perhaps.) That is part of the pervasive monitoring
attack, but is not well described as either passive nor active.

> With passive attacks, in most cases

No. It would be wrong to only consider pervasive monitoring as
a passive attack as that is not the case.

I think our conceptions of passive and active have in fact held
us back to an extent in that they may have made us less likely
to recognise the potential for the pervasive monitoring attack
which mixes both approaches and at scale.

> of the underlying currents of the draft.

No, the main purpose of that paragraph is to empahasise that
the IETF don't need to take a position on the morality or
otherwise of e.g. specific NSA or GCHQ motivations. We can and
do say that their actions are an attack, but we do not say that
their motivations are good, bad or indifferent.

That is necessary so that when someone misinterprets the draft
as saying that "the IETF says that NSA are bad" they can be
corrected by pointing at this text.

The text in this draft *will* be deliberately misinterpreted
by some for their own ends so this really is needed.

> meta-data), to me it seems this should always have been in the security

"should always have been" is correct from a security and privacy
perspective. But it is clearly the case that such consideration has
not been a typical part of current or past practice.

Hence the need for this BCP.

> one may wish to cater to.

Sigh. "Single quest" is a very weird mis-reading of the draft.
See the text quoted above. I honestly don't get how you end up
thinking that.

> After all, with security and communication

That message was not in relation to this draft. I don't know what
you mean in quoting it sorry. Can you clarify how it relates to
this draft?

> protection to one's heart content.

I have to say that the above seems to me pretty unclear in comparison
to the current text. (But I would think that of course:-)

> 4) Section 2, 2nd and 3rd para, seems to be a somewhat hidden admission

"Hidden" is not what I think. I think we have failed in some
respects, and generally not done so well in respect of privacy.

> security engines, without constraint on actors on the communication

Sorry, I don't get what your comment is getting at.

> wishes to cater for "security policy agility" as I alluded to above, so

I wouldn't call it an "admission". Again though, I'm not clear
if you're asking for some change or not.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 Jan 2014 19:46:12 +0000

> of single issue technical politics on the output of our document stream.

But Ted also pointed out that there is already plenty of ammunition
for an overly zealous AD to use to have that bad effect. And you and
others are I think also saying that that did happen in the past. If so,
then this BCP will have no impact in that respect - what is already
possible will continue to be possible regardless of what happens with
this draft.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 Jan 2014 21:39:18 +0000

Hi Steve,

A couple of points...

On 01/02/2014 04:03 PM, Stephen Kent wrote:
> thus it IS an attack. 

I fully agree its an attack, but the point of indistinguishable
is not to be polite, but rather to counter those who'd declare
that it is not an attack because their government only ever do
good things. That is also important. (And is the main reason for
this response as its a new point, I think most of the stuff
below is repetitive.

> Tim Bray's message characterized the current draft

I think I responded to that (wasn't it on list too? but anyway...).

> and active wiretapping at any point along a communication path. 

"a path" != many paths which is what we've now seen to be the case

> We
> encryption. 

Sorry, no - those are fine tools but they do not fully protect.
For example S/MIME doesn't cover mail headers etc.

> These protocols also usually incorporate data integrity and

If that last is meant to mean that we've already done enough
then I don't share that view.

> considered when designing security protocols. 

I don't think that's defensible to be honest if you mean that
we've long considered this scale and kind of attack and designed
countermeasures accordingly.

> Thus I believe this
>    ofthe communications channel over which the end-systems communicate.

Again, that talks about "the" channel though.

> qualitatively different, and thus merits this declaration by the IETF.

I don't agree to be honest that that is needed. The fact of the attack
is sufficient justification, compared to previous consideration of
potential, not actually exploited, threats.

> and active wiretapping as likely attacks in the past.

I agree we did consider those. But in too limited a way as it turns
out.

> be the limit of our security protocols.

I strongly disagree with that last point. If we are ever to succeed
with end-to-end email security for example (which I doubt), then that
would have to encompass web-UAs as an inherent part of the overall
system. Thus the security of the message store and submission server
would be intimately related to any e2e confidentiality mechanism.
And of course, we'd also need to counter spam somehow. Those are real
requirements that show that our threat models do need to extend to
some (but not all) aspects of host security.

Regards,
S.

---

From: Eric Rosen <[email-masked]>
Date: Fri, 03 Jan 2014 11:34:19 -0500

Stewart> The -03 text is a significant improvement, but I still fear the
Stewart> impact of single issue technical politics on the output of our
Stewart> document stream.

Let's face it, the draft is nothing but a political manifesto, and the IETF
has no business even considering it.  It is also clear from this discussion
that there is no consensus, even rough consensus, in favor. 

Note the tone taken by proponents of the draft.  It has been suggested that
critics are at best wasting everyone's time, and at worst unethical.  When
it is pointed out that one cannot determine from the draft what the actual
impact on IETF process is, the proponents yell "there's no time to consider
the details, Rome is burning, we can't afford the time to listen to people
who disagree with us".  The claim that we have to act immediately, even
though we don't know what we need to do, is particularly ridiculous.  This
is all typical political discourse: ratchet up the volume of the sound
bites, claim the support of a "silent majority", and yell that the
dissenters are bad people who shouldn't be listened to.  This should not be
considered to be an acceptable mode of discourse in the IETF.

StephenF> But Ted also pointed out that there is already plenty of
StephenF> ammunition for an overly zealous AD to use to have that bad
StephenF> effect. And you and others are I think also saying that that did
StephenF> happen in the past.

Routinely.  Some past ADs are absolutely notorious in this regard, some from
an excess of zeal, and some from a strong conviction that they just know
what is best for everyone else.

StephenF> If so, then this BCP will have no impact in that respect - what is
StephenF> already possible will continue to be possible regardless of what
StephenF> happens with this draft.

Well, here's a particularly egregious example of poor reasoning:  "since it
is already possible for the Security ADs to abuse their power, giving them
more tools and more excuses for doing so will have no effect."  An obvious
non-sequitur, but a good sound bite.

It is true that the ADs already have plenty of opportunities to replace WG
consensus with their personal prejudices.  Let's not give them any more.
This draft isn't what makes abuses possible, it just makes them a lot more
likely.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 3 Jan 2014 11:48:59 -0500

> non-sequitur, but a good sound bite.

The point of the IETF stating a position on this is not to give ADs another thing they can hassle document authors about.   It is to formally encourage document authors and working groups to think about the issue.

> critics are at best wasting everyone's time, and at worst unethical.

I don't recall seeing anyone suggesting that.   Maybe I missed something—there have been a lot of messages.  I do see a flaming diatribe from you, though.   If you are finding others' rhetoric uncomfortable, it might be worth listening to your own with a more critical ear!   :}

---

From: Scott Brim <[email-masked]>
Date: Fri, 3 Jan 2014 11:52:53 -0500

On Fri, Jan 3, 2014 at 11:34 AM, Eric Rosen <[email-masked]> wrote:
> has no business even considering it.

If so, what politics? If you look closely at the draft and not so much
at what people are assuming about it, it is straightforward: pervasive
monitoring, for whatever cause, is indistinguishable from an attack;
the ease of such attacks is increasing; the IETF is behind the curve;
so we're going to do more to make it possible to resist such attacks.

Is there something in that that you disagree with?

> It is also clear from this discussion

The problem with consensus is that people thought this draft either
should recommend specific actions, or was recommending specific
actions. Either would be wrong - the specific actions need to be
considered in specific contexts. I hope that has been made clear by
discussion.

> critics are at best wasting everyone's time, and at worst unethical.

There's a great deal of noise and confusion. Ignore statements that
you know are just wrong unless they come from those behind the draft,
as opposed to those claiming to represent their views (like me) or
those just commenting on it.

> When

I didn't see any of that from people who are actually responsible for the draft.

> non-sequitur, but a good sound bite.

Yes, that was too casual.

Personally, I don't think making a general statement about pervasive
monitoring is going to give ADs any more power than they have now.
Think about when Jeff Schiller was AD and how he used the power of the
security audit (aside: I thought it was a good thing), and think about
how the flow is now. No powers have been taken away and yet somehow we
have a balance, and our protocols are better for the security
considerations. In terms of drafts you might produce, this is another
(major) facet to be considered, it's not granting a new power.

Scott

---

From: Eric Rosen <[email-masked]>
Date: Fri, 03 Jan 2014 12:33:58 -0500

Scott> Is there something in that that you disagree with?

The issue isn't whether I agree or disagree with it, it's whether the IETF
should be making this foray into politics.  

Scott> Ignore statements that you know are just wrong unless they come from
Scott> those behind the draft,

That would only make sense if the draft were presented as an
individual-stream draft that represents only the authors' opinions, but does
not impact IETF process.

Ted> The point of the IETF stating a position on this is not to give ADs
Ted> another thing they can hassle document authors about.

One has to look at the likely impact of the draft, not merely at the
intentions of the authors.

---

From: Scott Brim <[email-masked]>
Date: Fri, 3 Jan 2014 12:42:25 -0500

> should be making this foray into politics.

What politics? Do you agree that pervasive monitoring can be an
attack, and thus even "good" pervasive monitoring is indistinguishable
from an attack? Do you agree that we should make it possible to resist
attacks? Those seem to be straightforward statements.

> intentions of the authors.

I meant: look for clarity from those who might actually provide it. I
believe you're saying that people's responses to the draft as it
stands show how they are going to respond to it if it's published --
ie the problem isn't the draft so much as its interpretation ... ?
Yes, that's pretty clearly a problem so far. Perhaps if it were
simplified way down, people couldn't read into it so much.

Scott

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 03 Jan 2014 19:36:27 +0100

>Is there something in that that you disagree with?

I think pervasive monitoring is possible without taking any action that
is indistinguishable from an attack.

If the draft defines "pervasive monitoring" or "attack" so there cannot
be "pervasive monitoring" without taking any action that is indisting-
uishable from an "attack", ...
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Melinda Shore <[email-masked]>
Date: Fri, 03 Jan 2014 10:00:19 -0900

> intentions of the authors.  

I don't know if I'd use "likely" here but I definitely think
the IETF should be somewhat more thoughtful about "possible."

I've been trying to figure out if there's a way forward that
doesn't involve bulldozing the dissenters.  Personally, I'd be
fine with publishing it as informational or experimental, or
if the document provided a lot more clarity about the basis for
review (along the lines of 3552).

Melinda

---

From: Ted Lemon <[email-masked]>
Date: Fri, 3 Jan 2014 14:22:39 -0500

> intentions of the authors. 

I'm sorry, I know that there have been some really painful incidents in the past, and that people are sensitized to the potential for a repeat, but I'd like to think that the IETF has learned from those experiences.

You say that we are edging into politics here, but I don't think that's true.   I think that it's entirely appropriate for us to document pervasive monitoring as an attack, because it is one.   If you disagree with that, that's fine, I'd like to hear your explanation.   If you agree that it's an attack, but think the IETF doesn't need to address it, I'd like to hear about that.   But it seems to me that you are doing neither of those things.

I think one likely impact of this draft is that authors and working groups will take pervasive monitoring more seriously as a threat when they are designing their protocols.   It's also possible that ADs will use this document as a bludgeon.   I don't think anyone on the current IESG wants to see that happen.   If you completely disagree that authors and working groups ought to be thinking about this, then I can see why you would argue for simply scrapping the document.   But if you are solely trying to address the concern that the IESG will go mad with power, then let's talk about how to tweak the document to address that concern.

---

From: "Stewart Bryant (stbryant)" <[email-masked]>
Date: Fri, 3 Jan 2014 20:36:38 +0000

I have been wondering whether a simple update to "A Guide to Writing A Security Considerations Section" is all that is needed to address the problem in hand?

Stewart

Sent from my iPad

> On 3 Jan 2014, at 19:00, "Melinda Shore" <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 04 Jan 2014 13:38:32 +1300

> should be making this foray into politics.  

It would be politics if the draft said that (for example) it's
OK for the Fives Eyes consortium to perform pervasive
monitoring, but it's not OK for some other organisation to do
so. Or it would be politics if it said the opposite. It very
carefully doesn't say either of those things or anything like
it. It says that pervasive monitoring is in practical terms a
security attack and that we intend to take this into account in
future IETF work. How is that politics?

There is a political debate going on, but not here.

    Brian

---

From: <[email-masked]>
Date: Sat, 4 Jan 2014 00:42:44 +0000

Sigh. That is in itself a political stance.

Jeff Schmidt's Disciplined Minds has a good overview of the political mindset of the professional workforce.

http://disciplinedminds.tripod.com

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [[email-masked]] On Behalf Of Brian E Carpenter [[email-masked]]
Sent: 04 January 2014 00:38
To: [email-masked]
Cc: John C Klensin; IETF Discussion; Stewart Bryant
Subject: Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive Monitoring is an Attack) to Best Current Practice

    Brian

---

From: <[email-masked]>
Date: Sat, 4 Jan 2014 00:45:31 +0000

"Please include a full explanation of how pervasive monitoring is mitigated in this protocol. If this protocol is not fully cryptographically secure to defeat  pervasive monitoring, explain why not."

Yeah, that gives complete design control to the security AD.

Which problem is being addressed, exactly?

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [[email-masked]] On Behalf Of Stewart Bryant (stbryant) [[email-masked]]
Sent: 03 January 2014 20:36
To: Melinda Shore
Cc: [email-masked]
Subject: Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive Monitoring is an Attack) to Best Current Practice

Stewart

Sent from my iPad

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 04 Jan 2014 00:53:23 +0000

Lloyd,

On 01/04/2014 12:45 AM, [email-masked] wrote:
> "Please include a full explanation of how pervasive monitoring is
> mitigated in this protocol. If this protocol is not fully
> cryptographically secure to defeat  pervasive monitoring, explain why
> not."

What are you quoting? That text is *not* part of the
draft, nor do I recall it being sent to the list by
anyone.

Surely inventing quotes is not fair game here?

S.

> Lloyd Wood http://about.me/lloydwood 
> ________________________________________ From: ietf
> [[email-masked]] On Behalf Of Stewart Bryant (stbryant)
> [[email-masked]] Sent: 03 January 2014 20:36 To: Melinda Shore 
> Cc: [email-masked] Subject: Re: Last Call:
> <draft-farrell-perpass-attack-02.txt> (Pervasive Monitoring is an
> Attack) to Best Current Practice
> 
> I have been wondering whether a simple update to "A Guide to Writing
> A Security Considerations Section" is all that is needed to address
> the problem in hand?
> 
> Stewart
> 
> Sent from my iPad
> 
>>> On 1/3/14 8:33 AM, Eric Rosen wrote: One has to look at the
>>> likely impact of the draft, not merely at the intentions of the
>>> authors.
>> 
>> I don't know if I'd use "likely" here but I definitely think the
>> IETF should be somewhat more thoughtful about "possible."
>> 
>> doesn't involve bulldozing the dissenters.  Personally, I'd be fine
>> with publishing it as informational or experimental, or if the
>> document provided a lot more clarity about the basis for review
>> (along the lines of 3552).
>> 
>> Melinda
>> 
> 
>

---

From: Sean Turner <[email-masked]>
Date: Fri, 3 Jan 2014 20:09:52 -0500

> I think one likely impact of this draft is that authors and working groups will take pervasive monitoring more seriously as a threat when they are designing their protocols.   It's also possible th…

Ted’s one likely impact is pretty much exactly why I agreed to sponsor this draft; I also hoped that the end result coupled with RFC 6973 would be akin to the two punch combo of BCP 61 & 72.

I guess I’m not shocked and a little amused that we ended up discussing process impacts especially wrt to this draft knowing Stephen and how much he absolutely loves process.  But, I guess that’s because everybody wants to know how publication of this draft will affect their standard’s experience (or that we “engineer" everything).  But, the word reasonable in Tim’s message jogged my memory about another conversation I had:

> From: Tim Bray <[email-masked]>
> 
> There are very few (any?) absolutes in any of the protocols we build, just a wealth of often-conflicting design criteria, which force us to trade off and make judgment calls.  draft-perpass-attack says that mitigation of pervasive surveillance should be seen as one of the design criteria, and it’s not OK to ignore it. A reasonable take is that a specification could be held up if there are plausible arguments that this criterion has not been given appropriate consideration, and I see nothing wrong with that. Similar hold-ups regularly occur when there are concerns that there hasn’t been appropriate consideration for efficiency or error-handling or, well, lots of other criteria. 

When I read this draft for the first time, I wondered among other things:

Could publishing this draft make the Internet work better?  Some consider better to be more secure/private so sure I can see that it could and in fact support that thinking.

Could publishing this draft harm the Internet?  (I guess I’m probably not supposed to be sarcastic here but I can’t help myself) I couldn’t think of a reason, but I guess I’m not paranoid enough to have thought about the DoS attack that the IESG can levy against authors ;)  More seriously, there’s plenty of checks on abuse of power in the IETF (appeals, recalls, negative re-up comments).  What you might not know (or believe) is that the IESG does also self-regulate itself somewhat - if an AD is going off the deep end they’re going to hear about it from another AD.

Is the draft requesting anything unreasonable or overly burdensome? In my mind, no on both accounts.  In fact, there are already protocols/directorates that require this; thank you MIB Doctors for requiring of MIBs that sensitive information or information that raise significant privacy concerns be explicitly listed by name and the reasons for the sensitivity/privacy concerns MUST be explained (see RFC 4181).

Is there an out?  Yes.  If you’ve got a reason to “monitor”, then you just need to explain why, which is not unlike other “outs”: confidentiality not always required if you explain why (BCP61), AKM unless … (BCP 107), we also give outs to experimental protocols (lisp and mptcp comes to mind), etc.  

Is there unnecessary process being introduced?  I thought not.

Is BCP appropriate?  Sure! We’ve published BCPs that document what we want done as a best practice and what is a best current practice.  I’ve tilted at this windmill both ways and no longer tilt.

Is it all figured out?  No, but that is just fine in my book.  There’s some wicked smart people that participate in the IETF and we’ll figure the process/impacts either now or as we go along.  So we can:

1) Publish now, learn as we go, and then publish the normative bits later.

2) Study for [insert timeframe] and then publish the normative bits later way we know how later.

Possibly naively, I think that publishing now and dealing with the growing pains of learning as we go option is a bit more in spirit of what the IETF is supposed to be about.  The latter option to me sounds a lot like what people complain about wrt the IETF process taking too long and having the bar be too high for the proposed standard level.

spt

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 04 Jan 2014 02:10:43 +0100

>Surely inventing quotes is not fair game here?

The quote marks indicate that the text is a paraphrase; Lloyd Wood re-
states the meaning, or a possible interpretation, of the text, likely
to illustrate a problem with the text. This is a common discourse tech-
nique and should be entirely obvious; nothing unfair about it.

If it does not reflect the intended meaning of the text, then there are
various ways to make that very explicit in the text, for instance, it
could literally say that "full explanation of how pervasive monitoring
is mitigated" is not expected or required. Then it should be obvious
that the above is not a permissable paraphrase.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 04 Jan 2014 01:19:34 +0000

> that the above is not a permissable paraphrase.

The text (I hate to bring it up, seems almost unfashionable;-),
says:

   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
   addressed?"

Lloyd's "paraphrase" is entirely unlike the actual text. His
quote marks, are, like his argument, entirely bogus. (And not
even funny, which is often a redeeming quality of Lloyd's
posts:-) Given that there seems to be a trend to ignore the
actual text, and that that I've already commented on that, I
think yes, his supposed quote is out of order. Perhaps you
don't, and that's fine, but I do.

S.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 04 Jan 2014 02:33:47 +0100

>don't, and that's fine, but I do.

If you think it would be a serious problem if the text is interpreted as
in the paraphrase above, then I think revisions to the actual text are
in order, because if there is any difference between the actual text and
the paraphrase, I find it hard to impossible to make out. It is not fine
to keep the text as-is if it is easy to misinterpret.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 4 Jan 2014 02:34:41 +0100

I think if we want to do a practice solution roadmap together we need the
draft to add more editors for diversity or include at least two more
(recommending Dave and Melinda). Secondly the draft to state relating to
the current plan practice what IAB and IESG should do? And what WGs should
do? Is there a team work between the bodies or there is continuous
separation as old days? Why the draft only states for IETF
community confirmation and responsibilities and ignores the IAB and IESG
responsibilities in future actions? Couldn't this draft be a joint work of
all bodies?

IMHO the previous IESG and IAB are responsible for the defined attacks as
well and they should take different strategies in working with IETF
community. The draft should be written in a way to guide bottom designs but
also upper designs.

AB

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 04 Jan 2014 01:35:37 +0000

> to keep the text as-is if it is easy to misinterpret.

I welcome honest attempts to improve the text. Lloyd's was
not that.

Feel free to propose better text, I'll be happy to see that.

S.

---

From: <[email-masked]>
Date: Sat, 4 Jan 2014 01:46:15 +0000

Stephen,
Stephen

I am responding to Stewart's suggestion with a suggestion of the likely added text to the Guide he suggests a "simple update" to. Which would go beyond the 'think about monitoring' to 'explicitly write up how monitoring is handled' on the way to full security protocol emphasis. Which is what doomed work in DTNRG and made it irrelevant to its problem space, by the way.

I quoted stewart's email is full below before responding to it. That is the usual thing to do.  I hope this helps with reading comprehension.

Before you check, "simple update" is not in your draft either.

I don't think pushing policy through rapidly here is fair game either.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: Stephen Farrell [[email-masked]]
Sent: 04 January 2014 00:53
To: Wood L  Dr (Electronic Eng); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive Monitoring is an Attack) to Best Current Practice

Lloyd,

S.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 04 Jan 2014 17:15:43 +1300

On 04/01/2014 14:19, Stephen Farrell wrote:

>    It means

I think this is an excellent question for a reviewer to ask,
regardless of whether the present draft is published as a BCP,
an Informational document, or never.

Responsible engineering means considering a great number of
eventualities when finalising a design, and this is just one
more of those eventualities.

     Brian

---

From: Tim Bray <[email-masked]>
Date: Fri, 3 Jan 2014 21:30:08 -0800

> nique and should be entirely obvious; nothing unfair about it.

No ***ing way.  Drafts say what they say, and recasting them in other words
and putting quotes around the transmogrified version is completely out of
bounds.

The quality of this discussion would be greatly improved if it were to
refocus on what the draft actually asserts and proposes.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 4 Jan 2014 01:42:17 -0500

> Sigh. That is in itself a political stance.
So is the Internet.

As well as murdering his uncle a couple of weeks ago, the tyrant running
North Korea murdered 80 people for having ipods and would doubtless have
done the same for Internet.

---

From: Hector Santos <[email-masked]>
Date: Sat, 04 Jan 2014 02:08:33 -0500

Here is my "paraphrase" or "interpretation:"

     Please remember to do your homework when it comes to ethical and
     societal design considerations, if any. Authors SHOULD ALWAYS
     be prepared to answer any questions related to such design
     considerations.

I think the problem is the lack of a section or "checklist" that one 
should be considering - ALWAYS.  The RFC templates should be a section 
with a baseline description:

     The author(s) of this document does not believe there are "pervasive
     monitoring" related attacks [RFCXXXX] in this specification.

Having this in the templates is a form of a "checklist" not only the 
authors can not avoid, but also reviewers.   At the end of the day, we 
don't want any possible considerations to "fall through" the 
proverbial "cracks."  Reviewers, participants, implementers need to be 
able to put the authors to the task to do their homework.

Ideally, "ethical IETF engineers" don't need these type of reminders, 
but it helps to have a "checklist."

My "Opinion"

-- 
HLS

---

From: Scott Brim <[email-masked]>
Date: Sat, 4 Jan 2014 09:56:30 -0500

> more of those eventualities.

Some of us who do reviews already consider it, and are willing to
argue to get drafts fixed if they have privacy problems. This is just
making it a general IETF practice.

---

From: Scott Brim <[email-masked]>
Date: Sat, 4 Jan 2014 10:00:28 -0500

On Sat, Jan 4, 2014 at 2:08 AM, Hector Santos <[email-masked]> wrote:
> I think the problem is the lack of a section or "checklist" that one should
> be considering

Yes but in this case we have the security considerations guidelines,
and could add a pointer to RFC 6973 and whatever new one comes out of
perpass. No need for a new section.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 04 Jan 2014 16:01:18 +0000

> A Security Considerations Section" is all that is needed to address

After a bit of offlist mail with Stewart, it turns out I had
misinterpreted the above.

I now believe (haven't quite confirmed, but its a fine idea
anyway so worth raising here) that what Stewart meant was
not to open up 3552 and add this text, (which'd take years) but
rather to make the RFC resulting from this draft be just another
part of BCP72 (aka RFC 3552).

(In case folks don't know, BCPs can be made up of multiple RFCs,
e.g. BCP 10 [1] is like that.)

I think that's quite an interesting idea, and would probably only
require adding a sentence or two to relate this text to that in 3552
(which is currently all of BCP72). I'd certainly have no problem
were that the outcome.

I guess that just might help folks with concerns that as a new BCP
this might be over zealously applied.

But I'm not sure - would that in fact help anyone with such concerns?

Cheers,
S.

PS: This might make suggest a fine longer term plan to work on a
broader revision of BCP72 as we better appreciate privacy concerns
in general and pervasive monitoring.

[1] http://tools.ietf.org/html/bcp10

---

From: "Stewart Bryant (stbryant)" <[email-masked]>
Date: Sat, 4 Jan 2014 19:14:58 +0000

Sent from my iPad

> On 4 Jan 2014, at 16:01, "Stephen Farrell" <[email-masked]> wrote:
> 
> 
> 

Yes, that is what I meant. An RFC that says updates RFC3552 in
the top left corner, and provides advise on this security issue in
the same manner and style that RFC3552 deals with all the other
important security issues.

- Stewart

---

From: Scott Brim <[email-masked]>
Date: Sat, 4 Jan 2014 14:54:11 -0500

Yes. I thought that would be the NEXT step after this draft. But let's not
skip this one. The next will take a bit of time, so let's publish this one
so the world can see our position.  Once the next one is done it can
incorporate this one and obsolete it.

Scott
On Jan 4, 2014 2:15 PM, "Stewart Bryant (stbryant)" <[email-masked]>

---

From: Melinda Shore <[email-masked]>
Date: Sat, 04 Jan 2014 10:57:40 -0900

On 1/4/14 10:54 AM, Scott Brim wrote:
> Yes. I thought that would be the NEXT step after this draft. But
> let's not skip this one. The next will take a bit of time, so let's
> publish this one so the world can see our position.  

So it's a position statement, not a process standard?

Melinda

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 05 Jan 2014 09:01:01 +1300

> important security issues.

But, RFC 3552 has a lot of technical meat, and RFC 3365 has quite
specific technical content too. I don't see the present draft as being
in that category at all.

I agree that we need equivalents of those two RFCs for this issue.
There's technical analysis heading in that direction in RFC 6973
and there's draft-trammell-perpass-ppa, but work remains to be done.

    Brian

    Brian

---

From: Scott Brim <[email-masked]>
Date: Sat, 4 Jan 2014 15:52:08 -0500

> So it's a position statement, not a process standard?

Well, my guess (not being a primary contributor) is that there is a
process change: we're going to give more heed to privacy in security
considerations.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 07 Jan 2014 08:00:44 +0100

Stephen,

Speaking only for myself, of course, with two caveats I support the
publication of this draft.  The first is that I would prefer still that
it be informational.  There just isn't sufficient elaboration in this
work to support BCP, nor could we get that elaboration if we want this
draft to go out soon.  I also propose a one word change below.

> But I'm not sure - would that in fact help anyone with such concerns?

There is an impedance mismatch between RFC-3552, which contains
substantially more specific guidance – with examples – on how to deal
with security considerations after a long and trying period of
establishing that procedure, and the new requirements we see in this
document, which are of a very general nature, and where the threat is
not yet well understood.

As Stewart wrote, -03 is considerably better than previous versions. 

>    pervasive monitoring relevant to this work and if so how has it been

The first sentence is perfectly clear.  The 2nd sentence is perfectly
clear.  I would prefer that the question in the 3rd sentence read "how
has this been considered?"  This is consistent with the 1st sentence
with regard to justifications, and also gives us time to more properly
evaluate the threat model.  I hope the IAB and W3C workshop will further
advance our understanding so that more guidance is available.

If this change is made, then the BCP is what I would class "good
enough", even though my preference would be for Informational.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 07 Jan 2014 12:45:03 +0000

Hi Eliot,

Great that -03 works better for you too. I'd have no problem
with your additional change. (I'll let Jari tell me what he
wants wrt that when the LC's done, but have noted it in my
working copy.)

S.

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 7 Jan 2014 10:18:56 -0500

> that there is no consensus, even rough consensus, in favor.

Anyone who has been around in the IETF long enough has seen this
before. Rabid opposition to real consideration of strong security. I
have seen yelling at plenaries. I've heard people say how the IETF
will be destroyed or become irrelevant if we don't bow to the US
Government rules. Etc.

If you want to distort the word "political" to try to characterize
this, I don't care that much. This draft is completely in line with
the previous admirable IETF engineering positions on security.

> Note the tone taken by proponents of the draft.  ... one cannot determine from the draft what the actual impact on IETF process is ... claim the support of a "silent majority" ...

Note the tone taken by opponents of the draft. Gross distortions and
mischaracterization of the draft. I hope people reading the IETF
discussion list, if they care about this issue, will actually read the
draft and see what it actually says, which is pretty reasonable.

The intended effect on IETF process is clear enough to me from the
document, at least in version -03.

Determining consensus is an all-sources, kind of thing and the person
judging consensus is entirely within their rights to take into account
meeting, mailing list, personal discussions, etc. I am in the
consensus in supporting this draft and I an not being silent.

>...

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: [email-masked]
Date: Tue, 07 Jan 2014 08:52:18 -0800 (PST)

> > that there is no consensus, even rough consensus, in favor.

All this quibbling over whether or not the document is political, a manifesto,
or whatever, seems pretty pointless to me. All I care about is what the
document says and given that, what the likely effects of having this document
as a BCP are going to be.

> will be destroyed or become irrelevant if we don't bow to the US

The fact that there has been opposition to previous statements about security
does not mean that the opposition to the document at hand has the same
character. The burden of proof for that would be on you and others making
this claim, and thus far I don't see any evidence being presented to support
this underlying claim.

In my own case, I fully supported the publication of RFCs 1984 (weak keys) and
2804 (wiretapping) - the two previous statements of this sort this document
cites. I also argued for the imposition of mandatory to implement ciphersuites
in TLS. And so on - I don't think I've exactly been an opponent of strong
security.

And yet I strongly oppose publication of this document as a BCP. I think it
should be published as an informational document instead. (I should note that I
find the idea of publishing this as experimental to be intriguing, but given
the confusion that has surrounded previous experiments I think this course is
too risky for something this important.)

I find this document to be too vague to function properly as a BCP, and I don't
think we have a sufficient understanding of the tradeoffs involved in making
pervasive monitoring more difficult to write a proper BCP at the present time.
And if anything, hasty and ill-considered changes may make monitoring easier,
not harder.

I think the course advocated by Dave Crocker is the correct one: Publish this
as an informational policy statement, and then work through the policy on
subsequent specifications. Then, once we believe we have a sufficient grasp of
how this actually plays out, write a BCP. (Dave, I think this summarizes your
position, but if not, apologies for getting it wrong.)

I also note that RFCs 1984 and 2804 were both published as informational. Maybe
I missed it, but I find nothing in the document itself that explains why this
time is different and publication as BCP is warranted.

> the previous admirable IETF engineering positions on security.

Which would argue for handling this one the same way, would it not?

> > Note the tone taken by proponents of the draft.  ... one cannot determine
> > from the draft what the actual impact on IETF process is ... claim the support
> > of a "silent majority" ...

(This is really off topic, but since you raised the issue, I'll make one
comment about it. I have no intention of discussing this further.)

The tone taken by both sides in this argument has been quite poor. That said,
my impression has been that there has been more impugning of motives from
supporters than from opponents.

> draft and see what it actually says, which is pretty reasonable.

What the draft says is reasonable IMO, but that's really beside the point. The
problem is what the draft does not say. It says we're going to take action to
mitigate attacks but doesn't say how this is going to be done. That vagueness
is fine for an architectural policy statement but leaves far too much leeway
for a BCP.

> document, at least in version -03.

I have no doubt the intentions here are good. But all too often intended and
actual results diverge.

				Ned

---

From: Stephen Kent <[email-masked]>
Date: Tue, 07 Jan 2014 12:59:11 -0500

Stewart,

> I have been wondering whether a simple update to "A Guide to Writing A Security Considerations Section" is all that is needed to address the problem in hand?
Good question.

RFC 3552 contains a threat model, and we need to update that threat model.
The I-D just released by Richard Barnes et al. seems to addressing that.
If we were to combine a new threat model, which explicitly accounts
for PM, with updated security considerations guidance, then I think we would
have what Stephen's doc alludes to at the end, i.e., guidance to RFC authors
on what we now consider to be the threat environment, and what we believe
needs to be done, vis-a-vis topics address in each security-relevant RFC.

That may argue for Stephen's doc being Informational, maybe even transient,
as the real focus is on what we will do in response to declaring PM a
serious concern.

Steve

---

From: Dave Crocker <[email-masked]>
Date: Tue, 07 Jan 2014 11:58:15 -0800

> position, but if not, apologies for getting it wrong.)

I've advocated Experimental, though I've thought Informational would 
also be ok.  On further reflection from people's comment, I now think 
Informational would be the sufficient and safer choice.

The more important issue is that the draft does usefully introduce the 
topic of PM to IETF work.

d/

---

From: Scott Brim <[email-masked]>
Date: Thu, 9 Jan 2014 13:05:45 -0500

On Tue, Jan 7, 2014 at 2:58 PM, Dave Crocker <[email-masked]> wrote:
> I've advocated Experimental, though I've thought Informational would also be
> ok.  On further reflection from people's comment, I now think Informational
> would be the sufficient and safer choice.

There's nothing to experiment on, nothing to report back on. It tends
toward Informational.

The inclination to make it a BCP would come from the fact that it's
the basis for extending an existing BCP. However, it does not actually
do the extending, it just sets the stage and the direction.

As I said before (on some thread) I now believe this should be
published as informational and then when a more specific BCP-level
draft is written, this one can be reiterated in a section near the
top.

> The more important issue is that the draft does usefully introduce the topic
> of PM to IETF work.

Yes. Any status is acceptable to me, let's just get it out.

Scott