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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 08 January 2014 16:20 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 E304F1AE4F5; Wed, 8 Jan 2014 08:20:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level:
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RP_MATCHES_RCVD=-0.538] 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 g4p5ZmLlPfXF; Wed, 8 Jan 2014 08:20:39 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1941AE4F3; Wed, 8 Jan 2014 08:20:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1B5D0BE49; Wed, 8 Jan 2014 16:20:29 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbev25zGUnOV; Wed, 8 Jan 2014 16:20:29 +0000 (GMT)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E8873BE3F; Wed, 8 Jan 2014 16:20:28 +0000 (GMT)
Message-ID: <52CD7ACC.4060305@cs.tcd.ie>
Date: Wed, 08 Jan 2014 16:20:28 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Adam Back <adam@cypherspace.org>, John Viega <john@viega.org>
References: <492D56BD-6F33-480D-877E-02D907C5F4AA@netapp.com> <CAGZ8ZG37MoEMaPwjJynCceGpjoPASXd5CC9AG1bzdm8ZFPpDtA@mail.gmail.com> <52CD4637.2070207@cisco.com> <20140108134213.GA26603@netbook.cypherspace.org> <853B0E5F-E5AC-4CE0-BCBC-602828D4AEE7@viega.org> <20140108151722.GA4441@netbook.cypherspace.org>
In-Reply-To: <20140108151722.GA4441@netbook.cypherspace.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Cc: Trevor Perrin <trevp@trevp.net>, David McGrew <mcgrew@cisco.com>, "cfrg@irtf.org" <cfrg@irtf.org>, irtf-chair@irtf.org, IAB IAB <iab@iab.org>
Subject: Re: [Cfrg] Response to the request to remove 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: Wed, 08 Jan 2014 16:20:43 -0000

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. (If this is old-news
for you, sorry for wasting the bytes:-)

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.

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?

I do agree that NSA's US$250M/yr for messing up Internet
security is just horrendous, and we should be (and some of
us are) working hard to make that wasted-effort to the
extent we can, but what I'm not seeing is the difference
between the NSA situation and the company-x situation as
it affects a sitting chair in the absence of a smoking
gun that directly implicates the chair involved.

And if Lars or the IAB fire Kevin for his affiliation then
I'd be quite worried about the precedent that'd set especially
since there will be a lot of company-y folks who might in
future see that going down the same route could benefit
company-y and damage company-x, even if the accusations were
baseless. We could be creating a significant DoS vector
that way.

To be clear about the above - I don't think that either
NSA nor company-x are doing the right thing, but we do
need to do our best to make the processes work well and
fairly even if they are bad-actors.

A couple of other points below, but those are maybe less
interesting.

> 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. And there's a constant
pressure to take that slippery slope for other reasons, e.g.
to "better" handle IPR, or to recognise the reality that it
costs a lot to fully participate, so we do need to be very
careful about anything related to affiliation alone lest we
damage the openness that allows an idiot in an Irish university
to end up as a sec AD:-)

> 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. Or if the folks with
access to the materials have more evidence on that aspect, I
really hope they manage to publish that sooner rather than
later.

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. A sort of
similar thing happened with oauth, where the (non-govt) enterprise
use-cases dominated for similar reasons.

And I think the security folks within the IETF (including
me) also need to take some blame for putting too much
emphasis on "purity" (for want of a better word) and not
enough on deployability and simplicity. I hope (but also
think) we have learned that lesson.

> I suppose I need to go find the declassified military sabotage manual
> that I
> mentioned Ian Grigg quotes from.  You, and others making this argument,
> should read and extrapolate (the part is a very short, one page).  "OSS's
> Simple Sabotage Field Manual, a 1944 document"
> 
> http://svn.cacert.org/CAcert/CAcert_Inc/Board/oss/oss_sabotage.html
> 
> No I am not being paranoid, the journalists have the docs, and they are
> publishing the summaries and some of the actual docs, and their technical
> analysts supporting them are Schneier & Applebaum.

I'm not saying you're paranoid, nor that Bruce of Jake are
wrong, but I'm not convinced by that part of the argument, as
of now.

Cheers,
S.

