Re: [Cfrg] Response to the request to remove CFRG co-chair
Trevor Perrin <trevp@trevp.net> Fri, 10 January 2014 03:35 UTC
Return-Path: <trevp@trevp.net>
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 060E91ADFFE for <cfrg@ietfa.amsl.com>; Thu, 9 Jan 2014 19:35:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.207
X-Spam-Level:
X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77] 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 Wg7wTkJSXd6D for <cfrg@ietfa.amsl.com>; Thu, 9 Jan 2014 19:35:40 -0800 (PST)
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by ietfa.amsl.com (Postfix) with ESMTP id D04F81ADFE3 for <cfrg@irtf.org>; Thu, 9 Jan 2014 19:35:39 -0800 (PST)
Received: by mail-wi0-f177.google.com with SMTP id cc10so4310695wib.16 for <cfrg@irtf.org>; Thu, 09 Jan 2014 19:35:29 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yoLZNwG18TfRIugS3RI/omK0P0/o9VVkjPmTRhMGVhA=; b=d7dzqeuPcu3D9NGeQuk7lePNrDH1JMFEpW8NdIs0aSSXFk0T7+dqdslp7PpCuxpbwg mL8Rp0Aqoszh1ZpzcWNFcuCHHNlRg2+euaMA41k1OE3PV2AzQcPv8TNvhaEp8zoydRiE by/ED8MXlyBYKiBtqizEahQb9vYnIqmGdIEx9NN9WOFTgBX9Y4iHLB/BeX1jrrZIxNqf CJdMVgDbhEfxV38jnPeNRaFUNc5mOZKtsZHbvKquy9TMpl902a4odqTf1FrZT2vakjyj TED9KMgB2M88lWes0BP8dibQf/+OLrj8ulWwY4f0Bxn8MzTYHTI5Xr2CB97BkhoC5D/T 2zZg==
X-Gm-Message-State: ALoCoQl42VLJXa5EwNyaJrpQVqlHnz3G6Ys0PbRS9hvISfH/BsfKIHkXKdsJirkv5njTb4Ev//nS
MIME-Version: 1.0
X-Received: by 10.180.108.162 with SMTP id hl2mr372921wib.56.1389324929618; Thu, 09 Jan 2014 19:35:29 -0800 (PST)
Received: by 10.216.214.134 with HTTP; Thu, 9 Jan 2014 19:35:29 -0800 (PST)
X-Originating-IP: [208.70.28.214]
In-Reply-To: <52CE7744.7010904@cs.tcd.ie>
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> <52CD7ACC.4060305@cs.tcd.ie> <CAGZ8ZG3ARN0AzPcRTKdnCJ0ndhxRUV6aVy2nrVWm-wGH20gsFA@mail.gmail.com> <52CE7744.7010904@cs.tcd.ie>
Date: Thu, 09 Jan 2014 19:35:29 -0800
Message-ID: <CAGZ8ZG3S-rtsu-Kgwkb_XVPbvS0HGzzsc6hwcs2xqeThHcbg5Q@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: Adam Back <adam@cypherspace.org>, "cfrg@irtf.org" <cfrg@irtf.org>, David McGrew <mcgrew@cisco.com>, 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: Fri, 10 Jan 2014 03:35:43 -0000
On Thu, Jan 9, 2014 at 2:17 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote: > > Hi Trevor, > > On 01/09/2014 02:46 AM, Trevor Perrin wrote: >> On Wed, Jan 8, 2014 at 8:20 AM, Stephen Farrell >> <stephen.farrell@cs.tcd.ie> 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 >> purges. > > Terrified, egregious, loyalty oaths and purges is just irritating > overblown rhetoric and wrong. Do you think such language helps > something or someone? It doesn't. However, the rest of you mail > deserves a response, so I'll skip over that. "Terrified" was too strong. But BULLRUN was 4 months ago. It's time for our leadership to summon their courage and take a stand. As for the rest - David McGrew indeed mused about "a statement of purpose of CFRG that contributors need to agree to". http://www.ietf.org/mail-archive/web/cfrg/current/msg03695.html And Lars indeed worried we'd have to "eliminate all individuals affiliated with the NSA". http://www.ietf.org/mail-archive/web/cfrg/current/msg03736.html I think these are implausible fears which our leadership seems more interested in spreading than explaining. > BTW, just to be clear, I'm not part of the decision process nor > the appeal process, which is why I feel free to respond. Others who > are in the appeal chain may well not, so please don't misinterpret > their silence. > >> 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. > > Yes. Appointment is not the same as firing though, at least IMO. > I figure its right for someone appointing someone to take many > informal factors into account, but its not the same firing someone. If those qualities are important at time of "hiring", they're important 2 years later. If the IRTF doesn't have a better policy for rotating the chair, then "firing" (your term) is how it has to be done. > I know that you don't agree that the only issue here is Kevin's > affiliation, but that is what I think, as I said before. > >> 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? > > That's probably true in general, and Lars I assume considered all > that as will the IAB. I'm ok with that process. > >>> 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? > > No, and I didn't say it was. Do machinations happen in an > organisation involving thousands of people like the IETF? > Of course they do. Analogous things happen in academia as > well of course. The point is not that its acceptable > behaviour (it isn't) but that our processes need to be > designed to counter it, while at the same time enabling > the sausage-making to happen. Yes, and countering an unacceptable conflict-of-interest in a leadership position by removing the individual from that position is an appropriate policy. > My point though was to question the assertion that the > NSA situation is new in this respect. > > I do think snowdonia is new in other respects and that > we need to respond to those. > >>> 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. > > Fair enough that you think that. I think it'd be wrong if > the firing is solely based on affiliation. So you would never remove a chair based on an affiliation that poses a conflict-of-interest? You also don't seem to care about competence or mismanagement. What would be grounds for replacing a chair, in your opinion? >> I disagree that this needs to be framed as "fire the person". That >> implies this is some exceptional and insulting process to inflict on >> someone. > > But it is that. Reading some of the comments on the ars articles > about this kerfuffle, the phrase "exceptional and insulting" does > seem accurate. I'm not saying that's your fault, but it has > happened. I don't think message board comments are relevant here. The IAB could frame a chair replacement however they want. I do think Kevin's removal should be a rebuke to the NSA. We should make a statement that weakening standards is unacceptable and damages their ability to work with us, and that there's been a loss of trust the NSA needs to repair. >> 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. > > There is not. That kind of thing has been discussed, and it is > generally a fine thing to rotate chairs now and then, but in a > volunteer organisation that's hard - chairing a contentious WG > can take 20% of your week and finding capable willing chairs is > hard. I don't think I've seen any credible proposal for term > limits for chairs in either the IETF nor IRTF. > >>>> 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? > > Once you start to recognise affiliation in the way that is implied > in the last part of your request, then you need processes that > deal with the organisations and not the individuals and that very > quickly tends to turn into a discussion about membership which > then also quickly turns into one about paid membership and voting. > You can believe me on this or not, but do bear in mind its far too > boring an argument to want to deal with all the ins and outs;-) In what way have I "implied" recognizing affiliation, beyond common sense? What new processes would we need to "deal with organizations"? Please explain. This is a major objection that's been raised to the request. You can't just handwave that we need to believe you, or that it's too "boring" to get into. If this is a serious objection it needs to be explained seriously. >>>> 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: >> >> http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html >> http://www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html?ref=us > > Well since those are NYT and I don't have a subscription I > can't follow those URLs:-) > > But I'm pretty sure I've seen that material already. Sorry, see the Pro Publica story (and memos): http://www.propublica.org/article/the-nsas-secret-campaign-to-crack-undermine-internet-encryption http://www.propublica.org/documents/item/784280-sigint-enabling-project http://www.propublica.org/documents/item/784284-bullrun-briefing-sheet-from-gchq.html And the Guardian story: http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security I'm sure you and most people have seen these. But if the shock has worn off for anyone they're worth revisiting. The Pro Publica article is almost (though not quite) identical with the NYT article. The Guardian article has additional information. The NYT memos have more commentary and annotations, which provide a good summary: http://www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html "Documents show that the N.S.A. has been waging a war against encryption using a battery of methods that include working with industry to weaken encryption standards, making design changes to cryptographic software, and pushing international encryption standards it knows it can break." "The N.S.A.'s Sigint Enabling Project is a $250 million-a-year program that works with Internet companies to weaken privacy by inserting back doors into encryption products." "One responsibility of the agency is to safeguard United States communications by promoting encryption standards, and the other is to break codes protecting foreign communications. Part of the Sigint Enabling Project's goal is to influence these standards — which are often used by American companies — and weaken them." >> 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. > > I don't think his speculations are convincing on this point, as > I said. Its not surprising that reasonable people differ on how > to interpret partial information like this though. Certainly this would be easier if there was more information. >>> 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. > > Yes. In the latter case, I assert that the motivation is far > more commonly "prioritising one's own set of requirements" and > not "wanting the Internet to work less well." Those aren't mutually exclusive. In fact, the needs of military "COMSEC" are probably different enough from public Internet crypto that simply prioritizing the former goes some way towards accomplishing the latter (as you note for PKI). And I would expect the mindset isn't "wanting the Internet to work less well", but simply "wanting the Internet to remain an easy target for collection". Kevin's main involvement with the IETF has been to "ensure various internet security protocols supported configurations which would be suitable for use in classified networks". http://www.ietf.org/mail-archive/web/cfrg/current/msg03644.html Nothing wrong with that. But does he care about widespread, strong crypto on the public Internet? Is he going to aggressively tackle end-to-end encrypted messaging; ubiquitous and strongly-authenticated HTTPS; or improving the deployment of TLS forward secrecy and better ciphers / curves? Those are real challenges this group could be contributing to. Do you want NSA at the helm? >> For example: It's interesting how NIST tends to standardize >> algorithms that work well in hardware but are tricky in software. > > That I think is something where we can make improvements all > right, without having to agree on whether or not the current > situation is a result of sabotage or not. I'm delighted to > see CFRG starting down that road (partly spurred by your > request I think). Other people have wondered about this, FWIW: https://www.imperialviolet.org/2012/10/21/nist.html http://www.ietf.org/mail-archive/web/cfrg/current/msg03599.html >> And >> how DoD's steering of PKI worked for DoD, I suppose, but has not >> resulted in working key management for the Internet. > > Actually, I'd argue that someone wanting pervasive monitoring > would be more likely to prefer that a DoD style PKI had been > widely deployed in the Internet, so I really don't think that > the NSA-driven sabotage argument holds water there. That's on > the basis that if everyone had to go to a CA to do stuff then > it'd be easier to track everyone and also to get at their long > term decryption keys, e.g. because they'd often be centrally > generated for mobility reasons. Someone wanting pervasive monitoring would prefer plaintext. It's already easy to track everyone. But the more I think about it, the more interesting your above observation is: >> 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. Some military gear is designed to be hard to use by outsiders - you can't load keys into comm gear, things disable themselves, etc. Maybe that strategy applies at a higher level, too? Maybe we're the outsiders. NSA is here participating so we build things for them. But do we trust them to build things for us? Trevor
- [Cfrg] Response to the request to remove CFRG co-… Eggert, Lars
- Re: [Cfrg] Response to the request to remove CFRG… Alyssa Rowan
- Re: [Cfrg] Response to the request to remove CFRG… Trevor Perrin
- Re: [Cfrg] Response to the request to remove CFRG… Adam Back
- Re: [Cfrg] Response to the request to remove CFRG… Greg Rose
- Re: [Cfrg] [IAB] Response to the request to remov… Trevor Perrin
- Re: [Cfrg] Response to the request to remove CFRG… David McGrew
- Re: [Cfrg] Response to the request to remove CFRG… Adam Back
- Re: [Cfrg] Response to the request to remove CFRG… John Viega
- Re: [Cfrg] Response to the request to remove CFRG… Watson Ladd
- Re: [Cfrg] Response to the request to remove CFRG… Adam Back
- Re: [Cfrg] Response to the request to remove CFRG… Stephen Farrell
- Re: [Cfrg] Response to the request to remove CFRG… Trevor Perrin
- Re: [Cfrg] Response to the request to remove CFRG… Stephen Farrell
- Re: [Cfrg] Response to the request to remove CFRG… Trevor Perrin
- Re: [Cfrg] Response to the request to remove CFRG… Stephen Farrell
- Re: [Cfrg] Response to the request to remove CFRG… Watson Ladd
- Re: [Cfrg] Response to the request to remove CFRG… Dan Harkins
- Re: [Cfrg] Response to the request to remove CFRG… Trevor Perrin
- Re: [Cfrg] Response to the request to remove CFRG… Stephen Farrell
- Re: [Cfrg] [IAB] Response to the request to remov… Trevor Perrin