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

[David McGrew <[e-mail]>]

Hi Trevor,

On 12/27/2013 10:56 AM, Trevor Perrin wrote:
> On Tue, Dec 24, 2013 at 9:57 AM, David McGrew <[e-mail]> 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.

I agree, more outreach to the theory community would be valuable. 
Perhaps you would be interested in helping with that effort?

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

I hope that you stay engaged with CFRG over the long term and help it do 
useful work.

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

I think we are in agreement here.

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

I think you are right.   I kind of like the idea of having a statement 
of purpose of CFRG that contributors need to agree to, but it would not 
be addressing any of the problems that people care most about.

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

I think that you are overestimating the power of a research group 
chair.  But I do think that trustworthyness and expertise are important.

>
>
>>>> [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?

I don't have the time right now to go back to the earlier version of the 
draft and check all of this, and I want to get back to you sooner rather 
than later.   So let me comment here as a chair, rather than a technical 
reviewer.  What would have been most useful is for this analysis to have 
been presented to the CFRG mail list during the discussion of timing 
attacks that initially took place on December 2012, or after Kevin put 
out a Last Call for comments on Dragonfly on April 4, 2013.   For 
perspective: Rene Struik's comments on that draft went out on Nov 29, 
and yous went out on Dec 10, over six months after the last call for 
comments.

David

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