datatracker.ietf.org
Sign in
Version 5.13.0, 2015-03-25
Report a bug

Pervasive Monitoring Is an Attack
draft-farrell-perpass-attack-06

Yes
(was No Objection)
[spt]
(was Recuse)
No Objection
(was Discuss)
(was Discuss)
Abstain
(was Discuss)

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

Summary: Needs 3 more YES or NO OBJECTION positions to pass.

Barry Leiba

Comment (2014-01-21 for -05)

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.

Benoit Claise

Comment (2014-02-11 for -06)

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

Comment (2014-02-06 for -05)

Thanks for an *interesting* DISCUSSion.

Joel Jaeggli

Comment (2014-01-23 for -05)

   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

Comment (2014-02-06 for -05)

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.

[Adrian Farrel]

Comment (2014-02-01 for -05)

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

====

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?

[Pete Resnick]

Comment (2014-02-06 for -05)

Jari has made a good case that there is rough consensus for BCP.

[Stewart Bryant]

Comment (2014-02-05 for -05)

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.