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

Trevor Perrin <> Fri, 27 December 2013 15:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 060611AE207 for <>; Fri, 27 Dec 2013 07:56:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.722
X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Xjhg0dRI9-PT for <>; Fri, 27 Dec 2013 07:56:49 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 020BA1AE20E for <>; Fri, 27 Dec 2013 07:56:48 -0800 (PST)
Received: by with SMTP id bz8so14424312wib.10 for <>; Fri, 27 Dec 2013 07:56:43 -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 :content-transfer-encoding; bh=H7L+2uxYqhXxovt/bCwYTsT11T5Bs1VfoS0ASZa0bS8=; b=S3vl1pnLudOlazMvNtbqRljRO0hLe/uu+Ak9ZO6po+roSmdAEvY80/H8o/if8mfWvW EgrO92jxpv9UGqH+bjfS17spkGr8vDllEhb084eDgEw3/KU/KztMqeebHnrVChgfEsNK r1vchX+Zbjx9JIUEfhR587Oi35gxRBIGi1yqs24SbVYV/l/NqKX0W4NpABEFA+lnrweC iTip3yhBAD0O23JtgS2YrBttlyVf11E09nwL8j6WvCuymmW/IgIaLs/b7Okup+0c6gvP axgv+BDHvyWS56QF/Bsyejc2RhG/pDNJQ9Z5y1ZGV/c4LMKzlvrEM9RghGSUSGTVODeL 9XEw==
X-Gm-Message-State: ALoCoQmKMSfS8R0BmSq31urgOTsuxCQA8pnfBj9do+mMl9nPOijkzp9D6k6eZMfaJCSZttm8gFze
MIME-Version: 1.0
X-Received: by with SMTP id hr11mr32661492wib.56.1388159803692; Fri, 27 Dec 2013 07:56:43 -0800 (PST)
Received: by with HTTP; Fri, 27 Dec 2013 07:56:43 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <>
Date: Fri, 27 Dec 2013 07:56:43 -0800
Message-ID: <>
From: Trevor Perrin <>
To: David McGrew <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>,
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: Fri, 27 Dec 2013 15:56:52 -0000

On Tue, Dec 24, 2013 at 9:57 AM, David McGrew <> wrote:
>>> As far as Kevin's
>>> competence goes, your complaint needs to be balanced against his
>>> contributions.
>> I've looked over his mailing list contributions.
>> Kevin seems unfamiliar with sidechannel attacks, RSA padding, provable
>> security, key agreement protocols, and consulting academic literature.
>>   I'm sure he's good at math, but I don't see the breadth of knowledge
>> I'd expect for his position.
>> His messages don't reflect a high standard of diligence.  He's made
>> significant mistakes with Dragonfly.  His tone reminds me of a bemused
>> hobbyist who doesn't care whether any of this is secure.
>> I believe there are people who could do a better job.
> I respectfully disagree with your characterization.   I would guess that if
> you could have been present for the discussion at the RG meeting, you might
> feel differently.

Which discussion?  The only substantial discussion of Dragonfly at a
CFRG meeting appears to be at IETF 83.  Is that what you're referring

> Let me make an aside about provable security. In the crypto practice
> community, it is often regarded as oversold.

As a member of the "crypto practice community" I disagree.  Key
agreement protocols are widely understood to be a tricky area where
formal analysis is crucial.  Dragonfly's lack of such analysis was a
red flag.  Jonathan Katz, a world-class cryptographer, raised the
issue repeatedly.  The CFRG chairs ignored him and endorsed Dan
Harkins' bluster.

Seems like CFRG could use more outreach to the cryptography community
and less to the intelligence community.

>> You seem to be arguing that intelligence agencies are the only people
>> who would propose someone for CFRG chair.
>> I'm not sure that's true.
> I agree that it is not true; it is an overstatement.  But it is a fact that
> intelligence agencies have a lot of the talent that will show up at a venue
> like this, and that those organizations are able to justify the cost of
> ongoing professional participation.

I see.  That's terrifying.

>> Perhaps CFRG should follow an actual
>> process for selecting its chairs.  Kevin or anyone else would be
>> welcome to participate.
> Do I understand you correctly to say that you would accept Kevin as a
> co-chair if he was selected through some sort of official process, other
> than affirmation by the RG?

If the IETF/IRTF community endorses Kevin through an open process I'd
give up participating in IETF/IRTF any further.  That's not
"acceptance", but you wouldn't have to listen to me any more.

>>> What about someone in the role
>>> of a document author or co-author? Would you ask that Sean Shen step down
>>> as
>>> co-author of draft-irtf-cfrg-cipher-catalog-01, for instance? I hope not,
>>> but these are important questions to consider.
>> No one proposed that.
> I didn't mean to suggest that you said that, but I did want to ask. If the
> IRTF decides to establish a policy that is based on an RG member's employer,
> as you are advocating, it would be best to establish the entire policy up
> front, rather than debate each case as it comes up.

I'm not advocating a formal policy.  I believe the selection (or
removal) of chairs involves weighing many factors, and is best handled
on a case-by-case basis.

> If we really did want to exclude people from intelligence agencies while not
> setting a formal policy to that effect, we could achieve that goal by
> crafting a policy that demands more transparency than an intelligence agency
> would be comfortable with.   For instance, the policy could require the
> publication of all of the contributor's publications, regardless of whether
> or not they have been classified, or it could require that the contributor
> sign a statement regarding transparency that their employer would never
> agree to.   But note that if we did this, it would not solve any problems,
> because an intelligence agency could always work through contractors or
> other people who are on their payroll, but do not admit to being on their
> payroll.

