Re: [Cfrg] Requesting removal of CFRG co-chair

Alyssa Rowan <akr@akr.io> Fri, 27 December 2013 15:21 UTC

Return-Path: <akr@akr.io>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B251AE183 for <cfrg@ietfa.amsl.com>; Fri, 27 Dec 2013 07:21:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.201
X-Spam-Level:
X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, LOTS_OF_MONEY=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GIbtY5B2kza for <cfrg@ietfa.amsl.com>; Fri, 27 Dec 2013 07:21:46 -0800 (PST)
Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id E7EC51ADF5D for <cfrg@irtf.org>; Fri, 27 Dec 2013 07:21:44 -0800 (PST)
Received: from [10.10.42.10] (cpc5-derb12-2-0-cust796.8-3.cable.virginm.net [82.31.91.29]) by entima.net (Postfix) with ESMTPSA id C32E0609E7 for <cfrg@irtf.org>; Fri, 27 Dec 2013 15:21:38 +0000 (GMT)
Message-ID: <52BD9B11.2000202@akr.io>
Date: Fri, 27 Dec 2013 15:21:53 +0000
From: Alyssa Rowan <akr@akr.io>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: cfrg@irtf.org
References: <CAGZ8ZG2f9QHX40RcB8aajWvEfG0Gh_uewu2Rq7bQGHYNx6cOmw@mail.gmail.com> <52B91820.9090706@cisco.com> <CAGZ8ZG02+o=Qm0gUQiVF9H_=wfn+wQt8ahY1ntLHNsELXbvtVg@mail.gmail.com> <AA79A33E-D6B9-4693-A670-B4458011B394@cisco.com> <CA+cU71mTCVHAe2a46USJihr9ihPVw_vQTu0xk-mpRp41La88Xg@mail.gmail.com> <e4054b534e308e3c17c22ccf987d3edc.squirrel@www.trepanning.net> <E7E97A5B-455F-4ABD-A182-DF6DC38F3429@taoeffect.com> <199f08bb0a197065184a07bed40e4e1a.squirrel@www.trepanning.net> <545E0C9B-5C24-43EA-85BE-03A13D70C2E2@taoeffect.com> <52BC6A6F.2000807@cisco.com>
In-Reply-To: <52BC6A6F.2000807@cisco.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: Re: [Cfrg] Requesting removal of CFRG co-chair
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Dec 2013 15:21:49 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

(Restoring the subject line, so Lars can better follow the thread.)

On 26 Dec 2013 20:07, Igoe, Kevin M. wrote:
> While NSA’s SIGINT mission gets all the press (especially now), the
> Agency has another mission: Information Assurance.

Unfortunately, given the SIGINT Enabling Project has used the NSA's
Information Assurance mission as official cover for sabotage of
cryptographic primitives¹, implementations², and standards³, not to
mention their interesting conduct in statements and enquiries so far,
any trust or confidence once placed in the NSA for anything by anyone
has now been fatally, critically, permanently undermined.

I can't imagine the NSA's IA department is pleased about that at all
(particularly if it wished to, in time, use the protocols and COTS
software and hardware, such as your BlackBerry, that its SIGINT
department meanwhile was no doubt busily trying to subvert). That is,
of course, an internal issue between your respective departments,
NIST, the wider US Government, and of course the American people it
serves.

No comment is required: I understand you may find yourself in a
difficult position regarding such things. However, if you (or anyone
with the knowledge) felt yourself ethically able and willing to
disclose the specific nature and existence of any vulnerabilities so
seeded - and indicate if, and how, you have addressed them in any
software or hardware you have fielded - I would heartily encourage it.

We certainly aren't pleased about it, because to meet the 'perpass'
threat posed by Nation State Adversaries (a convenient initialism)
discussed at IETF 88, we're going to have to change, redesign and
deploy several new and improved primitives, protocols, standards and
implementations. This will be hard, and yes, will take years to
finish; the IETF, and CFRG, will play a vital part, I feel.

As the other co-chair, David McGrew correctly points out:
> The Research Group needs to have chairs that it trusts, and who are
> trusted by the broader IETF and Internet communities that they work
> with.

Our work needs to be carried out openly and transparently so that it
can be trusted. And that process needs to be administered by people we
mistrust as little as possible, and clearly not by an
openly-acknowledged agent of an organisation systematically trying to
sabotage the process of devising and deploying strong cryptography:
it is a simple, and unavoidable, conflict of interest, I'm afraid.

I therefore reiterate the call for your resignation as co-chair.
I mean no personal disrespect, but it's clear you understand the
situation.

I hear Mr Schneier might be too busy. Besides, the job is, as you say,
unglamorous, and administrative. Still, perhaps a trusted
international cryptographer (perhaps in a jurisdiction with no
National Security Letters or similar means of potential coercion to
overlook a potential backdoor?), with the time available would be a
good choice?

I'm not sure a similar situation has arisen before, and therefore
there might well be no established procedure; of course, we can be
patient. Perhaps, if your colleagues and counterparts could be
persuaded to curtail their excesses, a similar situation may not arise
again. I remain guardedly hopeful.

In any case, I wish yourself (and your daughter) well, and please have
a enjoyable holiday.

___
1. Specific documented example: Dual_EC_DRBG - a backdoor that couldn't
   have been more obvious if you'd erected a flashing neon sign and
   driven a mounted parade with a marching band through it. We have no
   reason to expect other 'enablings' to be as obvious, of course.
2. Specific documented example: RSA Security; BSafe; $10m; Dual_EC_DRBG.
3. 802.11; GSM; LTE. Bluetooth? (Even perhaps TLS?) Hard to be sure...
   it's the kind of subtle sabotage that makes the result awful by
   design, rather than simply awful by committee; the two are hard to
   distinguish, which is the point, and the end result is similar,
   as is the need to improve and fix.

- -- 
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJSvZsQAAoJEOyEjtkWi2t6fc4QAJOP5dVI6HpSKLgqFK5AqUL2
aQl4zSje5yOk74eHaUw8cHYfwB8hfOOJCf/3IxYebybK+4rkylXl31HEsVPn2c1W
1XTqyNDXHvD1j4BMJrQFeHsMLvn4zusRW/pE1fAREpnmtC5pshxI6V+rhXS+vQUN
bx+/jiccVyr6LDc6IGSntu+jGEhqdyQQZ6LScieX78xOlf44WEa0txOM29HH9jNr
p8sBCX9UmMmo+aKLhoZRJQFDojhENn9XEp3oSQ0025ZDCTwHtvDAQP/jDxYJ/wcd
5RiOhkV3hQ6NtjdKkpJXKsVFWxQVmFvqf1YQvz8YjyJsThqDHgWdYHxLQeCon3Ia
u/h3cEyL4yM7rSyTF5GyNyp5XKZQDaq+Us0i+qyGLKesaPDfD7WXawfIAtvRcO0l
PqY34HQK4HCyGZrRlO4p+teUeJGVNHz1UbI0tH2ez9brnFNWdV1IeBVWpu17O+S5
3TBxzvkr+ASR5Vmy99hU79vET4yGwbAvwbwpo17keb/tmuKdAAjivg7Zc0vFdQpj
SpizLj42eimSO8rrc+v/MjJMASrVPF/dd/lGxSYQs3O0QJgi4CVMIeJdCpoG3owf
k41izNW4AUPVT7ocNMRIdOjeI+bk9EY4TLAMQ0HQS284EO/aIQds3voCTm5APf2r
jH83colAGkauRnacurlB
=QC3G
-----END PGP SIGNATURE-----