Pervasive Monitoring Is an Attack
RFC 7258

[Ballot comment]
Now, I will try to convince myself that this document is more a statement of principles than an enforcement tool.
THE only sentence that goes in this direction is: "An appropriate balance will emerge over time as real instances of this tension are considered."  This is pretty light and goes against :

  The IETF community
  has expressed strong agreement that PM is an attack that needs to be
  mitigated where possible, via the design of protocols that make PM
  significantly more expensive or infeasible.

Regardless of what the authors may say now, I have some concerns, as others have expressed during the IETF LC asking for more balance, that this document will be used as an enforcement tool against some future OPS developments.
However, nothing really actionable at this point, except if the community would be ready to add: "this document is more a statement of principles than an enforcement tool."

[Ballot comment]
Updated at the bottom ...

I'm mostly OK with the text in -05, but in section 2, I'm concerned that the draft is accurately reflecting conflicting goals:

- we need to mitigate PM
- we need to allow limited-scope monitoring
- we can't tell the difference in any technical way, so
- I'm not sure we can do both at the same time

Do we think we can figure that out?

Without resorting to http://www.nancyclaxton.net/uploads/3/4/6/9/3469502/525284.jpg, of course.

Update:

I'm looking at 3.  Process Note

  In the past, architectural statements of this sort, e.g., [RFC1984]
  and [RFC2804] have been published as joint products of the Internet
  Engineering Steering Group (IESG) and the Internet Architecture Board
  (IAB).  However, since those documents were published, the IETF and
  IAB have separated their publication "streams" as described in
  [RFC4844] and [RFC5741].  This document was initiated by both the
  IESG and IAB, but is published as an IETF-stream consensus document,
  in order to ensure that it properly reflects the consensus of the
  IETF community as a whole.

I honestly remembered this text saying something different than it says. I thought the plan was that the IETF and the IAB agreed, so we would have published the doc jointly, but we now have separate streams, so ...

But all I'm seeing is that the IESG and IAB both *initiated* this draft. Is that all the IAB is likely to say? (he asked the IESG and not the IAB, but mumble)

I started to edited my comments to ask "what does it mean when the IAB endorses this but the IETF publishes it as Informational?", but obviously I've gotten ahead of that question - sorry.

[Ballot comment]
Updated at the bottom ...

I'm mostly OK with the text in -05, but in section 2, I'm concerned that the draft is accurately reflecting conflicting goals:

- we need to mitigate PM
- we need to allow limited-scope monitoring
- we can't tell the difference in any technical way, so
- I'm not sure we can do both at the same time

Do we think we can figure that out?

Without resorting to http://www.nancyclaxton.net/uploads/3/4/6/9/3469502/525284.jpg, of course.

Update:

I'm looking at 3.  Process Note

  In the past, architectural statements of this sort, e.g., [RFC1984]
  and [RFC2804] have been published as joint products of the Internet
  Engineering Steering Group (IESG) and the Internet Architecture Board
  (IAB).  However, since those documents were published, the IETF and
  IAB have separated their publication "streams" as described in
  [RFC4844] and [RFC5741].  This document was initiated by both the
  IESG and IAB, but is published as an IETF-stream consensus document,
  in order to ensure that it properly reflects the consensus of the
  IETF community as a whole.
d 3.  Process Note

  In the past, architectural statements of this sort, e.g., [RFC1984]
  and [RFC2804] have been published as joint products of the Internet
  Engineering Steering Group (IESG) and the Internet Architecture Board
  (IAB).  However, since those documents were published, the IETF and
  IAB have separated their publication "streams" as described in
  [RFC4844] and [RFC5741].  This document was initiated by both the
  IESG and IAB, but is published as an IETF-stream consensus document,
  in order to ensure that it properly reflects the consensus of the
  IETF community as a whole.

I honestly remembered this text saying something different than it says. I thought the plan was that the IETF and the IAB agreed, so we would have published the doc jointly, but we now have separate streams, so ...

But all I'm seeing is that the IESG and IAB both *initiated* this draft. Is that all the IAB is likely to say? (he asked the IESG and not the IAB, but mumble)

I edited my comments to ask "what does it mean when the IAB endorses this but the IETF publishes it as Informational?", but obviously I've gotten ahead of that question - sorry.

[Ballot discuss]
My previous DISCUSS DISCUSS contained my own thoughts on the topic, was created to start the discussion within the IESG, and was not really actionable (hence the DISCUSS DISCUSS). This discussion took place during the informal telechat.

This is an important document, specifically as it relates to network operations and management protocol developments.

