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. 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. I¹m personally convinced that, on balance, the world would be a much worse place without ³attacks² than with. 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), 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. 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. 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. 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. 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. 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 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. 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. 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. 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 >