Tom, The IAB has seen the document and discussed it before we posted it for public review. And had some comments, and some members still do :-) My plan has been to find IETF consensus on this matter, but also have the IAB support the document (in its final form - I'm sure there will be changes). But we are not there yet - lets determine first what the IETF thinks. As for who is making what kinds of statements - I think the most fundamental difference is between IETF consensus and IAB opinion. The former is obviously a stronger statement. With regards to the workshop that the IAB is organising, it is an important event, but still one among many. My crystal ball says that we will be discussing impacts and defences related to pervasive monitoring for many years to come. Stephen's document states something which I believe we can and should state today - that pervasive monitoring should be and defences for it should seriously considered when we at the IETF do protocol work. In the coming months and years we'll do a lot of work in parallel in continuing IETF's work to secure various applications and protocols in individual working groups. And we'll for sure learn many things along the way about more general aspects of this problem. For instance, I'm hoping that we'll understand better what opportunistic encryption can and can not do for us. I'm sure the IAB workshop will provide some of those learnings, but at the same time we'll for sure learn yet more in IETF-89 and many other events as well. So the discussion is definitely not over now, not when this document is an RFC, not when the workshop is held, and it may not be ever over. We keep inventing new protocols and applications, for instance. Jari On Dec 12, 2013, at 12:23 PM, t.p. <daedulus@xxxxxxxxxxxxx> wrote: > Jari > > I am wondering what the role of the IAB is in this. Statements of > policy such as this I have seen previously from the IAB, as in the > RFC2804 that has just been referenced. Whereas the IETF produces the > engineering, such as TLS or IPsec, which is rather different in nature. > Does the IAB approve or disapprove of this? Why isn't it involved? > > And when I look at the IAB website, I am bemused. The IAB is calling > for papers for a conference on this precise topic, to be held in three > months, by which time you want this I-D to be signed, sealed and > delivered. So that the IAB can wave it at all participants and say > 'Discussion over'? Or what? > > It seems to me that this I-D is an ideal candidate to be presented and > discussed at the conference after which, the IAB can produced a > carefully considered document. > > Tom Petch > > ----- Original Message ----- > From: "Jari Arkko" <jari.arkko@xxxxxxxxx> > To: <ietf@xxxxxxxx> > Sent: Wednesday, December 04, 2013 4:45 AM > > > 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 > > > >