Not all PMs are attacks.  Take IPFIX, take data leakage analysis (done on all traffic existing an enterprise network, IP SLA measurements done all branch offices or all Point of Presence (PoP), etc. These are not attacks.
What makes a difference IMO is the notion of network operators managing their network versus the PM being used to gather information outside of the management domain.
So adding this notion of "outside the management domain" to PM would make sense to me.

[Ballot comment]
Now, I will try to convince myself that this document is more a statement of principles than an enforcement tool.
THE only sentence that goes in this direction is: "An appropriate balance will emerge over time as real instances of this tension are considered."  This is pretty light and goes against :

  The IETF community
  has expressed strong agreement that PM is an attack that needs to be
  mitigated where possible, via the design of protocols that make PM
  significantly more expensive or infeasible.

Regardless of what the authors may say now, I have some concerns, as others have expressed during the IETF LC asking for more balance, that this document will be used as an enforcement tool.
However, nothing really actionable at this point, except if the community would be ready to add: "this document is more a statement of principles than an enforcement tool."

==================================================================

Below is some good feedback fromDan Romascanu (OPS DIR review):
The principal impact that this document has on operations and management of the IETF protocol is included in the following paragraph in Section 2:

  While PM is an attack, other forms of monitoring can be beneficial
  and not part of any attack, e.g. network management functions monitor
  packets or flows and anti-spam mechanisms need to see mail message
  content.  Some monitoring can even be part of the mitigation for PM,
  for example Certificate Transparency [RFC6962] involves monitoring
  Public Key Infrastructure in ways that could detect some PM attack
  techniques.  There is though a clear potential for monitoring
  mechanisms to be abused for PM, so this tension needs careful
  consideration in protocol design.  Making networks unmanageable to
  mitigate PM is not an acceptable outcome, but ignoring PM would go
  against the consensus documented here.  An appropriate balance will
  emerge over time as real instances of this tension are considered.

The text above was carefully crafted and debated during the various reviews I believe that it is OK as it is, but the OPS community should debate whether work is necessary in the area (maybe in the OPSEC WG) in order to look at the following aspects:

-    Issue recommendations that could help protect the tools (applications, protocols, data repositories) used by operators for the day to day tasks or running and managing the networks from being used for pervasive monitoring (in the words of the document – how can we make sure in practical terms that useful monitoring mechanisms are not abused for PM?)

-    Review the existing protocols designed in the OPS area which have broad deployment and make sure that they have been designed in such a manner that the threat of a pervasive monitoring attack can be mitigated. If necessary (gaps were found out) issue recommendations for ‘ruggedizing’ these protocols against PM attacks

A few more observations:

-    In Section 2 the following sentence is IMO not clear enough: ‘It means that, if asked, there needs to be a good answer to the question "is pervasive monitoring relevant to this work and if so how has it been considered?"’ Who asks? Is this about the IESG reviews, or maybe about some kind of privacy assessment (done by whom?)

-    I found too little relation between this document and RFC6973. That Informational RFC provides actually a set of good recommendations on mitigation for privacy issues, many of them directly applicable against PM threats. It is also a very recent document, published only six months ago. It seems odd that the information[RFC6973] is mentioned only once and in an unclear way – the reference is just written in brackets between two sentences, not clear if it belongs to the sentence before or the sentence after.

[Ballot comment]
Adrian in his comment of 2014-02-01 articulates extremely well
points that have been giving me cause for concern since the first
version of this text was put forward, and continue to give me
concern.

To pick the most important points it is my view that the unqualified
use of the word "attack" in most places in the text, whilst sensational
does a dis-service particularly in its wider operational context.

Secondly I am concerned that PM, or techniques similar to PM
have a valid law enforcement use, and that to make PM infeasible
(section 1 para 2) would not be in the best long term interest
of the IETF designed Internet.

The text:

"While PM is an attack, other forms of monitoring can be beneficial
and not part of any attack, e.g. network management functions monitor
packets or flows and anti-spam mechanisms need to see mail message
content."

can be construed to permit the use of PM or similar techniques in
law enforcement but it would be better to explicitly note this.

I am also concerned that the lack of explicit guidance on what is needed
in IETF specifications will cause difficulties  with future RFCs resulting
in inconsistent application of the advice in published RFCs.

I accept however that there is a strong desire by many in the
IETF to submit text for publication before the London meeting, and
therefore consider that I should abstain from further discussion.

[Ballot comment]
I would really, really, really, prefer this document to go as
Informational. 

I find that it takes a deal of wriggling to make this fit the 2026
description of a BCP (although I will grant that that wriggling can
be done successfully). 

The bulk of the text is set up to provide information about what PM is
and how it is considered an attack: only a tiny bit says what we will
do about it.  That last is the potential BCP bit, but the document
really doesn't say enough about what we will do to warrant being a BCP.

I am relatively sure that I heard one of the authors say he didn't much
care whether it went as Informational.

Being Informational ratheer than BCP will address a number of concerns
from the community. While I heard many voices saying "make it
Informational" I do not recall hearing positive voices for BCP (distinct
from people saying you don't need to change it).

I don't believe this is a Discussable point, but I think the authors and
shepherding AD should thing about this a bit more.

---                                   

Each time I read the document I am bothered by the use of "Attack". The
problem I have is exactly explained in e third paragraph of the
document, but that is too late.

The issue is that the term "attack" is being used in a specific context
(that of security) in a document that has a wider readership and
applicablity. The largest concern I have is evidenced by a number of
comments received in reviews, and it is that this specialist usage of a
word is not perceived by some readers who then get "upset" by the
statement that this is a normal-English-language-meaning attack.

The telling point for me is that the Abstract actually sensed this issue
and used "technical attack" which is kind of helpful although it is a
third term that is not used elsewhere in the document.

I took the precaution of talking to a copy editor about how one normally
handles this sort of issue, and the answer leads to some simple changes
to the text. The general solution is to use "Security Attack" instead of
"attack" thereby using a term that fits the paragraph 3 definition and
clearly indicates that a specialist maning is being applied. So:

- Document title s/Attack/Security Attack/
- Running header s/Attack/Security Attack/
- Abstract s/technical attack/Security Attack/
- Section 1 para 2 s/attack/Security Attack/ twice
- and so on throughout the document

I fully expect to hear back that this is a fiddling little change that
is not worth the effort. I think it is worth the effort and makes a big
difference and will happily make the edits.

Again, this is not something that can be Discussable, but given that the
readership of this document will be wide, it behoves us to get this tone
correct.

---

Section 1 para 2

  PM is distinguished
  by being indiscriminate and very large-scale, rather than by
  introducing new types of technical compromise.

Could clarification. suggest it belongs in para 1 not inbetween two                 
sentences about the IETF's views.

---

Section 1 para 4

  The
  motivation for PM is not relevant for this document, but can range
  from non-targeted nation-state surveillance, to legal but privacy-
  unfriendly purposes by commercial enterprises, to illegal actions by
  criminals.

The motivation is not relevant in this document, but we are going to
talk about it anyway :-)

Great to say it is not relevant. Then stop!

But I suspect you wanted to say "We are not specifically targeting
governments in this document" in which case, perhaps it *is* relevant
for this document.

