Update RFC1087 (Ethics and the Internet) [was Re: Last Call: <draft-farrell-perpass-attack-02.txt>]

Hector Santos <hsantos@isdg.net> Thu, 12 December 2013 12:50 UTC

Return-Path: <hsantos@isdg.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82C21AE295 for <ietf@ietfa.amsl.com>; Thu, 12 Dec 2013 04:50:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.001
X-Spam-Level:
X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPDMGn_unZ6X for <ietf@ietfa.amsl.com>; Thu, 12 Dec 2013 04:50:24 -0800 (PST)
Received: from pop3.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAB71AE293 for <ietf@ietf.org>; Thu, 12 Dec 2013 04:50:23 -0800 (PST)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4663; t=1386852611; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=jyfsk6lpvEsYJrW2VcxAx/pHErg=; b=BTKqfHlo145nveDP6eJ4 +SCwL9K7SCWHrivm+dBazqqG557kmdvMAhe2hFuQ6nuoNqayXyr04J7t6DGOPnTl MrWk4tFRm4IEh61c3Jiztq1F0oTyloFQRI2bRIZZIyCymEnoFmNyEIy+vJhIYEOC 5INd/wtB0jZBaz86X2PZIQA=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Thu, 12 Dec 2013 07:50:11 -0500
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com;
Received: from hector.wildcatblog.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 430112780.304.1640; Thu, 12 Dec 2013 07:50:09 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4663; t=1386852104; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=6W73UQR uwQtS5O8Zj8BaFP8MdVXzk5ZKfUIYlDW49Wo=; b=vKHxHM0dsHdwezQQSmWmYy7 ribo0gLsbh++0oo6DTPr4h+k6M3CNXX2iD3/BZBeie7PL46qerStMP+giiAA7yqV DJnTtKIzhnDWWoOug/ENguRQCAd5pCikLUYReQ5UV+dD57c6UMI4ZNgCmkrE5aNa rrR1BNQkOYGGN6vhzemk=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Thu, 12 Dec 2013 07:41:44 -0500
Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4171418457.9.5992; Thu, 12 Dec 2013 07:41:44 -0500
Message-ID: <52A9B105.2020801@isdg.net>
Date: Thu, 12 Dec 2013 07:50:13 -0500
From: Hector Santos <hsantos@isdg.net>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Jari Arkko <jari.arkko@piuha.net>
Subject: Update RFC1087 (Ethics and the Internet) [was Re: Last Call: <draft-farrell-perpass-attack-02.txt>]
References: <20131203174852.21387.26099.idtracker@ietfa.amsl.com> <A3B306E3-846C-45BA-8ED9-13B96AA645A3@piuha.net> <015101cef724$c7bda160$4001a8c0@gateway.2wire.net> <07A8290C-AC71-4395-B2C3-ED3F4E1C88B8@piuha.net>
In-Reply-To: <07A8290C-AC71-4395-B2C3-ED3F4E1C88B8@piuha.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Dec 2013 12:50:27 -0000

Hi,

The IETF/IAB may wish to update (and expand) the 1989 "ethics" 
document, RFC 1087:

            Ethics and the Internet
            http://tools.ietf.org/html/rfc1087

--
HLS

On 12/12/2013 6:41 AM, Jari Arkko wrote:
> 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 defi
nitely 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@btconnect.com> 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@piuha.net>
>> To: <ietf@ietf.org>
>> 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
>>
>>