IETF Logo Mail Archive

Re: Transparency in Specifications and PRISM-class attacks

jnc@mercury.lcs.mit.edu (Noel Chiappa) Fri, 20 September 2013 15:25 UTC

Return-Path: <jnc@mercury.lcs.mit.edu>
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 32B5121F9AE6 for <ietf@ietfa.amsl.com>; Fri, 20 Sep 2013 08:25:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 Hljy8acB3aYY for <ietf@ietfa.amsl.com>; Fri, 20 Sep 2013 08:25:14 -0700 (PDT)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id BB58621F9AE3 for <ietf@ietf.org>; Fri, 20 Sep 2013 08:25:09 -0700 (PDT)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D98FC18C142; Fri, 20 Sep 2013 11:25:06 -0400 (EDT)
To: ietf@ietf.org
Subject: Re: Transparency in Specifications and PRISM-class attacks
Message-Id: <20130920152506.D98FC18C142@mercury.lcs.mit.edu>
Date: Fri, 20 Sep 2013 11:25:06 -0400
From: jnc@mercury.lcs.mit.edu
Cc: jnc@mercury.lcs.mit.edu
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 15:25:19 -0000

    > From: Martin Sustrik <sustrik@250bpm.com>

    > 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?
    > ...
    > With IETF standard there can very well be several unknown backdoors
    > introduced by different parties, so it's never safe.

Iff enough people are _carefully_ reviewing specs, that ought to find all the
backdoors. An open process does have potential issues, but it's also the one
with the best chance of producing a 'good' product.

    > That being said, wouldn't it make more sense to admit that IETF is not
    > a good platform for devising, say, crypto protocols and act accordingly
    > (use 3rd party protocols ...)?

You mean, trust another entity, which might have been suborned? How are they
less likely to have produced something without backdoors than the IETF?

	Noel

v2.35.0 | Report a Bug | By Email | System Status