Perhaps what you needed is...

  The
  motivation for PM can range from non-targeted nation-state
  surveillance, to legal but privacy-unfriendly purposes by commercial
  enterprises, to illegal actions by criminals.  The same techniques
  to achieve PM can be used regardless of motivation.
  Thus, we cannot defend against the most nefarious actors while
  allowing monitoring by other actors no matter how benevolent some
  might consider them to be, since the actions required are
  indistinguishable from other attacks.  The motivation for PM is,
  therefore, not relevant for how PM is mitigated in IETF protocols.

---

The text in the main body carefully says

  It means that, if asked, there needs
  to be a good answer to the question "is pervasive monitoring relevant
  to this work and if so how has it been considered?"

Yet other text says

  should be mitigated
  in the design of IETF protocols, where possible.

The correction is probably s/where possible/where appropriate and possible/

---

Section 2 para 1

  Protocols that mitigate PM
  will not prevent the attack, but can significantly change the threat.

Don't agree that all mitigation is only partial.
Thus s/will not/might not completely/

---

Section 2 para 2

  But those generally do not consider PM

Previous sentence has "standards", "mechanisms", and "guidelines". To
which does "those" apply?

Suggest "those  generally"

Is "generally" used because we haven't checked all the documents?

---

Section 2 doesn't half ramble on. I lack the energy to suggest a reduced
version at the moment, but surely it could have been said in a quarter
of the number of words.

---

Section 3 says:

  This document was initiated by both the
  IESG and IAB

Perhaps I slept through that meeting.


====

Nits

Section 1 para 1
"...can also be used..."
I think that "also" is incorrect and should be struck. The previous
sentence did not specify any mechanisms.

---

Section 2 para 2

  confidentiality of protocol meta-data, countering traffic analysis
  nor data minimisation.  [RFC6973] In all cases, there will remain
  some privacy-relevant information that is inevitably disclosed by

The positioning of the citation seems broken.  Should come before
period?

[Ballot comment]
  Some monitoring can even be part of the mitigation for PM,
  for example Certificate Transparency [RFC6962] involves monitoring
  Public Key Infrastructure in ways that could detect some PM attack
  techniques.  There is though a clear potential for monitoring
  mechanisms to be abused for PM, so this tension needs careful
  consideration in protocol design. 

In fact there are a number of activities that might fall under the rubrick of pervasive monitoring or  in same cases pervasive counter-surveillance (certificate pinning comes to mind for the later) that seem necessary in order to detect more active forms of subversion.

This tension with respect to exposure to monitoring also touches on the question of consent, the receiver of unsolicited requests may necessarily have rather different concerns than the sender and that may well result in inputs to protocol design/implementation/usage inconsistent with our concerns.

[Ballot discuss]
This is an important document, specifically as it relates to network operations and management protocol developments.
I'm currently hesitating between a no-record (like Stewart) to buy me some time, but I don't want to lose my chance to put a DISCUSS on it, so let me go for a DISCUSS-DISCUSS for now.
I will update my ballot after the discussion with the IESG, to stress what is DISCUSS worhty.
I also would like to hear from others.
Disclaimer:
* I read the version 00, provided some feedback, and asked questions. Since that, I have not kept up to date with the perpass related emails. A quick search in my system tells me "1942 emails with perpass in the subject", and https://mailarchive.ietf.org/arch/search/?q=perpass shows even more emails.
* I have not had the chance to synch up with Joel Jaeggli on this topic

