ietf
[Top] [All Lists]

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

2013-12-09 06:45:48

Hi Bjoern,

Thanks for the thoughtful comments. I've added this to my
list of threads to revisit [1] so it won't get forgotten
later.

  [1] http://down.dsg.cs.tcd.ie/misc/ppbcp-text-suggestions.txt

Mostly, I think the current draft is ok as-is, but would
be happy to see alternative wording suggestions if you
or anyone else has them.

At the same time I hope we all recognise the danger of
wordsmithing/bikeshedding on a list this big, so maybe if
folks have purely wordsmithing changes to suggest just
send those to Hannes and me off list?

Anything substantive should of course go to the list.

On 12/07/2013 02:45 AM, Bjoern Hoehrmann wrote:
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. 

Well, a "work of art" is quite a target, but yes, we should try
make this short document as good as we can. However, short and
accurate still outweighs artistic merit I think.

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.

I'd be uneasy with "substitute for debate" but if what you mean
is that this be usable in the same way that 1984 and 2804 are
then I'd agree. People still can and will debate how those and
this apply to e.g. what their WG is doing and that's the right
thing to happen. What this BCP and those RFCs can do though
is avoid having to continually debate the same background or
more fundamental points in each WG.

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.

Having read your mail, I'm not getting why but let's see...

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.

While I think you're correct that they aren't logically needed,
the last two words are nonetheless still useful I think. If
someone only read the abstract I think they'd get a more correct
picture as-is compared to the abstract without those two words.

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.

Maybe we could always say "technical attack" but the intent in the
abstract is to hint that the term is being used in a way that's not
common English usage. Thinking about it though, I do think its ok
to mix the terms "technical attack" and "attack" since we explain
the term.

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.

No. Your #1 isn't there. There is an implicit "Some people claim
this is not an attack, but it is" that I'd prefer we keep
implicit and not make explicit. If we made it explicit that'd
beg the question "Who thinks that?" and I don't think we want
to or need to answer that for this BCP to be correct and have
the effect we want.

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. 

That is important. Since the actions required are indistinguishable
from what even defenders of pervasive monitoring would agree is an
attack, those defenders are placed in the awkward position of having
to agree that yes, pervasive monitoring should be treated as an
attack in the design of IETF protocols.

Again though, I'd suggest that we don't include that logic in
the draft, since it'd just provide text that'd be fodder for more
argument later on. If that argument needs to be thrashed out,
then we should do it now and anyone interested can find it in
the archives.

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

Again, I think its ok to use attack rather than technical attack
when/if that reads better, since we define what we mean.

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.

Does the above help? (Or make it worse;-)

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

Fair point. That was deliberate though but could maybe be
improved.

I think the term pervasive monitoring is generally better since
its less emotive and surveillance (for me, YMMV) has an implication
of being more targeted. So I wanted to define pervasive monitoring,
at least well enough to be usable for this document, i.e. I don't
think we need to be exhaustive or give loads of examples here to
get done what we want to get done here.  But I also wanted to
sort-of equate that with surveillance in case some readers
understand the latter word but might otherwise be confused by
as to what "pervasive monitoring" meant.

I think using them as synonyms once does the above well enough.
(It might be better to change the last para of section 2 though
to say monitoring.)

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.

2804 is a fine document but I don't think we need to follow its
layout.

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.

Better wording welcome, but the intent of this is to validate the
consensus that was overwhelming in the room via an IETF LC'd
draft, which is the "right thing" given our processes. So saying
exactly that seems entirely appropriate.

Presenting it as if the meeting was ancillary to forming the
consensus wouldn't be accurate.

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 (carefully:-) don't care about that to be honest. I can say
it wasn't written in haste.

I think "Best Current Practice" is a qualifier that cannot stand on its
own (something like "document" should follow), 

I think that's fine as-is in terms of English usage.

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

wrt acronyms & abbrevs... sure, will-fix:-)

I do think calling out the BCPness of this BCP is worthwhile since
I expect it will have readers who'll not get meaning of the RFC
meta-data at the top of the front page.

We could add a reference to 2026 section 5 though maybe. That
might be a good addition.

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

We added that as a result of comments on the perpass list. I'll look
at it again and wordsmith when/if Jari tells me to shoot out a new
rev. Having said that I think its ok good enough as-is, but not a work
of art.

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.

Maybe. In this case, the point was made that "attack" might be
misconstrued so as to mean that we are discussing the motivations
of e.g. NSA. We are not discussing those motivations and we need
to be clear that we are not if this BCP is to have its proper
effect. But see below...

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.

This bit does need to be clear and if its not we should fix.
I've not heard from others that its unclear though.

The point is not that the attacker has no motivation, but that the
IETF don't need to think about their motivations, since the actions
are indistinguishable from other (technical) attacks.

What we're saying is just that.

And its important that we say it, since the current attacker's
stated/claimed motivations include things  (e.g. "apprehend
terrorist") on which the IETF is not in a position to comment.

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.

See above. Lumped-together is going to happen though if we want
to keep this short and sweet, and I think we do.

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.

Yep, that could be better. Suggestions welcome, but I'll think
about it. (In fact, one of the non-native English speaking folks
who commented earlier suggested this, but based on my initial
equally bad section heading;-)

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

Heh. A good target though.

In the hope this helps,

It does. Still not promising a work of art though:-)

Thanks,
S.