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

Trevor Perrin <trevp@trevp.net> Fri, 27 December 2013 15:56 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 060611AE207 for <cfrg@ietfa.amsl.com>; Fri, 27 Dec 2013 07:56:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.722
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xjhg0dRI9-PT for <cfrg@ietfa.amsl.com>; Fri, 27 Dec 2013 07:56:49 -0800 (PST)
Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id 020BA1AE20E for <cfrg@irtf.org>; Fri, 27 Dec 2013 07:56:48 -0800 (PST)
Received: by mail-wi0-f171.google.com with SMTP id bz8so14424312wib.10 for <cfrg@irtf.org>; Fri, 27 Dec 2013 07:56:43 -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=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 10.180.109.107 with SMTP id hr11mr32661492wib.56.1388159803692; Fri, 27 Dec 2013 07:56:43 -0800 (PST)
Received: by 10.216.214.134 with HTTP; Fri, 27 Dec 2013 07:56:43 -0800 (PST)
X-Originating-IP: [68.225.244.139]
In-Reply-To: <52B9CB13.9020500@cisco.com>
References: <CAGZ8ZG2f9QHX40RcB8aajWvEfG0Gh_uewu2Rq7bQGHYNx6cOmw@mail.gmail.com> <52B91820.9090706@cisco.com> <CAGZ8ZG02+o=Qm0gUQiVF9H_=wfn+wQt8ahY1ntLHNsELXbvtVg@mail.gmail.com> <52B9CB13.9020500@cisco.com>
Date: Fri, 27 Dec 2013 07:56:43 -0800
Message-ID: <CAGZ8ZG07QGL4mD1+XpDgm-5GHuhZEg2WRUvF20zRM_ZPNFLOUQ@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: David McGrew <mcgrew@cisco.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, irtf-chair@irtf.org
Subject: Re: [Cfrg] Requesting removal of 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, 27 Dec 2013 15:56:52 -0000

On Tue, Dec 24, 2013 at 9:57 AM, David McGrew <mcgrew@cisco.com>; 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
to?

http://www.ietf.org/proceedings/83/minutes/minutes-83-cfrg.txt


> 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.

http://www.ietf.org/mail-archive/web/cfrg/current/msg03053.html
http://www.ietf.org/mail-archive/web/cfrg/current/msg03216.html

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
ops.

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


Trevor