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

Tao Effect <contact@taoeffect.com> Sat, 28 December 2013 18:37 UTC

Return-Path: <contact@taoeffect.com>
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 A72CB1AFFC2 for <cfrg@ietfa.amsl.com>; Sat, 28 Dec 2013 10:37:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.566
X-Spam-Level:
X-Spam-Status: No, score=0.566 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
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 0GivaQ3ArtKz for <cfrg@ietfa.amsl.com>; Sat, 28 Dec 2013 10:37:35 -0800 (PST)
Received: from homiemail-a2.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 22DC91AFFBF for <cfrg@irtf.org>; Sat, 28 Dec 2013 10:37:35 -0800 (PST)
Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id 1C07228006D; Sat, 28 Dec 2013 10:37:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=taoeffect.com; bh=XtAul8V9YCgohmhXA z4hBWbzLY4=; b=iyygiiOVspA1oCnbeE/bEt9lZHotRaTfqZlMRY/5XK/d+AQXi 429vsal6C9GOAcmUocbxtn9aMtSzm10E6U+IvSQX6s+IZugvamav2Kx+yJAfFzl1 O9f0bySUqTWwWXsMXG2tXwxqci1UeMCVYXfG27LE7VCiIK5GkJkKAMysuE=
Received: from [192.168.13.142] (adsl-98-70-220-147.gnv.bellsouth.net [98.70.220.147]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTPSA id 20837280069; Sat, 28 Dec 2013 10:37:26 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_343A0D59-A62C-4016-8411-F08329B37356"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Tao Effect <contact@taoeffect.com>
In-Reply-To: <52BD9B11.2000202@akr.io>
Date: Sat, 28 Dec 2013 13:36:47 -0500
Message-Id: <193E5491-B78A-483F-A93F-01B0AE389D36@taoeffect.com>
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> <52BD9B11.2000202@akr.io>
To: Alyssa Rowan <akr@akr.io>
X-Mailer: Apple Mail (2.1827)
Cc: cfrg@irtf.org
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: Sat, 28 Dec 2013 18:37:37 -0000

Based on Kevin's reply, dated Dec. 26th, it's clear that he has no interest in stepping down as co-chair.

Is there a process in place that would allow the community of the CFRG to vote on the matter?

If not, here's a simple one that allows for semi-secret vote (votes are revealed to only a tiny fraction of the members):

1. Select two or three people who participated in this discussion thread and expressed opposing views, call them the "Ballot Team"
2. Allow those who have participated in this discussion thread (or related threads, but you've gotta be specific) to send their vote to the Ballot Team via email.
3. Have the Ballot Team check to make sure the email is from someone who participated in this discussion, and send a confirmation reply back to them.
4. Upon receiving a confirmation back with the previous email quoted, mark down their vote.
5. Set a deadline for votes.
6. Have the Ballot Team publicly announce the number of "Yay" and "Nay" votes. If they match up, we can reasonably expect that no cheating happened.

Just an idea, probably not bullet proof, but it considers some of the potential issues of doing such a vote.

A better system, of course, would involve us knowing the result and nobody knowing how anyone else voted.

Cheers,
Greg

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

On Dec 27, 2013, at 10:21 AM, Alyssa Rowan <akr@akr.io>; wrote:

> Signed PGP part
> (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.
> 
[snip]
> 
> ___
> 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