Editorial thoughts on draft-farrell-perpass-attack-02

Greetings.

  Regarding http://tools.ietf.org/html/draft-farrell-perpass-attack-02 I
think a document like this needs prose that is clear, straight to the
point, easy to follow, persuasive, confident, convincing, inspiring. It
should be, at least more than your ordinary RFC, a work of art, and in
art it is often necessary to start over from scratch than making a few
tweaks here and there. An important reason is that, as I understand it,
some would like to use the document as substitute for debate. It is not
good enough for that.

If an IETF Working Group participants wants the group to consider wire-
tapping requirements, and a pointer to RFC 2804 puts an end to that, I
think that's fair. If I saw draft-farrell-perpass-attack-02 used this
way or otherwise having such an effect, I think that would not be fair.
This is my intuitive reaction from reading through the document a few
times; I suspect there are material reasons, but some editorial issues
are easy to identify. I think it may be useful to point some of them out
while I continue to review the document. (This is a mind-dump provided
as-is from first impressions, not something I intend to argue over).

The Abstract is this:

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

The last two words do not belong here. If they mattered they should not
be left as a hanging appendage to the sentence but appear prominently,
but they do not even matter, the Abstract does not need to highlight
that the IETF does not have consensus on something impossible.

The qualifier "technical" makes the document appear deceptive. I do not
understand what it means, why it is there. I will have to keep this in
mind throughout the rest of the document, but human brains have a rather
limited set of registers, odds are I will forget about the four touch-
downs in a single game. I think the document does not actually explain
why this qualifier is in the Abstract. My impression is that it is not
needed there.

The document continues:

   1. It's an Attack

   The technical plenary of IETF 88 [IETF88Plenary] discussed pervasive
   monitoring.  Such pervasive surveillance requires the monitoring
   party to take actions that are indistinguishable from an attack on
   Internet communications.  Participants at that meeting therefore
   expressed strong agreement 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.

There are many problems here. The biggest is probably that I get the
impression that this is twisted on a technicality. The logic is thus:

  1. X is not an attack.
  2. X is indistinguishable from an attack.
  3. X is therefore an attack.

If X was an attack then "indistinguishable from an attack" would be un-
necessary, so I get the impression that I am missing some important
detail here. Also note that this appears to be the central argument of
the document, but unlike the Abstract, it's just "attack", not "techni-
cal attack". The first time I looked at the document this was the point
where I stopped reading and instead scroll through the document to see
what else is there, and then put it aside for later when I can concen-
trate better.

Another problem is that the second sentence equates "pervasive moni-
toring" with "pervasive surveillance". That makes me wonder whether the
two are actually precisely the same thing, and I note that the document
does not actually introduce or define either of them before this point
and never defines "pervasive surveillance".

We are thrown right into "It's an Attack". Contrast this with RFC 2804
which takes care to start with a "Summary position" section, later
discusses "The Raven process", and then provides "A definition of
wiretapping". That is a clear separation of concerns, this draft throws
it all together.

The document continues

   This Best Current Practice (BCP) formally documents that consensus,
   having been through an IETF last call.

Before the document talked about meeting participants expressing strong
agreement. "That" is not consensus, some people in Vancouver expressing
something is not a method of finding IETF consensus. The "oh yeah, there
was also a last call" appendage does not help here. It seems to me that
this should be the other way around, IETF Consensus, oh yeah, and there
was a meeting in Vancouver, by the way.

I am sorry if this seems petty, but the dominant capitalisation is "Last
Call"; "last call" gives an impression of carelessness and haste, not an
impression of careful attention to detail.

I think "Best Current Practice" is a qualifier that cannot stand on its
own (something like "document" should follow), and it is probably not a
good idea to emphasise the formal document status in the document, it
gives too much of a sense of "look at me! I'm important! And I need to
point this out! Because, actually I am not that important after all". I
also think this document is probably intended for a wide audience, so it
should avoid abbreviations as much as possible. (To stick with the re-
ference, RFC 2804 only abbreviates and explains the abbreviation for
"IESG" and "IAB" and uses them only in immaterial sections).

Later in the document

   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.  In the
   Internet, the term is used to refer to a behavior that subverts the
   intent of a communicator without the agreement of the parties to the
   communication.

I speak English only as a third language, but my impression is "intended
to enforce the opponent's will on the attacked party" is not in fact
part of how the word is usually or even commonly understood.

I think "In the Internet, the term is used" is not suitable prose for a
general audience. This is more something like "when the Security Con-
siderations sections of IETF specifications refer to an 'attack', then".

I suspect the document probably should not give the impression to IETF
outsiders that "we" speak in some sort of "code" where words do not mean
what they ordinarily mean. It might be an option to simply say what the
memo means by the word "attack" without reference to other definitions.

Later on

   In particular, the term "attack", when used technically, implies
   nothing about the motivation of the actor mounting the attack.

My initial impression was that this contradicts the earlier definition,
for instance, it seems to me that the "motivation" is to subvert "the
intent of a communicator without the agreement of the parties". I do not
see how "monitoring" and "surveillance" are free of "motiviation", so I
am not sure if this is trying to explain "attack" independently of the
main points of the document, or what else might be the point.

Later in the same paragraph

   ... The same techniques can be used regardless of motivation and
   we cannot defend against the most nefarious actors while allowing
   monitoring by other actors no matter how benevolent some might
   consider them to be. ...

This probably is a Central point of the document but it is lumped to-
gether with other things in a single paragraph.

The "other" section of the document carries this headline

  2. And We Will Continue to Mitigate the Attack

This is like saying that we will "further perfect the optimisations". To
me this mainly conveys insecurity, don't want anyone to think "we"'ve
not done this before now. Right, it's like calling something "Network
News Transfer Protocol Great International Consensus Standard" instead
of just "NNTP". It's desperate and probably means the opposite. And
clearly, starting a sentence with a conjunction is very transparent.

As Bender learned, "When you do things right, people won't be sure
you've done anything at all."

In the hope this helps,
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · 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/

Received on Saturday, 7 December 2013 02:45:44 UTC