ietf
[Top] [All Lists]

Re: conclusion on draft-farrell-perpass

2014-02-27 07:50:49
Well done.
On Feb 27, 2014 12:52 PM, "IETF Chair" <chair(_at_)ietf(_dot_)org> wrote:

The IESG has made a conclusion on draft-farrell-perpass [1]. This draft
was extensively discussed during the last call and within the IESG. As you
have seen, there has also been a number of document revisions and changes
based on the discussion. The last version reflected changes that the IESG
felt were necessary to move forward.

It has not been an easy to task to determine what the final outcome should
be. The IESG took the approach that the document should reflect community
opinion, not just our opinions, even if many of us had strong opinions on
the topic. But even reflecting community opinion was not easy. I have over
700 e-mails on this topic, some of those e-mails focus on specific aspects,
and the opinions and the draft changed as the discussion progressed [2].
Nevertheless, I want to thank everyone who has contributed on this topic.
You really care about this topic, and making the right recommendations at
the IETF. Thank you.

The IESG believed there eventually was consensus to publish the document
and our main question was whether the document should proceed as initially
planned (BCP) or whether it should be downgraded to Informational. After a
discussion we have concluded that there is (very) rough consensus to
publish the document as BCP. While there was clearly no full consensus, we
believe that issues were discussed sufficiently to allow them to be
addressed - even if no full agreement with the entire group could be
reached.

There were three high-level concerns that I wanted to discuss in this
e-mail:

1) Some forms of network management, traffic measurements, and similar
important tasks might be affected by a broad definition of pervasive
surveillance. We should obviously not make legitimate networking tasks
harder, and that was not the intent of the document. In the last version,
we believe that the the third last paragraph of Section 2 clarifies this
sufficiently.

2) The document has too little specific guidance, making it difficult to
follow it as a rule (if the document is a BCP) and is easily subject to
mis- or over-application. The document is indeed thin on the specific
guidance. Its primary message is to say that pervasive monitoring is yet
another threat that we need to consider when working on Internet
technology. This seems inline with RFC 2026 notion that BCPs can be
"community's best current thinking on a statement of principle". Also, we
see positive signs about many of those more specific details emerging in
various documents.

3) The document, particularly as a BCP, could be used to block documents
by ADs in an unreasonable fashion. There was considerable concern about
this. However, the IESG process for document approval is most commonly not
based on specific rules in existing RFCs, but rather specific technical
concerns of the individual AD reviewers. ADs occasionally raise invalid
issues on documents, and we expect (and get) pushback when that happens. I
have certainly made mistakes when filing a Discuss. These are resolved
through discussion. In more severe cases, we have override procedures,
appeals, discussions with the Nomcom, and recall procedures to deal with
these issues. In other words, if we start from the assumption of a
misbehaving AD, no new documents are needed to file an inappropriate
Discuss. Any AD can raise concerns about pervasive monitoring under the
current Discuss criteria, and this document doesn't change that. We don't
think this document will significantly change things for the worse.
However, the IESG felt that there is an opportunity to clarify our
procedures with regards to this specific case:

The IESG intends to make a change to its Discuss criteria statement [3].
While the general thrust of the statement already indicates that AD
disagreement with informed WG consensus is a NOT an acceptable basis for a
discuss, we wanted to say that more explicitly in the specific context of
adequate consideration for pervasive monitoring issues. Section 3.2 of the
Discuss criteria statement is about criteria that are not appropriate basis
for a Discuss. We plan to say that while it is generally necessary that
IETF work considers the impact of specific threats such as pervasive
surveillance, informed and rational community decisions about the
particular protocols and the possible need for mitigating mechanisms will
be respected.

In addition, there were a number of other issues that were discussed.
These included, for instance:

- Request to not support more encryption, and a point that surveillance
can have good or useful motives. (Although there is little by way of
solutions in the current draft, and previous RFCs have already talked at
length about IETF position towards encryption.)

- Argument that the document will lead to one concern dominating others.
(The draft says "... mitigate the technical aspects of PM, just as we do
for protocol vulnerabilities in general")

- Architectural issues and separate legal/political remedies should be
brought up. (They are now.)

- Whether to describe the issue as an attack or as indistinguishable from
an attack. (Current text is the result of the discussion started by Stephen
Kent.)

- The textual style of the document is that it reads as "too offended".
(Some changes were done regarding this, but otherwise this comment was
considered to be in the rough.)

- The document should include a checklist and more detailed actions. (See
2 above. Also, various documents under development are more likely to
produce a more fine-grained guidance on specific issues.)

This e-mail is a report of the IESG's conclusion on the matter. I will
proceed with the approval of the document in the next couple of days.

References:

[1] http://tools.ietf.org/html/draft-farrell-perpass-attack-06
[2]
http://tools.ietf.org/rfcdiff?url1=draft-farrell-perpass-attack-02.txt&url2=draft-farrell-perpass-attack-06.txt
[3] https://www.ietf.org/iesg/statement/discuss-criteria.html

Jari Arkko for the IESG


<Prev in Thread] Current Thread [Next in Thread>