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

[David McGrew <[e-mail]>]

Hi Trevor,

On 01/03/2014 09:43 PM, Trevor Perrin wrote:
> 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.

It would be great to have an ambassador, and that person need not be a 
chair.

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

Agreed.  Unfortunately, I will not be able to attend due to other 
travel.  If there is someone in the RG who can attend, it would be great 
to hear a report from them on topics that they think the list should 
know about.   (An aside: I'd like to hear or read about /Provable 
security of advanced properties of TLS and SSH/, which I would guess is 
similar http://eprint.iacr.org/2013/813.pdf) Also, if there is an 
opportunity to present a plug for CFRG at the event, say during a rump 
session, I offer to help to prepare a short presentation on CFRG to 
anyone willing to give it.

I think it would be good to have an actual CFRG meeting adjunct to an 
IACR venue, such as Crypto in Santa Barbara.   Probably there are not 
many people who regularly attend both the IETF and crypto conferences, 
but I think that such a meeting would help to build a stronger online 
community, if nothing else.

thanks,

David

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