On the Internet, there are actually conflicting interests:
The end user (and I'm one of them) wants access to every services, with good SLAs all the time, for free, and demand confidentiality on top of that.
The network operators (in a typical enterprise network), on the other hand, have to manage the users, the network, the services, and introduce innovation through some new services.

Point 1: How do we bring innovation to the Internet, and where?
How do we distinguish good attack versus bad attack (referring to the last paragraph of section 1, "In particular, the term attack, used technically, implies nothing about the motivation of the actor mounting the attack. ...")? How do we distinguish pervasive monitoring for a noble goal from the rest (for example: Internet surveillance)
This is the key difference between the security world and my OPS world, between the end user interest and the network operator job.
What's called an attack in the document could actually be the basis for a service in my OPS world:
    - "measuring packet sizes"for a billing service
    - "Active or passive wiretaps and traffic analysis, (..., timing or measuring packet sizes)", required for SLA measurements, in order to understand if voice or video flows should be treated differently than the rest.
    - "including application content ", required for data leakage (a real problem in today networks), malware detection, etc.
    - "looking at traffic header" to route traffic between a primary costly link with SLA, and a cheap backup
    - load balancer
    - traffic redirection (WCCP)
    - etc...
The point is that middleboxes needs to provide a service, and they need some input for that. So if this is not provided by traffic monitoring, the only solution is that the end points need to send their metadata to the middleboxes. This was not well received at the IETF lately, and this goes against the principles of this draft:

  Pervasive monitoring is a technical attack that should be mitigated
  in the design of IETF protocols, where possible.

Alternatively, we could say: all innovation will come from the end points. IMO, some innovation (read some new services) must happen inside the network, as opposed to the end points. Yes, if we had 1000 times the bandwidth we have today on all end points, and btw, no constrained devices, then yes, we could delegate all innovations to the end points. But that's not the case!

Don't get me wrong: I like what this draft tries to do, but it doesn't make any distinction between good and reasons for pervasive monitoring. This leads to my point 2.

Point 2: who decides what's right or wrong?
The following text goes in the right direction for OPS. Thanks.

  While PM is an attack, other forms of monitoring can be beneficial
  and not part of any attack, e.g. network management functions monitor
  packets or flows and anti-spam mechanisms need to see mail message
  content.  Some monitoring can even be part of the mitigation for PM,
  for example Certificate Transparency [RFC6962] involves monitoring
  Public Key Infrastructure in ways that could detect some PM attack
  techniques.  There is though a clear potential for monitoring
  mechanisms to be abused for PM, so this tension needs careful
  consideration in protocol design.  Making networks unmanageable to
  mitigate PM is not an acceptable outcome, but ignoring PM would go
  against the consensus documented here.  An appropriate balance will
  emerge over time as real instances of this tension are considered.

However, who will be the judge to tell whether work at the IETF is a good PM (for monitoring) or a bad PM?
I wonder: if the IPFIX work would starting today at the IETF, would this be considered as a PM and blocked? Who would decide? Consensus based, IESG, IAB?

Point 3: pervasive monitoring versus monitoring
We could say that points 1 and 2 don't matter because the PM definition doesn't apply ("PM is distinguished by being indiscriminate and very large-scale") to the services I described in point 1.
It depends. Data leakage analysis is done all traffic existing an enterprise network, SLA are typical metered in all branch offices or all Point of Presence (PoP), etc.  I guess that  "very large-scale" means outside of the network operator administrative admin? 

Point 4: unmanageable networks
I like this sentence "Making networks unmanageable to mitigate PM is not an acceptable outcome".
Note: half-joking, I mentioned to Stephen after the version 00 of the document, I would be looking for a "close the OPS area" button in the tracker if this "let's have end-to-end privacy at all costs" principle would be accepted without any balance, as they would nothing left to manage in OPS. Maybe that's a good thing. :-)

Not sure where to go from here. I'm not sure.
- I would like to get a discussion with the IESG
- I could also review all perpass emails. If some specific points were discussed already, a pointer to the discussion would be appreciated.
- I could synch up more with the OPS DIR
- I could have a call with the authors
Don't get me wrong, I'm against the document, but we need some more nuance.

Below is some good feedback fromDan Romascanu (OPS DIR review):
The principal impact that this document has on operations and management of the IETF protocol is included in the following paragraph in Section 2:

  While PM is an attack, other forms of monitoring can be beneficial
  and not part of any attack, e.g. network management functions monitor
  packets or flows and anti-spam mechanisms need to see mail message
  content.  Some monitoring can even be part of the mitigation for PM,
  for example Certificate Transparency [RFC6962] involves monitoring
  Public Key Infrastructure in ways that could detect some PM attack
  techniques.  There is though a clear potential for monitoring
  mechanisms to be abused for PM, so this tension needs careful
  consideration in protocol design.  Making networks unmanageable to
  mitigate PM is not an acceptable outcome, but ignoring PM would go
  against the consensus documented here.  An appropriate balance will
  emerge over time as real instances of this tension are considered.

The text above was carefully crafted and debated during the various reviews I believe that it is OK as it is, but the OPS community should debate whether work is necessary in the area (maybe in the OPSEC WG) in order to look at the following aspects:

-    Issue recommendations that could help protect the tools (applications, protocols, data repositories) used by operators for the day to day tasks or running and managing the networks from being used for pervasive monitoring (in the words of the document – how can we make sure in practical terms that useful monitoring mechanisms are not abused for PM?)

-    Review the existing protocols designed in the OPS area which have broad deployment and make sure that they have been designed in such a manner that the threat of a pervasive monitoring attack can be mitigated. If necessary (gaps were found out) issue recommendations for ‘ruggedizing’ these protocols against PM attacks

A few more observations:

-    In Section 2 the following sentence is IMO not clear enough: ‘It means that, if asked, there needs to be a good answer to the question "is pervasive monitoring relevant to this work and if so how has it been considered?"’ Who asks? Is this about the IESG reviews, or maybe about some kind of privacy assessment (done by whom?)

-    I found too little relation between this document and RFC6973. That Informational RFC provides actually a set of good recommendations on mitigation for privacy issues, many of them directly applicable against PM threats. It is also a very recent document, published only six months ago. It seems odd that the information[RFC6973] is mentioned only once and in an unclear way – the reference is just written in brackets between two sentences, not clear if it belongs to the sentence before or the sentence after.

[Ballot discuss]
This is an important document, and although it is short it
has the potential to have important and subtle implications.

I am concerned that it is premature to put this on a telechat
for approval given the extent of debate that continues.

Below are a number of points that I would like to discuss with
the authors and other members of the IESG. I accept that I
am likely to end up in a minority position and will need
to choose between no-objection, no-position or abstain with
the latter currently the most likely.

I am concerned that the text lacks balance. For example
it fundamentally assumes that there is no case for PM
and that it is fundamentally bad. On the other hand I can
see that it has the potential to be a useful servant of
a free society in post event forensics. Provided the
gathered information is secured and only analysed when
warranted (in both senses of the term) I can see its
use as a societal benefit.

I think that it is important that we provide an balanced
view between the human right to privacy and the human
right to safety as enabled by the actions of law enforcement.
Thus perfect security and inviolable privacy may not be
desirable goals.

I am concerned that the use of the work attack is unnecessarily
emotive.



                  Pervasive Monitoring is an Attack
                  draft-farrell-perpass-attack-05.txt

Abstract

  Pervasive monitoring is a technical attack that should be mitigated
  in the design of IETF protocols, where possible.


SB> I think that is one conclusion, and it is a judgement, but surely
SB> an abstract should tell you rather more about the contents of the
SB> text so at to determine whether or not you want to read the detail.
SB>
SB> How about something like this:
SB>
SB> Pervasive Monitoring is the large scale collection of Internet
SB> traffic and/or its associated metadata at many level of the
SB> Internet protocol stack. There is evidence that deployed PM systems
SB> end ran the assumed security models of the Internet, and in
SB> some cases subverted them. It is the conclusion of the IETF that
SB> IETF protocols should in future be designed to provide greater
SB> (maybe: ", but not necessarily perfect") privacy in the presence of PM.


1.  Pervasive Monitoring is a Widespread Attack on Privacy

SB> Yes and no. It is not clear whether the passive collection of the
SB> data is such an attack. For example if the collected data
SB> were held in some unreadable form (for example encrypted)
SB> would this be an attack? It surely becomes an invasion of
SB> privacy at the point where it is subjected to unwarranted
SB> (in both senses of the word) analysis of its content.
SB> The subversion of security with its wider implications for
SB> the introduction of exploits by others is in a different
SB> (worse) class than basic collection of bytes passing by.

  Pervasive Monitoring (PM) is widespread (and often covert)
  surveillance through intrusive gathering of protocol artefacts,
  including application content, or protocol meta-data such as headers.

SB> Some forms of PM are seemingly intrusive in that they actively
SB> damage the security model leaving it more vulnerable, others
SB> it seems are passive.

  Active or passive wiretaps and traffic analysis, (e.g., correlation,
  timing or measuring packet sizes), or subverting the cryptographic
  keys used to secure protocols can also be used as part of pervasive
  monitoring.

SB> You do not distinguish between these two classes of action
SB> but I think they are importantly different.

  The IETF community's technical assessment is that PM is an attack on
  the privacy of Internet users and organizations. 

SB> I am not sure you can say that without a lot more information on the
SB> technical details of what was done.

  PM is distinguished
  by being indiscriminate and very large-scale, rather than by
  introducing new types of technical compromise. 

SB> I think that this contradicts the earlier text and is technically
SB> incorrect. I think that there were some technical approaches used.

  The IETF community
  has expressed strong agreement that PM is an attack that needs to be
  mitigated where possible, via the design of protocols that make PM
  significantly more expensive or infeasible.  Pervasive Monitoring was
  discussed at the technical plenary of the November 2013 IETF meeting
  [IETF88Plenary] and then through extensive exchanges on IETF mailing
  lists.  This document records the IETF community's consensus and
  establishes the technical nature of PM.


SB> There were three hums were there not. Not all were fully endorsed
SB> as others. Surely to be a fair record we need to qualify the above.

    The term "attack" is used here in a technical sense that differs
  somewhat from common English usage.  In common English usage, an
  attack is an aggressive action perpetrated by an opponent, intended
  to enforce the opponent's will on the attacked party.  The term is
  used here to refer to behavior that subverts the intent of
  communicating parties without the agreement of those parties. 

SB> It seems to me that rather than take advantage of the emotivity
SB> of the technical word, we should use a more objective term and then
SB> qualify then note the equivalence for the security technical
SB> community.

  An
  attack may change the content of the communication, record the
  content or external characteristics of the communication, or through
  correlation with other communication events, reveal information the
  parties did not intend to be revealed.  It may also have other
  effects that similarly subvert the intent of a communicator.

SB> I think that you are taking advantage of the technical definition
SB> to introduce emotion rather than strict objectivity and impartiality.


  [RFC4949] contains a more complete definition for the term attack.
  We also use the term in the singular here, even though PM in reality
  may require a multi-faceted set of coordinated attacks.

  In particular, the term attack, used technically, implies nothing
  about the motivation of the actor mounting the attack.  The
  motivation for PM is not relevant for this document, but can range
  from non-targeted nation-state surveillance, to legal but privacy-
  unfriendly purposes by commercial enterprises, to illegal actions by
  criminals.  The same techniques can be used regardless of motivation.
  Thus we cannot defend against the most nefarious actors while
  allowing monitoring by other actors no matter how benevolent some
  might consider them to be, since the actions required are
  indistinguishable from other attacks.


SB> That is the crux of the dilemma and deserves to be more prominent.
SB> I think the text "no matter how benevolent some might consider them"
SB> is unnecessarily judgmental. We may all have different thresholds
SB> for warranted analysis, but there are cases where most ordinary
SB> people would consider the gathering of the information was
SB> morally justified.



2.  The IETF will work to Mitigate Pervasive Monitoring

  "Mitigation" is a technical term that does not imply an ability to
  completely prevent or thwart an attack.  Protocols that mitigate PM
  will not prevent the attack, but can significantly change the threat.
  (See the diagram on page 24 of RFC 4949 for how the terms attack and
  threat are related.)  This can significantly increase the cost of
  attacking, force what was covert to be overt, or make the attack more
  likely to be detected, possibly later.

SB> I am not sure forcing all monitoring to be overt is a good thing.
SB> Overt implies detectability from outside the monitoring system
SB> and its associated control environment. There are cases in law
SB> enforcement where few would consider the complete removal of
SB> undetectability desirable or morally defensible.

  IETF standards already provide mechanisms to protect Internet
  communications and there are guidelines [RFC3552] for applying these
  in protocol design.  But those generally do not consider PM, the
  confidentiality of protocol meta-data, countering traffic analysis
  nor data minimisation.  [RFC6973] In all cases, there will remain
  some privacy-relevant information that is inevitably disclosed by
  protocols.  As technology advances, techniques that were once only
  available to extremely well funded actors become more widely
  accessible.  Mitigating PM is therefore a protection against a wide
  range of similar attacks.

SB> Maybe it's later, but I thought that we agreed that there were
SB> operational reasons to gather some of the protocol artifacts.

  It is therefore timely to revisit the security and privacy properties
  of our standards.  The IETF will work to mitigate the technical
  aspects of PM, just as we do for protocol vulnerabilities in general.
  The ways in which IETF protocols mitigate PM will change over time as
  mitigation and attack techniques evolve and so are not described
  here.

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

  In particular, architectural decisions, including which existing
  technology is re-used, may significantly impact the vulnerability of
  a protocol to PM.  Those developing IETF specifications therefore
  need to consider mitigating PM when making these architectural
  decisions.  Getting adequate, early review of architectural decisions
  including whether appropriate mitigation of PM can be made is
  important.  Revisiting these architectural decisions late in the
  process is very costly.

SB> For balance the following needs to be earlier in the text.
SB> As it is here it is something of an afterthought which belittles
SB> its legitimacy and importance.

  While PM is an attack, other forms of monitoring can be beneficial
  and not part of any attack, e.g. network management functions monitor
  packets or flows and anti-spam mechanisms need to see mail message
  content.  Some monitoring can even be part of the mitigation for PM,
  for example Certificate Transparency [RFC6962] involves monitoring
  Public Key Infrastructure in ways that could detect some PM attack
  techniques.  There is though a clear potential for monitoring
  mechanisms to be abused for PM, so this tension needs careful
  consideration in protocol design.  Making networks unmanageable to
  mitigate PM is not an acceptable outcome, but ignoring PM would go
  against the consensus documented here.  An appropriate balance will
  emerge over time as real instances of this tension are considered.

  Finally, the IETF, as a standards development organisation, does not
  control the implementation or deployment of our specifications
  (though IETF participants do develop many implementations), nor does
  the IETF standardise all layers of the protocol stack.  Moreover, the
  non-technical (e.g. legal and political) aspects of mitigating
  pervasive monitoring are outside of the scope of the IETF.  The
  broader Internet community will need to step forward to tackle PM, if
  it is to be fully addressed.

  To summarise: current capabilities permit some actors to monitor
  content and meta-data across the Internet at a scale never before
  seen.  This pervasive monitoring is an attack on Internet privacy.
SB> Do you mean Internet privacy, or the privacy of Internet transactions?
SB> Other than to prevent attack, or compromise the commercial secrets
SB> of operators, I am not sure the Internet has any right to privacy.
SB> On the other hand internet users have the right to have their
SB> Internet transactions guarded to the degree agreed by their society.


  The IETF will strive to produce specifications that mitigate
  pervasive monitoring attacks.

SB> I think we mean appropriately mitigate, since the degree of
SB> acceptable mitigation is a societal matter.

3.  Process Note

  In the past, architectural statements of this sort, e.g., [RFC1984]
  and [RFC2804] have been published as joint products of the Internet
  Engineering Steering Group (IESG) and the Internet Architecture Board
  (IAB).  However, since those documents were published, the IETF and
  IAB have separated their publication "streams" as described in
  [RFC4844] and [RFC5741].  This document was initiated by both the
  IESG and IAB, but is published as an IETF-stream consensus document,
  in order to ensure that it properly reflects the consensus of the
  IETF community as a whole.

  [[Note (to be removed before publication): This draft is written as
  if IETF consensus has been established for the text.]]


4.  Security Considerations

  This document is entirely about privacy.  More information about the
  relationship between security and privacy threats can be found in
  [RFC6973].  Section 5.1.1 of [RFC6973] specifically addresses
  surveillance as a combined security-privacy threat.

SB> I think that the security considerations are surely more complex than
SB> this. Given that some degree of monitoring is inevitable should
SB> we not develop some security guidelines of the form "and if
SB> you really must do some form of information gathering, here is
SB> how you should secure it from illegitimate access".

From: http://www.ietf.org/iesg/template/individual-doc-writeup.txt

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

BCP; this is correct and is in the header

BCP vs Informational was the main unresolved LC discussion
topic. The text should be ok for either.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The IETF has consensus that pervasive monitoring is a technical
  attack that should be mitigated in the design of IETF protocols,
  where possible.

Working Group Summary

  This is not a workgroup document but was discussed in depth at
  the IETF 88 technical plenary, on the perpass@ietf.org and
  ietf@ietf.org lists, with more than 300 mails in the IETF LC
  discussion.

Document Quality

  This is a statement of principle BCP (or info doc) so there
  are no implementations.  It is a very short document that
  has been thoroughly wordsmithed.

Personnel

  The document shepherd is Sean Turner
  The AD is Jari Arkko

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The shepherd read it, likes it, and supports its publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No. There was extensive discussion about this draft during IETF LC on the ietf@ietf.org mailing list.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the interested community has
discussed those issues and has indicated that it still wishes to advance
the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any discussion and conclusion regarding the IPR
disclosures.

No.

(9) How solid is the consensus of the interested community behind this
document? Does it represent the strong concurrence of a few individuals,
with others being silent, or does the interested community as a whole
understand and agree with it?

The consensus at the IETF 88 technical plenary was overwhelming.
The consensus for the text on ietf@ietf.org seems clear.
The consensus for BCP vs informational is less clear.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

None. Well, there's no introduction section, but that's not a point worth halting publication over.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as
either normative or informative?

All are informative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the interested community considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

There are no IANA considerations.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A.

(19) Describe reviews and automated checks performed by to validate
sections of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, etc.

N/A.

[Ballot comment]
I'm mostly OK with the text in -05, but in section 2, I'm concerned that the draft is accurately reflecting conflicting goals:

- we need to mitigate PM
- we need to allow limited-scope monitoring
- we can't tell the difference in any technical way, so
- I'm not sure we can do both at the same time

Do we think we can figure that out?

Without resorting to http://www.nancyclaxton.net/uploads/3/4/6/9/3469502/525284.jpg, of course.

[Ballot comment]
I'd really like to take a YES on this document (on my principle that you say YES when you'd stand up and sponsor the document yourself if the sponsoring AD got run over by a bus), but I've got the outstanding concern about whether we have consensus, in particular for the status. Jari asked me to review the IETF list archive for the Last Call comments (almost 400 messages). My problem is that, except for Lloyd Wood, there are a bunch of previous opponents of publication as BCP have not said anything since the publication of -04/-05. I'm not a big believer in "silence as assent", especially when it comes to individual submissions. Some of the louder folks (Crocker, Lear, Kent) seem to be OK with BCP at this point, but if I were shepherding this document, I'd be poking some of the folks who were initially opposed to BCP and see how they feel about -05.

