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.