> 
> So again I do not find it acceptable to have an agent of a now known
> industrial scale sabateur in a chair position.  Maybe you would feel
> different if it were Chinese military intelligence and they were shown via
> leaks to have succeeded in backdooring a protocol the world is using, based
> on abused good faith in open standards, and say used it to exfiltrate info
> from US defense contractors and military, and an openly Chinese MI
> affiliated guy was co-chair.  Not sure what triggers people to get it.  Its
> ridiculously and egregiously inappropriate from where I am sitting.
> 
> Adam
> 
> (IETF participant since 1996)
> 
> On Wed, Jan 08, 2014 at 09:37:36AM -0500, John Viega wrote:
>>   I agree with David that competence doesn’t factor into it.
>>
>>   Conflict of interest is an issue here.  But again, even before recent
>>   NSA revelations, there would often be participants with a conflict—
>>   good of the participant’s company vs. good of the world.  Even now,
>>   where NSA is part of the threat model, we shouldn’t expect every actor
>>   with a conflict is going to walk in with an NSA badge.
>>   I don’t think conflict of interest is a good enough basis for removing
>>   a chair.  The IETF/IRTF needs to be able to design standards when many
>>   actors have conflicts, and should be able to give confidence in what
>>   they produce.
>>   The most important thing from my perspective is making sure the
>>   IETF/IRTF has the public trust.  I think it’s possible to do this
>>   without removing Kevin, especially if the IETF/IRTF can clearly
>>   communicate how it prevents subversion.
>>   That is, if the world cares enough.  I suspect that very few people are
>>   going to boycott IETF/IRTF-driven standards if no further action is
>>   taken.
>>   John
>>   John Viega | cel +1 212-321-0902
>>   On Jan 8, 2014, at 8:42 AM, Adam Back <[1]adam@cypherspace.org> wrote:
>>
>>     I support Trevor in raising the conflict of interest, its pretty
>>     egregious
>>     and Kevin should in my view resign gracefully to end this mess.  If
>>     hes
>>     clean and works for IA as he says its a nice way out.  If hes not
>>     and is
>>     actually part of the sabotage side its still a quieter way out than
>>     being
>>     pushed.  It probably doesnt look as clean either way if he is
>>     pushed.  If he
>>     is not pushed it just creates bad impression of the impartiality of
>>     IRTF. Sort of like the justice system closing ranks and supporting
>>     Hoover after
>>     the scandal and him staying in office with immunity by analogy.  I
>>     am not
>>     sure of the game theory from NSA sabotage side, if they would prefer
>>     Kevin
>>     (whether on their budget or not) to let the noise continue and be
>>     pushed or
>>     skip the noise and resign, or noise continue, plus fail to push him
>>     and
>>     continue with the resentment and reputation loss to IRTF.
>>     There is some validity in what David said below also.  Some of
>>     Kevins stuff
>>     looks suspicious to others also, its certainly not just Trevor, but
>>     of
>>     course its not provable - the worst parts are either innocuously
>>     ill-considered/sub-optimal suggestions, as with the next guy prone
>>     to human
>>     failure (which is somewhat plausible) or designed to be unprovable.
>>     $250m/year managed with military intent can achieve that you know,
>>     its not
>>     hard.  There are unclassified military intelligence double agent
>>     sabotge
>>     manuals that Ian Grigg posts quotes from now and then that show the
>>     basic
>>     ideas.  Most of them still seem quite relevant.
>>     Anyway the point I wanted to draw from David's comment is we cant
>>     and wont
>>     be able to prove it.  BUT I think anyone is certainly within their
>>     right to
>>     comment on things that look suspicious, or insecure.  See I think
>>     for
>>     comparison the RNG bias Bleichenbacher found in DSA RNG leading to
>>     key
>>     recovery are fair game.  As is Ferguson et al's comments about
>>     EC_DRBG.  Or
>>     Trevors about some of the decisions relating to Dragonfly.  Or Prof
>>     Bernstein's comments about Kevin's recent post here about certicom
>>     patents
>>     pushing towards less secure curves (see the crypto list).
>>     Its called peer review.  If anyone cant stand their thoughts and
>>     public
>>     statements being peer reviewed, probably participating in IRTF/IETF
>>     or
>>     uncensored internet discussion in general is not for them.  As we
>>     have
>>     pretty incontrovertible proof that NSA has been sabotaging
>>     standards,
>>     unfortunately that opens up review of input to the standards
>>     influenced by
>>     any NSA participants.  Its ugly but we didnt create the problem,
>>     Kevin's
>>     employer did.  Sorry.
>>     So unfortunately it is probably relevant that apart from conflict of
>>     interest, the public record is not suspicionless.  Imagine NSA /
>>     NIST
>>     communications about EC DRBG were public.  There'd be a pretty clear
>>     public
>>     interest to go over the history of it, see who was supporting it or
>>     aware of
>>     it within NIST.  Its really not that dissimilar.
>>     We may in the longer term have to review and even deprecate existing
>>     standards as a result of this militarized sabotage of its own and
>>     global
>>     civilian infrastructure.
>>     ps I support Trevor in rejecting Lars assertion that IRTF co-chair
>>     has no
>>     influence.
>>     Adam
>>     (IETF participant since 1996).
>>     On Wed, Jan 08, 2014 at 07:36:07AM -0500, David McGrew wrote:
>>
>>     Hi Trevor,
>>     I recognize and support your right to raise the question of a
>>     conflict of interest between the NSA and CFRG.  I am confident that
>>     the IRTF chair and IAB will give it due consideration.
>>     However, I am concerned that your efforts to find evidence in the
>>     CFRG email archive that support the idea that Kevin is incompetent
>>     are unwarranted and counterproductive.   While many people agree
>>     with you about the conflict of interest, many disagree with you on
>>     the subject of competence.  It is not hard to go through the email
>>     archive and find examples where someone misstated something, or did
>>     not explain something completely, but doing so does not advance the
>>     security or privacy on the Internet, which is the goal that you and
>>     I share for CFRG.  That goal would best be served by focusing the
>>     valuable time of the research group members (a scarce resource that
>>     we need to manage well) on addressing technical issues.   Therefore,
>>     I respectfully ask that, in your request to the IAB, you focus on
>>     the key issue of the conflict of interest.
>>     David
>>     On 01/06/2014 08:48 PM, Trevor Perrin wrote:
>>
>>     Hi Lars,
>>     Thanks for considering this request.
>>     Of course, I'm disappointed with the response.
>>     --
>>     I brought to your attention Kevin's record of technical mistakes and
>>     mismanagement over a two year period, on the major issue he has
>>     handled as CFRG co-chair.  You counted this as a single
>>     "occurrence",
>>     and considered only the narrow question whether it is "of a severity
>>     that would warrant an immediate dismissal".
>>     I appreciate your desire to be fair to Kevin and give him the
>>     benefit
>>     of the doubt.  But it would be better to consider what's best for
>>     CFRG.  CFRG needs a competent and diligent chair who could lead
>>     review
>>     of something like Dragonfly to a successful outcome, instead of the
>>     debacle it has become.
>>     --
>>     I also raised a conflict-of-interest concern regarding Kevin's NSA
>>     employment.  You considered this from the perspectives of:
>>     (A) Kevin's ability to subvert the group's work, and
>>     (B) the impact on RG participation.
>>     Regarding (A), you assessed that IRTF chairs "are little more than
>>     group secretaries" who "do not wield more power over the content of
>>     the ongoing work than other research group participants".
>>     That's a noble ideal, but in practice it's untrue.  Chairs are
>>     responsible for creating agendas, running meetings, deciding when
>>     and
>>     how to call for consensus, interpreting the consensus, and liaising
>>     with other parties.  All this gives them a great deal of power in
>>     steering a group's work.
>>     You also assessed that the IETF/IRTF's "open processes" are an
>>     adequate safeguard against NSA subversion, even by a group chair.
>>     I'm
>>     not sure of that.  I worry about soft forms of sabotage like making
>>     Internet crypto hard to implement securely, and hard to deploy
>>     widely;
>>     or tipping groups towards dysfunction and ineffectiveness.  Since
>>     these are common failure modes for IETF/IRTF crypto activities, I'm
>>     not convinced IETF/IRTF process would adequately detect this.
>>     Regarding (B), you judged this a "tradeoff" between those who would
>>     not participate in an NSA-chaired CFRG (like myself), and those
>>     "affiliated with NSA" whom you presume we would "eliminate" from
>>     participating.
>>     Of course, that's a bogeyman.  No-one wants to prevent anyone else
>>     from participating.
>>     But the chair role is not a right given to every participant, it's a
>>     responsibility given to those we trust.  The IETF/IRTF should not
>>     support a chair for any activity X that has a strong interest in
>>     sabotaging X.  This isn't a "slippery slope", it's common sense.
>>     --
>>     Finally, I think Kevin's NSA affiliation, and the recent revelations
>>     of NSA sabotage of a crypto standard, raises issues you did not
>>     consider.
>>     You did not consider the cloud of distrust which will hang over an
>>     NSA-chaired CFRG, and over the ideas it endorses.
>>     You also did not consider that as the premier Internet standards
>>     organization, the IETF/IRTF's actions here will make an unavoidable
>>     statement regarding the acceptability of such sabotage.
>>     We have the opportunity to send a message that sabotaging crypto
>>     standards is unacceptable and destroys public trust in those
>>     organizations in a way that has real consequences.  Or we send a
>>     message that it's no big deal.
>>     This is a political consideration rather than a technical one, but
>>     it
>>     needs to be considered.  We're sending a message either way.
>>     --
>>     I understand there's no formal appeal process, but these issues are
>>     of
>>     great importance to the IRTF and IETF, and would benefit from the
>>     perspective IAB possesses.
>>     I would appreciate if the IAB would consider reviewing this issue
>>     and
>>     expressing its judgement.
>>     Trevor
>>     (a couple comments below)
>>     On Sat, Jan 4, 2014 at 11:49 PM, Eggert, Lars <[2]lars@netapp.com>
>>     wrote:
>>
>>     Hi,
>>     on Dec 20, 2013, I received a request from Trevor Perrin in my role
>>     as IRTF Chair to consider the removal of Kevin Igoe as one of the
>>     co-chairs of the IRTF's Crypto Forum Research Group (CFRG). The
>>     request stated several reasons for the removal:
>>     (1) That Kevin Igoe provided the only positive feedback on the
>>     "Dragonfly" key exchange protocol.
>>     (2) That Kevin Igoe made technical suggestions that would have
>>     weakened the cryptographic properties of "Dragonfly".
>>     (3) That Kevin Igoe misrepresented the CFRG opinion on "Dragonfly"
>>     to the IETF's TLS working group.
>>     (4) That Kevin Igoe is employed by the NSA.
>>     I have reviewed the mailing list discussion, as well as the emails
>>     that were sent privately. Thank you all for being candid in your
>>     feedback.
>>     David McGrew, the CFRG's other co-chair, has already posted a
>>     detailed timeline of events on points 1-3 to the list and concluded
>>     that the research group process has been followed imperfectly. I
>>     share this conclusion.
>>
>>     Dragonfly discussions started in December 2011.  David's timeline
>>     begins in October 2012, skipping:
>>     * The early critical feedback which Kevin ignored [1]
>>     * Kevin's "nitpicking detail" which breaks the protocol's security
>>     [2]
>>     * Kevin's cheerleading for a protocol whose use cases and
>>     alternatives he made no effort to understand [3]
>>     [1]
>>     [3]http://www.ietf.org/mail-archive/web/cfrg/current/msg03046.html
>>     http://www.ietf.org/mail-archive/web/cfrg/current/msg03052.html
>>     http://www.ietf.org/proceedings/83/minutes/minutes-83-cfrg.txt
>>     [2]
>>     http://www.ietf.org/mail-archive/web/cfrg/current/msg03047.html
>>     [3]
>>     http://www.ietf.org/mail-archive/web/cfrg/current/msg03047.html
>>     http://www.ietf.org/proceedings/84/minutes/minutes-84-tls
>>     [...]
>>
>>     So unlike the title "co-chair" might imply, and unlike in many other
>>     organizations, IRTF co-chairs are little more than group
>>     secretaries.
>>
>>     The chair is far more than a "group secretary".  As RFC 2014 section
>>     5.3 states:
>>     """
>>     The Research Group Chair is concerned with making forward progress
>>     in
>>     the areas under investigation, and has wide discretion in the
>>     conduct
>>     of Research Group business.  [...] The Chair has ultimate
>>     responsibility
>>     for ensuring that a Research Group achieves forward progress.
>>     """
>>     _______________________________________________
>>     Cfrg mailing list
>>     Cfrg@irtf.org
>>     http://www.irtf.org/mailman/listinfo/cfrg
>>     .
>>
>>     _______________________________________________
>>     Cfrg mailing list
>>     [4]Cfrg@irtf.org
>>     http://www.irtf.org/mailman/listinfo/cfrg
>>
>>     _______________________________________________
>>     Cfrg mailing list
>>     [5]Cfrg@irtf.org
>>     http://www.irtf.org/mailman/listinfo/cfrg
>>
>> References
>>
>>   1. mailto:adam@cypherspace.org
>>   2. mailto:lars@netapp.com
>>   3. http://www.ietf.org/mail-archive/web/cfrg/current/msg03046.html
>>   4. mailto:Cfrg@irtf.org
>>   5. mailto:Cfrg@irtf.org
> 
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> http://www.irtf.org/mailman/listinfo/cfrg
> 
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg