Skip to main content

Pervasive Monitoring Is an Attack
RFC 7258


(Jari Arkko)
(Martin Stiemerling)
(Richard Barnes)
(Sean Turner)
(Ted Lemon)

No Objection

(Gonzalo Camarillo)



(Stephen Farrell)

Note: This ballot was opened for revision 04 and is now closed.

Jari Arkko Former IESG member
Yes (for -04) Unknown

Martin Stiemerling Former IESG member
Yes (for -05) Unknown

Pete Resnick Former IESG member
(was No Objection) Yes
Yes (2014-02-06 for -05) Unknown
Jari has made a good case that there is rough consensus for BCP.
Richard Barnes Former IESG member
Yes (for -05) Unknown

Sean Turner Former IESG member
(was Recuse) Yes
Yes (for -05) Unknown

Ted Lemon Former IESG member
Yes (for -05) Unknown

Adrian Farrel Former IESG member
No Objection
No Objection (2014-02-01 for -05) Unknown
I would really, really, really, prefer this document to go as 

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


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

   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

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

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



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
Barry Leiba Former IESG member
No Objection
No Objection (2014-01-21 for -05) Unknown
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:

   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.

   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.
Benoît Claise Former IESG member
(was Discuss) No Objection
No Objection (2014-02-11) Unknown
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."
Brian Haberman Former IESG member
(was Discuss) No Objection
No Objection (2014-02-06 for -05) Unknown
Thanks for an *interesting* DISCUSSion.
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -05) Unknown

Joel Jaeggli Former IESG member
No Objection
No Objection (2014-01-23 for -05) Unknown
   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.
Spencer Dawkins Former IESG member
No Objection
No Objection (2014-02-06 for -05) Unknown
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, of course.


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.
Stewart Bryant Former IESG member
(was Discuss) Abstain
Abstain (2014-02-05 for -05) Unknown
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

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

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.
Stephen Farrell Former IESG member
Recuse (for -04) Unknown