Hi Stephan, Some non-trivial points below, but actually I think your posting is a great example of why the IETF needs this draft published. If we do not get that done, then anyone proposing to consider or mitigate pervasive monitoring is liable to have to re-litigate this entire debate in whatever WG is involved, because absent an IETF consensus position on this, you and those who agree with you will, holding the position you do, feel bound to question such work, which could be quite disruptive overall. (I'm not saying you'd be disruptive btw, the ultimate fault if any lies with the signals intelligence agencies IMO.) On 01/07/2014 03:41 AM, Stephan Wenger wrote: > Hi all, > As the time window for the last call comes to a close shortly, I want to > chime in. This is going to be my first and last message on this > subject--I will not have time to argue my viewpoints due to other, for me > more important, commitments. > > I¹m against publishing this draft in any form. I¹m convinced, based on > the mailing list discussion up to now, and on my own reading, that > publishing this draft has more risks than benefits for myself and for the > IETF. Here are a few condensed points. > > 1. My personal risk/benefit equation: > The main disconnect I see in the draft is its implicit assumption that an > ³attack² is a Bad Thing. Actually no that terminology (more fully explained in RFC 4949) is standard in computer security/risk analysis in general and has been since before my time, so for 40 years or more. While you may not be a "security guy" that terminology is sufficiently widespread that I'm very surprised that you don't already know its meaning. What you're asking would be similar to asking to re-interpret the term octet and should be similarly regarded IMO. > It¹s an implicit assumption, because after the > very clear definition for ³attack² provided in section 1, the draft > immediately jumps to the subject of the need for the IETF to work towards > mitigation, which implies that there is something (namely the ³attack") > that needs to be mitigated. That is an immensely political statement that > has not been addressed in the draft. There are countless examples where > ³attacks² (as defined in the draft) have saved lives and generally have > done good to the world. There are countless examples of when falling over saved lives too. That doesn't mean falling over is a good plan. > I¹m personally convinced that, on balance, the > world would be a much worse place without ³attacks² than with. I see. So you're all for hacking into Belagcom then? I'm sure they'll be a little sad to hear that. Esp. if the next attacker is not a government agency. > Without > ³attacks², we would probably not have safe mass transportation, terrorist > of different colour would run wild, organized crime would be widespread, > and so on. I DO WANT my communication to be ³attackable² (albeit not > necessarily easily attackable), So you would like security mechanisms with government-backdoors but that are hard for anyone else? I want a pony:-) But seriously, we don't know of a way to do that. Please see RFCs 1984 and 2804 for some IETF history on that. > based on the assumption that, generally > speaking, me, being a moderately good guy myself, will probably not be > subject to too many attacks by the good guys because my views are > generally better aligned with the good guys than with the bad guys. Even > if the good guys were spying on me, they could hardly use that information > in a way that would hurt me. That's optimistic. > OTOH, I want that the communication of the > bad guys, be they terrorists, organized crime or whatever, to be broken > into, and their schemes to be disrupted by law enforcement, before they > have a chance to attack (without quotes) me in the very real sense of > flying bullets and blown up planes. For that, I¹m willing to accept that > the bad guys can break my communication as well. This logic obviously > works best, today, when living in a western democracy (like I do), > generally trusting the government (as I do), and having the resources and > the will to fight (like I think I have) if I am ³attacked² by the > government or anyone else for illegitimate reasons (Note that I didn¹t > write ³illegal²). > > Note that I have labeled this section ³My personal risk/benefit equation². > I can fully understand if others set other priorities. However, I > participate in the IETF as well, and my viewpoint should (and. I¹m quite > confident, will) be taken into account as those of others, despite it > being perhaps somewhat politically incorrect in the current climate. That's fair. I'd guess you're fairly clearly in the rough in that respect. But, taking contrarian views into account here (as should be done) does not mean making contrarians happy. In this case, as soon as there are a significant number of people who do not share your views (and there are) and who would like not to be so vulnerable to pervasive monitoring, then I think that viewpoint wins, in terms of what the IETF should be considering and the technical proposals that we develop since only then is it possible to satisfy both sets of opinions on this topic. (Folks such as yourself can turn things off, but the other set can only turn things on after they've been defined and implemented.) And in labelling your own view as currently "politically incorrect" you are accepting that most participants do not share your view, which implicitly therefore also accepts that the IETF should be working to develop mitigations to pervasive monitoring as explained above. The logical position for a self-recognised contrarian such as yourself is therefore in fact to support the draft! > > 2. IETF¹s risk/benefit equation > 2.a declaring consensus on something like this. The assertion in the > document that it represents IETF consensus (based on the plenary) has > already been competently challenged. No need to repeat. I'm sorry but that's wrong. First, nobody asserted that the plenary in Vancouver means that this draft already has consensus. Second, the plenary in Vancouver did happen, so claiming that it can be ignored is not credible. >From my POV, I consider the Vancouver plenary in the same way as I'd consider a huge set (hundreds) of +1 mail messages - there's no thoughtful statement that the draft captures the hums correctly, but the draft IMO fairly obviously does that at least imperfectly, so those hums can be considered to be +1 messages. And in saying that I do consider a +1 mail as only being a very weak contribution to establishing rough consensus. I'm not sure how or if Jari will factor the hums in Vancouver into his evaluation of this LC, but pretending they never happened would be very wrong. > But let me add > that in this case we have an even stronger problem with the ³silent > majority² than usual. I could imagine that a large percentage of the IETF > participants, especially those living in areas less fortunate than the > western democracies, cannot voice their opinion safely and freely, even if > they wished. I've no idea what you mean. If you're saying that people in "less fortunate" areas are less likely to oppose this draft then I think that's silly. > As stated above, I believe this is an immensely political > draft (for the reason that it makes implicit assumptions), and some folks > have to be more careful than others commenting. I carefully tried to stay > away speculating what their view may be, and I invite others to do the > same--this is not only a political but also a cultural question. In fact, you are speculating above. > 2.b there is the further risk that even more of our standards get silently > disregarded in large parts of the world, potentially leading to less > interoperability and an even more pronounced split between a ³western > democracy Internet² and ³rest of the world Internet". Already, there are > countries where any form of encryption of media data and emails is > forbidden, and one goes to jail (or worse) if one does. I hear that from time to time. Never accompanied with references though. And RFC 1984 is our position on that, this draft is not needed. > I don¹t say that > this is a good thing, but fighting the situation is once more an immensely > political process, and I don¹t think the IETF is particularly good at > that, nor does it need to be. > 2.c for my own work in the IETF, I do not want to see yet another opening > that potentially allows the security lobby to require me to load up my own > drafts, which have nothing to do with security, with additional security > oriented language. I¹m not a security guy. I don¹t care about pervasive > monitoring; I view it generally as beneficial (see above). Why should I > have answers ready when competent others ask me questions about it? Why > should I see my documents delayed for this stuff? They may well be very > good documents in what they are describing. We have enough boilerplate > and process already, thank you. The draft does not require any new boilerplate or process. 2c seems to be back to you personal view. > 2.d risk of misrepresentation by the media. The language of the draft is > flashy enough to invite misrepresentation by the media. It cannot be in > the interest of the IETF to see one of its future core docs (process BCPs > are just that, right?) be misinterpreted by journalists, many of which > probably having spent even less time with this doc than myself. I just disagree about flashy. Its fairly boring now:-) Readers of RFCs can always mis-represent them. Your claim amounts to a claim that we should never say anything I think. And you don't even quote a single sentence that you say could be misrepresented or that is "flashy." That's not really credible as a criticism. > 2.e as for the benefits, where are they? The IETF would be viewed in > certain progressive circles in the western democracies as sensitive > people, especially in year 1 past Snowden. (I¹m not so sure how we would > look in year 1 after the next large scale terrorist attack.) The security > guys would have more work. Nothing against good biz-dev, but does it > really have to be an IETF BCP? :-) What else? Nothing comes to my mind. See the top-post for one benefit. Those who do think that attacks are bad things will see benefits in terms of being less vulnerable. S. > > Thanks for reading. > > Best regards, > Stephan > > > On 12/3/13, 20:45, "Jari Arkko" <jari.arkko@xxxxxxxxx> wrote: > >> I wanted to draw your attention on this last call: >> >>> The IESG has received a request from an individual submitter to consider >>> the following document: >>> - 'Pervasive Monitoring is an Attack' >>> <draft-farrell-perpass-attack-02.txt> as Best Current Practice >>> >>> http://datatracker.ietf.org/doc/draft-farrell-perpass-attack/ >> >> >> It is a short read and important, so please comment. The last call ends >> in four weeks and covers holiday time, but we'll deal with this document >> on the January 9th telechat in the IESG, so in practice there should be >> enough time to comment. >> >> I would like to see this document as a high-level policy we have on >> dealing with this particular type of vulnerabilities in the Internet. A >> little bit like RFC 3365 "Danvers Doctrine" was on weak vs. strong >> security. Please remember that the details and tradeoffs for specific >> solutions are for our WGs to consider and not spelled out here. The draft >> does say "where possible" - I do not want to give the impression that our >> technology can either fully prevent all vulnerabilities or do it in all >> situations. There are obviously aspects that do not relate to >> communications security (like access to content by your peer) and there >> are many practical considerations that may not make it possible to >> provide additional privacy protection even when we are talking about the >> communications part. But I do believe we need to consider these >> vulnerabilities and do our best. >> >> Jari >> > > >