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

Alyssa Rowan <> Sun, 22 December 2013 01:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B968F1AE127; Sat, 21 Dec 2013 17:00:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5yRXehceJuCG; Sat, 21 Dec 2013 17:00:29 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2617B1AE11F; Sat, 21 Dec 2013 17:00:28 -0800 (PST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 954A660A12; Sun, 22 Dec 2013 01:00:24 +0000 (GMT)
Message-ID: <>
Date: Sun, 22 Dec 2013 01:00:27 +0000
From: Alyssa Rowan <>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
References: <>
In-Reply-To: <>
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-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 22 Dec 2013 01:00:31 -0000

Hash: SHA512

On 21/12/2013 22:37, Hilarie Orman wrote:

> Is the CFRG co-chair the only person in the CFRG who has 
> associations, proclaimed or covert, with an organization intent on 
> undermining the standards process?

Given you admit Kevin works for an organisation intent on undermining
the standards process, why would you, or anyone (or even he) wish him
to remain as co-chair?

Kindly explain.

> Take it as a challenge, is the IETF smarter than NSA or any other 
> organization with ulterior motives?

Frankly: no. (Disquieting, I know.)

They are a billion-dollar-funded Nation State Adversary; this is a
mailing list.

We are at quite a profound disadvantage. Please be mindful of that.

> That open process provides the resilience against attack.

That open process is our only defense: but yes, it can be a powerful
one. And so, here we are, openly having this discussion.

When they're blatant, like Dual_EC_DRBG - or when they have an email address - we can spot it, if we actually take the time
to look.

But with something more subtle (mysterious 'seeds' with no
nothing-up-my-sleeve numbers, say), all bets are off. Without knowing
everything they know, really the best we can do is hope to spot which
bits look 'off'.

Based on what we've seen so far, they particularly seem to like:

• Subverting random number generators
• Specifying algorithms which need strong RNGs every time
• Standards which encourage implementations susceptible to timing and
  other side-channel attacks

We need to particularly watch out for those three. (Of course this
list isn't complete. I wish it were.)

I note the common thread: fragility. The results of their efforts are
often easy to implement poorly, very hard to implement well: who
implements slow constant-time Brier-Joye ladders for short Weierstrass
curves? [Raise your hands, please...] Who used deterministic nonces
with (EC)DSA? [...anyone *before* RFC6979?] That seems in line with a
paradigm of making things that could be secure, but usually aren't.

For future standards and primitives, if we can ensure that the right
way is more obvious, we can make our efforts more resilient, against
malice and mistake alike - hopefully.

> Can the IETF make sound technical judgments based on written 
> documents?

On technical cryptographic literature? That is the purpose of the
CFRG, surely.

They defer here, as Watson points out: so whomever represents the
opinions of here carries weight. For that weight of trust to fall on
untrustworthy shoulders is unsound.

> choose leaders based on their competence and not on their 
> employment.

The (reasonable) concern is that his employer deliberately wishes to
seed incompetence in crypto standards, so they can break them.

No 'purge' is necessary: you overstate. Having him on the group is not
an issue, as we are clearly well aware of his affiliations, and can
take his opinions with the trustworthiness and credibility that goes
along with them: as we should do with everyone, as you, Paul, and
Daniel quite correctly point out.

But as co-chair, in charge of stating - or, indeed, misstating! -
group consensus to others? Good grief, no. It seems untenable; more
importantly, untrustworthy. We cannot possibly do that with a straight
face after IETF 88, can we? Surely not. Surely, neither can he.

Kevin: Do you even have a comment on this? Anything? Any answer?

- --