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

[Trevor Perrin <[e-mail]>]

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.


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