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

["Dan Harkins" <[e-mail]>]

  (trimming the cc list. Trevor, you should really read what people
write and honor their requests)

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

  Yes, that would've been a good meeting to discuss it at. Or you
could've brought anything up on the list over the past couple of
years.

  As far as the _other_ discussion is concerned, the one that prompted
your starting of this thread. It has been shown that the process you
and your twitter followers are complaining about was open and
transparent, contra your mischaracterizations of it.

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

  And as a member of the "crypto practice community" I agree with David.
The issue that Jonathan Katz raised concerned the inability to prove the
protocol secure in the random oracle model. The reason is that in that
model the adversary has certain capabilities, like reveal(). The problem is
this:

  1. assume there is no key confirmation step in the protocol
  2. adversary as man-in-the-middle adds 1 to Bob's scalar
  3. adversary issues reveal() query to both Alice and Bob to
      obtain secrets
  4. adversary does off-line dictionary attack.

Now, this is indeed a problem with proving the protocol secure in the
random oracle model but it is not attack against dragonfly (or TLS-pwd).
That is because if an adversary has that much control over BOTH sides
of a TLS connection then all bets are off and the ability to do an off-line
dictionary attack after launching a man-in-the-middle attack against
entities it controls is the least of your worries. In addition, there is key
confirmation in the protocol and it does foil this attack. So in the "crypto
practice community" this is not viewed as an attack.

  The other issues Dr. Katz raised were:

  1. don't use the session key as a key confirmation key. A good
      suggestion but I didn't.
  2. validate the received elements. Good suggestion, which resulted
      in a change to the draft.

  So there is no "bluster". There was not a repeated raising of any
issues. There's just a continued (intentional?) misunderstanding by you
of what happened, what was said, and what it meant.

> Seems like CFRG could use more outreach to the cryptography community
> and less to the intelligence community.

  And it could do with less of another community too….

  Dan.