Re: Transparency in Specifications and PRISM-class attacks

Harald Alvestrand <harald@alvestrand.no> Fri, 20 September 2013 10:19 UTC

Return-Path: <harald@alvestrand.no>
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 7A60B21F8596 for <ietf@ietfa.amsl.com>; Fri, 20 Sep 2013 03:19:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.385
X-Spam-Level:
X-Spam-Status: No, score=-110.385 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 WaSZI-YgU4gi for <ietf@ietfa.amsl.com>; Fri, 20 Sep 2013 03:19:02 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD7E21F8414 for <ietf@ietf.org>; Fri, 20 Sep 2013 03:19:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 17BD639E085 for <ietf@ietf.org>; Fri, 20 Sep 2013 12:19:01 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGrlKDjBWEKx for <ietf@ietf.org>; Fri, 20 Sep 2013 12:19:00 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:1003:d74f:d593:c954] (unknown [IPv6:2001:470:de0a:27:1003:d74f:d593:c954]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 6430239E068 for <ietf@ietf.org>; Fri, 20 Sep 2013 12:19:00 +0200 (CEST)
Message-ID: <523C216A.8030305@alvestrand.no>
Date: Fri, 20 Sep 2013 12:20:26 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: Transparency in Specifications and PRISM-class attacks
References: <CAMm+LwiYy1xVGFvcKNbmLEEWcnHns70CS6aH9zV4B0Xqg-OWOw@mail.gmail.com>
In-Reply-To: <CAMm+LwiYy1xVGFvcKNbmLEEWcnHns70CS6aH9zV4B0Xqg-OWOw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Fri, 20 Sep 2013 10:19:07 -0000

I'd like to snippet Phil's suggestion to an abbreviated version of one 
sentence, becaue I think this is right on.

On 09/19/2013 05:37 PM, Phillip Hallam-Baker wrote:
> The issue we need to focus on is how to convince our audience that our 
> specifications have not been compromised 

To my mind, the first thing to focus on is making our specs readable, so 
that it's possible to understand that they have not been compromised.

That means that complexity is our enemy.

(Or perhaps the zeroeth thing is actually finishing our specs, so that 
we can worry about whether RFC XXXX is compromised rather than worrying 
about whether deployed equipment has fixed the glitch that was 
introduced in -24 and fixed in -27, but everyone had forgotten about by 
-33...)