Re: Hum theatre

Jari Arkko <jari.arkko@piuha.net> Thu, 07 November 2013 18:12 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E702E21E8225 for <ietf@ietfa.amsl.com>; Thu, 7 Nov 2013 10:12:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.545
X-Spam-Level:
X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTIRnFUCpQfD for <ietf@ietfa.amsl.com>; Thu, 7 Nov 2013 10:12:10 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 8D25121E8148 for <ietf@ietf.org>; Thu, 7 Nov 2013 10:09:15 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 91BB62CC6B for <ietf@ietf.org>; Thu, 7 Nov 2013 20:09:03 +0200 (EET)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWNN4w6g2t2g for <ietf@ietf.org>; Thu, 7 Nov 2013 20:09:03 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id A519D2CC48 for <ietf@ietf.org>; Thu, 7 Nov 2013 20:09:02 +0200 (EET)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: Hum theatre
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <527BD0D1.4000708@qti.qualcomm.com>
Date: Thu, 7 Nov 2013 10:09:00 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <B0ACC5AB-F87B-4EF5-801F-27BBA7445E98@piuha.net>
References: <527AF986.4090504@dcrocker.net> <CAHBU6iuDXQok_QRZe7BL__Vmkn447vUCSViDgrVkaedKAHcnfw@mail.gmail.com> <m2bo1w29zw.wl%randy@psg.com> <527B3F62.3030005@qti.qualcomm.com> <CAL02cgRNTCuQWXsZQOKKpMtPa09PYhFj5FncghOmORsZ8hb13A@mail.gmail.com> <527BD0D1.4000708@qti.qualcomm.com>
To: IETF Discussion <ietf@ietf.org>
X-Mailer: Apple Mail (2.1510)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
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, 07 Nov 2013 18:12:16 -0000

I wanted to provide my thoughts on this. 

First, in the interest of full disclosure, Russ and I conferred on stage about the questions, and he had my OK to go ahead. 

Now, of course the questions were at a high level, and with full hindsight they could have been more neutrally formulated. At the end of the day, they are what they are. And should be given the value they deserve.

I'd actually like to argue that the IETF position on this topic is something bigger, something where the plenary discussion and hums played a supporting role but they are not the sole determination. Here's my take-away from this week:

"The IETF considers pervasive-monitoring as a security issue and is willing to work to address it."

Nothing more, nothing less. Most working groups that I went to were addressing this topic in one way or the other, going through application by application, doing careful work to understand what options we have to improve security, and weighing the various trade-offs in different designs. The proof of the pudding is in the eating. "We need to address it" vs. "We are putting in the cycles to address it". When I look at the discussions throughout the week, it is very clear to me that we are putting in the cycles. 

As Carsten said:

> As always, hard work follows, and the devil is in the details.  But that doesn’t take away from the unanimity.

And indeed there are a lot of details and trade-offs to worry about. Opportunistic encryption, for instance, has been discussed at length this week and the variants and trade-offs are far from clear.

I think the next steps are what is important. And this is a long term effort. Here are some of the things we should be doing:

- work on the general guidance in this area ("consider it as an attack", "recommended ways to apply opportunistic encryption", "threat model changes", ...)

- work on the specific protocols and application areas (http, xmpp, etc)

Jari