Re: [Cfrg] Response to the request to remove CFRG co-chair

Trevor Perrin <> Thu, 09 January 2014 02:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A7FD31AE02B for <>; Wed, 8 Jan 2014 18:46:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.208
X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z7iLtiomlPAP for <>; Wed, 8 Jan 2014 18:46:22 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6F3551AE02D for <>; Wed, 8 Jan 2014 18:46:20 -0800 (PST)
Received: by with SMTP id z2so2903917wiv.12 for <>; Wed, 08 Jan 2014 18:46:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fR2lghMbWObhcOLFmQQbLF6bYgZ3fXP5oobgj/K4bvI=; b=JMt2c2QPhR6cznsBhta7RTHD+UWoD4WBJVLSXnMfgMz0t0A6tiFTUys9yUEXOy1Rhe ikUoAcKdxEQXEGN51HbZtsij1SiLf/wChg0kQtmzpQJlbtoa1RcaUh8pDvhZcgmFKDQK 4YiA+4waqCe9Ww1EbcIHXJsneuQ4QsZAACwCuKeg0ACu5izm3NmfEpRCMeCfnVBuTNLK ZB/VBQXyHUGLsIW9Vny6VMpcxuRtKCmMh6XXFNBbrLPhYR6FAe7dEHJNyPeYqFSUGBLI OJ6gTdYMEWNdO7xffrTTR2aRIB4R3g5A2JtbNTPrJCGp3GycD+We2utr6KcYdU3UfQqp osuQ==
X-Gm-Message-State: ALoCoQnp6aQbxOSxTb0LBshqnIYiwycuLT0B5oQax4X8oKhxTPXGK5cXxwbTV0ZEbnMCbdS1ElvG
MIME-Version: 1.0
X-Received: by with SMTP id l9mr980294wiz.20.1389235570515; Wed, 08 Jan 2014 18:46:10 -0800 (PST)
Received: by with HTTP; Wed, 8 Jan 2014 18:46:10 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Wed, 08 Jan 2014 18:46:10 -0800
Message-ID: <>
From: Trevor Perrin <>
To: Stephen Farrell <>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: Adam Back <>, "" <>, David McGrew <>,, IAB IAB <>
Subject: Re: [Cfrg] Response to the request to remove 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: Thu, 09 Jan 2014 02:46:24 -0000

On Wed, Jan 8, 2014 at 8:20 AM, Stephen Farrell
<> wrote:
> Hi Adam,
> On 01/08/2014 03:17 PM, Adam Back wrote:
>> Hi John
>> I've seen several people putting forward a similar argument.  There is some
>> logic but its I think an incorrect conclusion.
> I think there's a bit more subtlety to the conflict of interest
> issue than maybe some folks appreciate.

Hi Stephen,

I'd like to understand the subtlety better.  The IETF/IRTF leadership
seems terrified that considering an egregious conflict of interest in
a chair is a "slippery slope" to membership fees, loyalty oaths, and

I don't understand this.  Chairs are appointed (I assume) by weighing
many factors:  are they smart?  Fair?  Good communicators?
Trustworthy?  Easy to work with?  Knowledgeable both technically and
of IETF/IRTF process?  I would think being clear of severe
conflicts-of-interest is also good.

No-one wants to make these criteria for excluding participants.  But
if a chair's lack of these qualities threatens a group's performance,
surely it's appropriate to consider a replacement?

> Within the IETF its not that uncommon to have conflicts of
> interest where a company would like to sabotage a piece of
> standards work, in ways that seem quite similar to the current
> situation and that do not involve IPR, nor the misbehaviour
> of an individual chair.
> Say company-x have a product doing some proprietary thing
> that has significant market share. Then others propose to
> standardise that function, which company-x might consider
> would lessen their advantage with their product. It would not
> at all be a surprise to see people acting for company-x
> (employed, as consultants or business partners) trying to
> bugger up the standards process by e.g. trying to make the
> standard take ages, be over-complex or omit some crucial
> functionality. And if company-x aren't dumb then that can
> be attempted without any obvious evidence being left about.

And this is just totally acceptable, day-to-day life at the IETF?

> Now if company-x are of any size, then its quite likely
> that employees of theirs are chairing other WGs. And for
> a long-lived WG with a generic charter, it'd not be at
> all unusual if someone working for company-X co-chairs
> the WG in question.
> So - what's different here? Are we saying that if a
> company-x marketing department memo leaks that says "let's
> bugger up <foo>" then we should fire the person who's
> co-chairing that WG?

Depending on the credibility of the memo and the consequences of the
buggering, I would think that's reasonable to consider.

I disagree that this needs to be framed as "fire the person".  That
implies this is some exceptional and insulting process to inflict on

But there is no other process to replace an RG chair except for having
the IRTF chair replace them.  Kevin has no term limit.  We can't just
wait 6 months and then quietly ease him out, or something.

Perhaps there should be some process for selecting new chairs
periodically that is less confrontational, but unless I'm missing
something, there is not.

>> I understand the conflict of interest when people are somewhat
>> pushing their companies approach, related to their product or
>> implementtion choices they have some investment in, but generally
>> tempered by reasonableness.  All the companies that care can put
>> their voice in also.  IPR disclosures are also there.  Loose
>> consensus and running code copes with that ok.
> I think you left out a critical part of that, at least as its
> done in the IETF and IRTF - the participants ideally act as
> individuals and not on behalf of their employers and are treated
> that way. There is a serious danger of going down the slippery
> slope to paid membership if we deviate from that, with what I
> think would be overall worse outcomes.

You lost me - what does "paid membership" have to do with this?

>> I think NSA sabotage is a significantly different and its unrealistic to
>> just assume a chair has no influence.  A non-NSA chair would strive for
>> impartiality with regard to their employers interests.  If certicom
>> wants to
>> push something and cisco something else they are both pushing for something
>> reasonably secure as a fundamental assumption and trying to make secure
>> systems so their customers will buy them.  Forward secrecy is good,
>> architectural weaknesses bad etc.
>> The NSA is NOT in that boat.  They are explicitly sabotaging security on a
>> grand and systematic scale at all levels including standardization.  They
>> dislike forward secrecy, and like architectural weakness and architectural
>> tap points and sabotaged RNGs, and fragile hard to implement correctly
>> standards with traps.  There were numerous news articles by Greenwald and
>> others backed by NSA docs about these strategies.
> Other than the headline 250/yr I think I've only seen
> convincing evidence related to the RNG stuff though. The
> rest afaik is speculation. If I missed more that's been
> published, I'd appreciate pointers.

See the BULLRUN reporting and documents:

Adam's speculations strike me as plausible and consistent with the
documents we have.  I think acting on "risk avoidance" grounds is
prudent here, instead of demanding absolute proof of what would of
course be covert and "deniable" activities by sneaky people.

> But there's IMO a far more likely explanation for why we end up
> with stuff that fits this particular speculation - a lot of
> standards work ends up being dominated by people with more
> complex requirements and its always hard to keep stuff simple.
> In the case of security protocols, the US DoD requirements, as a
> customer (e.g. for PKI) are about as complicated as it gets and they
> can afford to pay folks to work on that. So we've ended up with
> PKI that's over complex for many other use-cases.

Huh.  That's not all that different from the fears Adam has, or my
concern about "softer forms" of sabotage.  At least, the line between
"sabotage" and "not quite working in the Internet's best interest" is
a blurry one.

For example:  It's interesting how NIST tends to standardize
algorithms that work well in hardware but are tricky in software.  And
how DoD's steering of PKI worked for DoD, I suppose, but has not
resulted in working key management for the Internet.