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

[Trevor Perrin <[e-mail]>]

On Thu, Jan 2, 2014 at 12:53 PM, David McGrew <[e-mail]> wrote:
>>
>>> 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?

Sure, my advice:  There's a wealth of knowledge in academia that CFRG
is not tapping.  Having a CFRG co-chair who could serve as ambassador
to that community and a translator of its knowledge would be very
valuable.

I'd recommend talking to some of the academic cryptographers who've
engaged with TLS and CFRG (Jonathan Katz, Kenny Paterson, Douglas
Stebila, David Wagner, etc), and see where that leads you.

Also, this would be a good discussion to pursue at Real World Crypto
(NYC, shortly).


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

Rene brought up the sidechannel issue again in July 2013, with no response:

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

But there's a bigger picture:  Regardless of timing attacks, Dragonfly
is inferior to alternatives already standardized or found in the
literature.

This opinion was well-expressed on the TLS and CFRG mailing lists when
Dragonfly was proposed.  This opinion was probably shared by many more
people than expressed it (like me), and was never adequately
addressed.  By Dec 2012, I assume most people had tuned-out a
discussion about an non-useful protocol that was proceeding without
regard to group opinion.


Trevor