Re: Transparency in Specifications and PRISM-class attacks

Ted Lemon <> Fri, 20 September 2013 18:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 799E421F99D0 for <>; Fri, 20 Sep 2013 11:29:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.497
X-Spam-Status: No, score=-106.497 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VV-ep4qCNAp9 for <>; Fri, 20 Sep 2013 11:29:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C4F9B21F994C for <>; Fri, 20 Sep 2013 11:29:13 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Fri, 20 Sep 2013 11:29:13 PDT
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by (Postfix) with ESMTP id 9E9DB1B82A4 for <>; Fri, 20 Sep 2013 11:29:11 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by (Postfix) with ESMTPS id 52297190068; Fri, 20 Sep 2013 11:29:10 -0700 (PDT) (envelope-from
Received: from [] ( by CAS-02.WIN.NOMINUM.COM ( with Microsoft SMTP Server (TLS) id; Fri, 20 Sep 2013 11:29:10 -0700
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1811\))
Subject: Re: Transparency in Specifications and PRISM-class attacks
From: Ted Lemon <>
In-Reply-To: <>
Date: Fri, 20 Sep 2013 10:27:18 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <>
References: <> <> <>
To: Martin Sustrik <>
X-Mailer: Apple Mail (2.1811)
X-Originating-IP: []
Cc: IETF Discussion Mailing List <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Sep 2013 18:29:23 -0000

On Sep 20, 2013, at 10:02 AM, Martin Sustrik <> wrote:
> Isn't it the other way round? That exactly because IETF process is open it's relatively easy for anyone to secretly introduce a backdoor into a protocol?

No, this is exactly wrong.

What is important about openness is not who is allowed to make changes, but who is allowed to see changes being made.   So sure, the NSA could send someone in to try to sabotage a protocol.   But people who want the protocol to be secure are also welcome.  This means that they have a chance to prevent the sabotage, if they can detect it as it is happening, and it also means that we can audit the process later to see if it was sabotaged, and if so, by whom.

By comparison, in a closed process, the NSA is still welcome.  Non-NSA people might well _not_ be welcome. There is no ability to validate the process as it is happening, so sabotage can easily be concealed.   And if sabotage is successful, it is easy both to conceal the fact of the sabotage, and also who is responsible for the sabotage.

When you think about the protection afforded by closed processes, you must always ask, quis custodiet ipsos custodes: who guards those who guard?   If the people acting as gatekeeper are corrupt, or are successfully fooled, then all is lost.   With an open process, everybody is potentially a gatekeeper, so it's much harder to corrupt the process.

In order to have backdoors, the thing in which the backdoor exists must be secret, either because nobody bothered to look, or because nobody _can_ look.   It is true that if nobody bothers to look, you can have a backdoor in any protocol, but we can't do anything about that.   We _can_ make sure that we are at least permitted to look for the backdoor.   And the IETF process very deliberately allows for that.