I think those are bad ideas which would not prevent sabotage and would
burden innocent contributors.

>>   For the CFRG chairs this has
>> included handling an important security flaw prior to public
>> disclosure [2].
> What do you mean by this?   Are you saying that the CFRG chairs mishandled
> the Lucky-13 disclosure?

No.  From what I can tell Kenny Paterson handled it well.

But amongst those defending Kevin, a major theme seems to be that
trustworthiness and expertise is not important for IETF/IRTF chairs
since they're presiding over an open process.

I disagree since chairs wield a great deal of power in the IETF/IRTF
process.  The "Lucky 13" disclosure highlights an additional duty
which has been entrusted to CFRG chairs and which is hard to audit.

>>> [IGOE_2] ends with the statement "Many thanks to Rene Struik and Scott
>>> Fluhrer for their insightful comments. Would anyone else on the list like
>>> to
>>> join in? We can’t learn from our mistakes until we realize we’ve made
>>> them."
>>> I have a hard time seeing this message as steering the RG in an
>>> unfruitful
>>> direction.
>> That's [IGOE_3].  See the paragraph preceding your quote.  "steering
>> the RG in an unfruitful direction" is exactly how I'd describe it.
> If I understand you, the paragraph is Kevin's summary of Scott's improvement
> to Dan's protocol.   To me, that paragraph, followed by the request for
> review, looks like an RG chair that is seeking to stimulate discussion.

That's a good description.  But so is your phrase "steering the RG in
an unfruitful direction".  Kevin's paragraph is below:

Scott Fluhrer proposed an elegant change to DragonFly that fixes this.
 In the EC case, replace
the while-loop with a for-loop, say “for t = 1,,,,40”.  On each pass
through this for-loop generate
a possible x- coorodinate as in DragonFly,  saving off the first x
value which corresponds to a
point on the curve.  The only thing that can go wrong here is doing
all 40-iterations without
finding a good x-coordinate.  This is quite unlikely to occur (~
10^-12), but when it does occur
it gives 40 bits of information about the password.  In some VERY high
volume applications it
might be prudent to choose a value larger than 40.

>>>> He also endorsed an ineffective attempt to avoid
>>>> timing attacks by adding extra iterations to one of the loops [IGOE_3,
>>>> IGOE_4].
>>> I think that by "ineffective attempt to avoid timing attacks" you are
>>> referring to your statement that "within each loop are conditional
>>> branches
>>> and Legendre symbol / square-root algorithms, which are hard to implement
>>> efficiently in constant time ([STRUIK], [ICART], [FIPS186-4])" from
>>> [REVIEW]. Is this right? There is a significant difference between "hard
>>> to
>>> implement" and "ineffective". The statement in [REVIEW] makes it sound
>>> like
>>> it is inconvenient for the implementer, while the statement in your email
>>> makes it sound as though it is impossible.
>> Not sure I understand this quibble.
> The important point here is that a Research Group chair reading [REVIEW]
> could get the impression that the proposed mitigation to timing attacks is
> "hard to implement" rather than "ineffective", in your opinion.

I'm still not sure what you're asking.  Let's just look at a crude
analysis of the "40-loops" countermeasure Kevin endorsed, comparing
CFRG draft-00 vs draft-01/draft-02.

Let's assume that modular square roots are calculated via modular
exponentiation, and that Legendre symbol calculations take less time.
Let's also ignore the variable time taken by a Legendre symbol
calculation and other conditional logic, and just count the number of

In draft-00, the hunt-and-peck loop in 3.2.1 performs Legendre symbol
calculations until it finds a square (probability ~1/2), at which
point a square root is performed.  So:
 - 1 modular exponentiation
 - Variable number of Legendre symbol calculations
   - geometric distribution with mean ~2, variance ~2

In draft-01 and draft-02, the hunt-and-peck loop continues until it
completes 40 loops, with a probability ~1/2 of performing a modular
exponentiation on each iteration.  So:
 - Variable number of modular exponentiations
   - binomial distribution with mean ~20, variance ~10
 - 40 Legendre symbol calculations

The 40-loops algorithm was intended to reduce timing variance but
instead increases it, and increases computation cost as well.  So I
think "ineffective" is a fair description.  Do you agree?

>>>> 4)  Kevin's NSA affiliation raises unpleasant but unavoidable
>>>> questions regarding these actions.  It's entirely possible these are
>>>> just mistakes by a novice chair who lacks experience in a particular
>>>> sort of protocol and is being pressured by IETF participants to
>>>> endorse something.
>>> Yes, I agree: It's entirely possible these are just mistakes by a novice
>>> chair who lacks experience in a particular sort of protocol and is being
>>> pressured by IETF participants to endorse something.
>> I think CFRG deserves a chair who would be informed enough to
>> understand these areas, and diligent enough not to make the technical
>> and process mistakes that Kevin did.
> Of course we need informed and diligent chairs.   But when we are
> establishing the criteria that we expect from the CFRG chairs, we need to
> keep in mind that the higher that we set the bar, the fewer the candidates
> that will be qualified and interested.   It would be wrong to set an
> expectation that each email that attempts to summarize the on-list
> discussion must be free from flaws, for instance.

Sure.  Crypto's hard.  Mistakes happen.  But I'm uncomfortable with
the volume of mistakes in Kevin's handling of Dragonfly:
 * Endorsing Dragonfly despite better alternatives in the literature
 * Twice suggesting a way of deriving the DH generator which makes the
protocol breakable
 * Endorsing an ineffective timing-attack countermeasure
 * Misrepresenting CFRG consensus to TLS WG