Re: Transparency in Specifications and PRISM-class attacks

Phillip Hallam-Baker <hallam@gmail.com> Thu, 19 September 2013 16:49 UTC

Return-Path: <hallam@gmail.com>
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 DD10E21F8AD5 for <ietf@ietfa.amsl.com>; Thu, 19 Sep 2013 09:49:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.454
X-Spam-Level:
X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 OADQw0FOfJwa for <ietf@ietfa.amsl.com>; Thu, 19 Sep 2013 09:49:06 -0700 (PDT)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9211321F89EB for <ietf@ietf.org>; Thu, 19 Sep 2013 09:49:05 -0700 (PDT)
Received: by mail-la0-f43.google.com with SMTP id ep20so7036135lab.2 for <ietf@ietf.org>; Thu, 19 Sep 2013 09:49:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+ETqkhMIlbtPyPP/Icnj50wUXF73gra+7oAbhAvU+WI=; b=el55qZn0O6TYgUa5in7ThNATcISmOTlT5l09VNHXpc1V72yCHwRfaS9HSN0Sj3T0Mf jGG0zpGAgp5Kl7ZD2IonuD3Xh13lnUeMK6tYKtXRSSnrLcahveA113r/hFuS70tuJ4gg xG158faVINjKP5l7BMTH4pzEfSQY9NPTJvnGwglQy6ErIc0TEiQKJAd4bzgBY+/R/iHz 7MzAtgPzCtSVIM9S2RIFa8SCkHf1m1WCRJPPbIABJjm6nnA5XH5pDO0ArLMv5plcOFVA bJbvOvBcHAGlT21Mdik2ejcfTE8QyaTIToK1KB76FeQMztlORQz2aH3aq4A2IUnB/NZ8 Pi9g==
MIME-Version: 1.0
X-Received: by 10.112.159.166 with SMTP id xd6mr2518885lbb.22.1379609344428; Thu, 19 Sep 2013 09:49:04 -0700 (PDT)
Received: by 10.112.148.165 with HTTP; Thu, 19 Sep 2013 09:49:04 -0700 (PDT)
In-Reply-To: <523B1F60.5080204@gmx.net>
References: <CAMm+LwiYy1xVGFvcKNbmLEEWcnHns70CS6aH9zV4B0Xqg-OWOw@mail.gmail.com> <523B1F60.5080204@gmx.net>
Date: Thu, 19 Sep 2013 12:49:04 -0400
Message-ID: <CAMm+Lwji9bZvqCYchsqXG6pTwx3r+BiN=Vdo7GY6ia-E=iA1gg@mail.gmail.com>
Subject: Re: Transparency in Specifications and PRISM-class attacks
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: multipart/alternative; boundary="001a11c3db74e7502e04e6bf542d"
Cc: IETF Discussion Mailing List <ietf@ietf.org>
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, 19 Sep 2013 16:49:07 -0000

On Thu, Sep 19, 2013 at 11:59 AM, Hannes Tschofenig <
hannes.tschofenig@gmx.net> wrote:

> Hi Phillip,
>
> I am personally not worried that the standardization work in the IETF can
> be sabotaged by governments since our process is open, and transparent to
> everyone who cares to see what is going on. I could, however, see easily
> how that is a problem with some other organizations (without listing any).
>

Really?

Are IESG decisions transparent? Where are the audio recordings of the con
calls? Is the IESG/IAB retreat transparent? The NOMCON process certainly is
not.

I have been in pretty much every standards body in the field and the view
of the IETF from outside the IETF is exactly the same as the one you just
gave of those other organizations. Its the reverse of the grass is always
greener.

Document editors have a huge amount of discretion in what they do or do not
include in their documents. Rather more influence than the Chairs in most
WGs.


The traditional view of an RFC is that it is just a description of the
design. What I am arguing for is that we need to capture both the final
design and the design process. People are not going to go through ancient
working group archives to convince themselves that the design is sound. The
design docs have to provide all the explanation necessary.



> I believe it is useful to talk about specific cases instead of abstract
> concerns to see whether there is a problem at all in the IETF. Maybe that
> would allow us to find out whether there is a room for improvement.
>

I don't want to talk about specific cases because that leads to the game of
hunt the NSA mole which is a really bad idea.

-- 
Website: http://hallambaker.com/