I'd *really* like to see this as a BCP. A consensus-Informational document is OK, but I don't think it's really where this document belongs. And I'm OK with the consensus being rough. (I think Lloyd's concerns have been sufficiently addressed to call him "in the rough"). But I'd like to get more (at least grudging) consent that the major worries were addressed before making the call.

[Ballot comment]
This is an important document, and although it is short it
has the potential to have important and subtle implications.

I have as yet not taken a position since I want to think further
about the issues that I share below.

I am concerned that the text lacks balance. For example
it fundamentally assumes that there is no case for PM
and that it is fundamentally bad. On the other hand I can
see that it has the potential to be a useful servant of
a free society in post event forensics. Provided the
gathered information is secured and only analysed when
warranted (in both senses of the term) I can see its
use as a societal benefit.

I think that it is important that we provide an balanced
view between the human right to privacy and the human
right to safety as enabled by the actions of law enforcement.
Thus perfect security and inviolable privacy may not be
desirable goals.

I am concerned that the use of the work attack is unnecessarily
emotive.



                  Pervasive Monitoring is an Attack
                  draft-farrell-perpass-attack-05.txt

Abstract

  Pervasive monitoring is a technical attack that should be mitigated
  in the design of IETF protocols, where possible.


SB> I think that is one conclusion, and it is a judgement, but surely
SB> an abstract should tell you rather more about the contents of the
SB> text so at to determine whether or not you want to read the detail.
SB>
SB> How about something like this:
SB>
SB> Pervasive Monitoring is the large scale collection of Internet
SB> traffic and/or its associated metadata at many level of the
SB> Internet protocol stack. There is evidence that deployed PM systems
SB> end ran the assumed security models of the Internet, and in
SB> some cases subverted them. It is the conclusion of the IETF that
SB> IETF protocols should in future be designed to provide greater
SB> (maybe: ", but not necessarily perfect") privacy in the presence of PM.


1.  Pervasive Monitoring is a Widespread Attack on Privacy

SB> Yes and no. It is not clear whether the passive collection of the
SB> data is such an attack. For example if the collected data
SB> were held in some unreadable form (for example encrypted)
SB> would this be an attack? It surely becomes an invasion of
SB> privacy at the point where it is subjected to unwarranted
SB> (in both senses of the word) analysis of its content.
SB> The subversion of security with its wider implications for
SB> the introduction of exploits by others is in a different
SB> (worse) class than basic collection of bytes passing by.

  Pervasive Monitoring (PM) is widespread (and often covert)
  surveillance through intrusive gathering of protocol artefacts,
  including application content, or protocol meta-data such as headers.

SB> Some forms of PM are seemingly intrusive in that they actively
SB> damage the security model leaving it more vulnerable, others
SB> it seems are passive.

  Active or passive wiretaps and traffic analysis, (e.g., correlation,
  timing or measuring packet sizes), or subverting the cryptographic
  keys used to secure protocols can also be used as part of pervasive
  monitoring.

SB> You do not distinguish between these two classes of action
SB> but I think they are importantly different.

  The IETF community's technical assessment is that PM is an attack on
  the privacy of Internet users and organizations. 

SB> I am not sure you can say that without a lot more information on the
SB> technical details of what was done.

  PM is distinguished
  by being indiscriminate and very large-scale, rather than by
  introducing new types of technical compromise. 

SB> I think that this contradicts the earlier text and is technically
SB> incorrect. I think that there were some technical approaches used.

  The IETF community
  has expressed strong agreement that PM is an attack that needs to be
  mitigated where possible, via the design of protocols that make PM
  significantly more expensive or infeasible.  Pervasive Monitoring was
  discussed at the technical plenary of the November 2013 IETF meeting
  [IETF88Plenary] and then through extensive exchanges on IETF mailing
  lists.  This document records the IETF community's consensus and
  establishes the technical nature of PM.


SB> There were three hums were there not. Not all were fully endorsed
SB> as others. Surely to be a fair record we need to qualify the above.

    The term "attack" is used here in a technical sense that differs
  somewhat from common English usage.  In common English usage, an
  attack is an aggressive action perpetrated by an opponent, intended
  to enforce the opponent's will on the attacked party.  The term is
  used here to refer to behavior that subverts the intent of
  communicating parties without the agreement of those parties. 

SB> It seems to me that rather than take advantage of the emotivity
SB> of the technical word, we should use a more objective term and then
SB> qualify then note the equivalence for the security technical
SB> community.

  An
  attack may change the content of the communication, record the
  content or external characteristics of the communication, or through
  correlation with other communication events, reveal information the
  parties did not intend to be revealed.  It may also have other
  effects that similarly subvert the intent of a communicator.

SB> I think that you are taking advantage of the technical definition
SB> to introduce emotion rather than strict objectivity and impartiality.


  [RFC4949] contains a more complete definition for the term attack.
  We also use the term in the singular here, even though PM in reality
  may require a multi-faceted set of coordinated attacks.

  In particular, the term attack, used technically, implies nothing
  about the motivation of the actor mounting the attack.  The
  motivation for PM is not relevant for this document, but can range
  from non-targeted nation-state surveillance, to legal but privacy-
  unfriendly purposes by commercial enterprises, to illegal actions by
  criminals.  The same techniques can be used regardless of motivation.
  Thus we cannot defend against the most nefarious actors while
  allowing monitoring by other actors no matter how benevolent some
  might consider them to be, since the actions required are
  indistinguishable from other attacks.


SB> That is the crux of the dilemma and deserves to be more prominent.
SB> I think the text "no matter how benevolent some might consider them"
SB> is unnecessarily judgmental. We may all have different thresholds
SB> for warranted analysis, but there are cases where most ordinary
SB> people would consider the gathering of the information was
SB> morally justified.



2.  The IETF will work to Mitigate Pervasive Monitoring

  "Mitigation" is a technical term that does not imply an ability to
  completely prevent or thwart an attack.  Protocols that mitigate PM
  will not prevent the attack, but can significantly change the threat.
  (See the diagram on page 24 of RFC 4949 for how the terms attack and
  threat are related.)  This can significantly increase the cost of
  attacking, force what was covert to be overt, or make the attack more
  likely to be detected, possibly later.

SB> I am not sure forcing all monitoring to be overt is a good thing.
SB> Overt implies detectability from outside the monitoring system
SB> and its associated control environment. There are cases in law
SB> enforcement where few would consider the complete removal of
SB> undetectability desirable or morally defensible.

  IETF standards already provide mechanisms to protect Internet
  communications and there are guidelines [RFC3552] for applying these
  in protocol design.  But those generally do not consider PM, the
  confidentiality of protocol meta-data, countering traffic analysis
  nor data minimisation.  [RFC6973] In all cases, there will remain
  some privacy-relevant information that is inevitably disclosed by
  protocols.  As technology advances, techniques that were once only
  available to extremely well funded actors become more widely
  accessible.  Mitigating PM is therefore a protection against a wide
  range of similar attacks.

SB> Maybe it's later, but I thought that we agreed that there were
SB> operational reasons to gather some of the protocol artifacts.

  It is therefore timely to revisit the security and privacy properties
  of our standards.  The IETF will work to mitigate the technical
  aspects of PM, just as we do for protocol vulnerabilities in general.
  The ways in which IETF protocols mitigate PM will change over time as
  mitigation and attack techniques evolve and so are not described
  here.

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

  In particular, architectural decisions, including which existing
  technology is re-used, may significantly impact the vulnerability of
  a protocol to PM.  Those developing IETF specifications therefore
  need to consider mitigating PM when making these architectural
  decisions.  Getting adequate, early review of architectural decisions
  including whether appropriate mitigation of PM can be made is
  important.  Revisiting these architectural decisions late in the
  process is very costly.

SB> For balance the following needs to be earlier in the text.
SB> As it is here it is something of an afterthought which belittles
SB> its legitimacy and importance.

  While PM is an attack, other forms of monitoring can be beneficial
  and not part of any attack, e.g. network management functions monitor
  packets or flows and anti-spam mechanisms need to see mail message
  content.  Some monitoring can even be part of the mitigation for PM,
  for example Certificate Transparency [RFC6962] involves monitoring
  Public Key Infrastructure in ways that could detect some PM attack
  techniques.  There is though a clear potential for monitoring
  mechanisms to be abused for PM, so this tension needs careful
  consideration in protocol design.  Making networks unmanageable to
  mitigate PM is not an acceptable outcome, but ignoring PM would go
  against the consensus documented here.  An appropriate balance will
  emerge over time as real instances of this tension are considered.

  Finally, the IETF, as a standards development organisation, does not
  control the implementation or deployment of our specifications
  (though IETF participants do develop many implementations), nor does
  the IETF standardise all layers of the protocol stack.  Moreover, the
  non-technical (e.g. legal and political) aspects of mitigating
  pervasive monitoring are outside of the scope of the IETF.  The
  broader Internet community will need to step forward to tackle PM, if
  it is to be fully addressed.

  To summarise: current capabilities permit some actors to monitor
  content and meta-data across the Internet at a scale never before
  seen.  This pervasive monitoring is an attack on Internet privacy.
SB> Do you mean Internet privacy, or the privacy of Internet transactions?
SB> Other than to prevent attack, or compromise the commercial secrets
SB> of operators, I am not sure the Internet has any right to privacy.
SB> On the other hand internet users have the right to have their
SB> Internet transactions guarded to the degree agreed by their society.


  The IETF will strive to produce specifications that mitigate
  pervasive monitoring attacks.

SB> I think we mean appropriately mitigate, since the degree of
SB> acceptable mitigation is a societal matter.

3.  Process Note

  In the past, architectural statements of this sort, e.g., [RFC1984]
  and [RFC2804] have been published as joint products of the Internet
  Engineering Steering Group (IESG) and the Internet Architecture Board
  (IAB).  However, since those documents were published, the IETF and
  IAB have separated their publication "streams" as described in
  [RFC4844] and [RFC5741].  This document was initiated by both the
  IESG and IAB, but is published as an IETF-stream consensus document,
  in order to ensure that it properly reflects the consensus of the
  IETF community as a whole.

  [[Note (to be removed before publication): This draft is written as
  if IETF consensus has been established for the text.]]


4.  Security Considerations

  This document is entirely about privacy.  More information about the
  relationship between security and privacy threats can be found in
  [RFC6973].  Section 5.1.1 of [RFC6973] specifically addresses
  surveillance as a combined security-privacy threat.

[Ballot discuss]
This DISCUSS is a placeholder until we can determine the right status (BCP or Informational) for this document.  No action is needed as the IESG will resolve this on the telechat.

[Ballot comment]
Recognising that we could quibble about wording until the document is entirely overtaken by events (such as the death of the known universe), I'll throw in a couple of comments, which you're free to opt out of with no reply needed.

  The term "attack" is used here in a technical sense that differs
  somewhat from common English usage.  In common English usage,

I would strike the second sentence ("In common English usage...") entirely, as it only serves to bring the inapplicable sense to the reader's attention.  Just go straight from the first sentence right into, "The term is used here...."

  We also use the term in the singular here, even though PM in reality
  may require a multi-faceted set of coordinated attacks.

I'd say "consist of", rather than "require".

  Thus we cannot defend against the most nefarious actors while
  allowing monitoring by other actors no matter how benevolent some
  might consider them to be, since the actions required are
  indistinguishable from other attacks.

"the actions required" seems odd here.  I think it refers to the actions required for defense, but then it says they're indistinguishable from attacks.  I think the best fix is something like this:

NEW
  Thus we cannot defend against the most nefarious actors while
  allowing monitoring by other actors no matter how benevolent some
  might consider them to be, since the various actors are
  indistinguishable from each other in this regard.
END

  This can significantly increase the cost of
  attacking, force what was covert to be overt, or make the attack more
  likely to be detected, possibly later.

Isn't making what was covert overt also making in detectable?  This seems repetitious.

IESG/Authors/WG Chairs:

IANA has reviewed draft-farrell-perpass-attack-02, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion. IANA requests that the IANA Considerations section of the document remain in place upon publication.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Pervasive Monitoring is an Attack) to Best Current Practice


The IESG has received a request from an individual submitter to consider
the following document:
- 'Pervasive Monitoring is an Attack'
  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
ietf@ietf.org mailing lists by 2013-12-31. Exceptionally, comments may be
sent to iesg@ietf.org 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.

AD review comments:

I'm happy with -01 and can push the last call button. Sean, do you have comments?

A couple of minor nits

Section 2 title could probably capitalise "work" and I'd probably also write "We Will Work" instead of "We'll work".

Also, because we can't mandate other people to do stuff: "Others will be required to step forward" => "Others need to step forward"

Jari