[Cfrg] Dragonfly Timeline, Observations, and Conclusions

David McGrew <mcgrew@cisco.com> Fri, 03 January 2014 22:45 UTC

Return-Path: <mcgrew@cisco.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7929E1AE001; Fri, 3 Jan 2014 14:45:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.14
X-Spam-Level:
X-Spam-Status: No, score=-13.14 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qz2AfGfVrqAs; Fri, 3 Jan 2014 14:45:45 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC2F1ADFFF; Fri, 3 Jan 2014 14:45:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9150; q=dns/txt; s=iport; t=1388789138; x=1389998738; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=WUpdAzpg67zWvsW7goQ5SNzpa6WsvHov54eEsidRm3U=; b=ksmdNMMYmUvFmoMM9oqrqW3RHfNDiw3Kz8jHnnV2BgQA/YG9o3i3KAeO LpcTJghTt8ra9kqTc1jqPmbGDRf00esABHqIr1n/QTxHakNkpd0rZELif nRhO3U1lxtlQ9xzNxpcAe3jK57uXf/icQ9DT1yg9Xh/NajkJ5eQ81UQ/w Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFADs9x1KtJXG+/2dsb2JhbABOCoMLujSBDBZ0giUBAiEbQDMKDAMHGAMCAQIBPQ4BDAgCEAeHacMqF44hCwYLAV0EDoQfAQOJQ45UhkWLT4NLHoE1
X-IronPort-AV: E=Sophos;i="4.95,600,1384300800"; d="scan'208";a="295182202"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 03 Jan 2014 22:45:19 +0000
Received: from [10.0.2.15] (rtp-mcgrew-8913.cisco.com [10.117.10.228]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s03MjDk9031507; Fri, 3 Jan 2014 22:45:14 GMT
Message-ID: <52C7392A.1050909@cisco.com>
Date: Fri, 03 Jan 2014 17:26:50 -0500
From: David McGrew <mcgrew@cisco.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9
MIME-Version: 1.0
To: "cfrg@irtf.org" <cfrg@irtf.org>, irtf-chair@irtf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Cfrg] Dragonfly Timeline, Observations, and Conclusions
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Jan 2014 22:45:48 -0000

Hi,

Lars, who chairs the IRTF, asked me to go over the events related to 
Dragonfly and let him know what I thought about the possibility of undue 
influence.   For the sake of transparency, I want to my observations and 
conclusions with you, starting out with a summary of the timeline.

I hope that in the new year we have an opportunity to re-focus on the 
task of improving security and privacy in the Internet through more & 
better crypto.

best regards,

David


---

CFRG Dragonfly Timeline, Observations, and Conclusions
David McGrew
January 3, 2014

Timeline

   Oct 15 2012. (Subject: Dragonfly Password Authenticated Key
   Exchange).  Kevin Igoe asks for review on dragonfly and for
   submissions of other algorithms.

   Oct 16 2012. (Subject: Cfrg Digest, Vol 90, Issue 2).  Jonathan Katz
   asks: is there a security proof?  Dan Harkins says no, and
   references an earlier discussion with Jonathan.

   Dec 13 2012.  (Subject: Status of DragonFly).  Kevin summarizes the
   status of Dragonfly, provides an analysis, and describes for the
   first time the importance of resisting timing attacks, and proposes
   a solution.  Scott Fluhrer points out problem with proposed
   solution, and suggests a fix.  Independently, Rene Struik points out
   a problem with proposed solution.  Kevin acknowledges the problems.

   Dec 17 2012.  (Subject: Status of DragonFly).  Kevin re-summarizes
   status, suggests adopting Scott's fix.  Dan says that the latest
   version of Dragonfly already does the equivalent of Scott's fix, and
   asks if it is sufficient.

   Dec 18 2012.  (Subject: Status of DragonFly).  Scott points out that
   the Dragonfly spec needs to be more clear on its use of the fix, and
   suggests computing the Legendre/Jacobi symbol instead of computing
   an actual square root.  Kevin does a simple calculation suggesting
   the number of iterations of the suggested fix are adequate.

   Feb 24 2013.  (Subject: I-D Action:
   draft-irtf-cfrg-dragonfly-01.txt).  New version of draft posted.

   Apr 04 2013. (Subject: Dragonfly) Kevin posts a request for comments
   and initiates Last Call.

   Jul 26 2013. (Subject: small editorial error in and question on
   draft-irtf-cfrg-dragonfly-01 (was: Re: CFRG meeting at IETF 87)).
   Rene points out small error and proposes a fix, and asks what
   motivated a design change.

   Jul 29 2013.  (Subject: small editorial error in and question on
   draft-irtf-cfrg-dragonfly-01 (was: Re: CFRG meeting at IETF 87)).
   Rene asks about motivation for the use of nonces and a potential
   side channel.

   Aug 27 2013.  (Subject: I-D Action:
   draft-irtf-cfrg-dragonfly-02.txt).  New version of draft posted.

   Nov 3-8 2013.  IETF 88 meeting in Vancouver.  Kevin reports to TLS
   WG chairs that CFRG did not find any problems with Dragonfly.

   Nov 29 2013.  (Subject: review of draft-irtf-dragonfly-02 (triggered
   by [TLS] Working Group Last Call for draft-ietf-tls-pwd)).  Rene
   provides a detailed review of the draft, finds several problems and
   suggests fixes.  His summary: "While the proposed protocol could
   probably be made to work, it would require more work to get there,
   including removal of security weaknesses".

   Nov 30 2013.  (Subject: review of draft-irtf-dragonfly-02 (triggered
   by [TLS] Working Group Last Call for draft-ietf-tls-pwd)).  Feng Hao
   provides a link to a published security analysis showing problems
   with some versions of Dragonfly.

   Dec 03 2013.  (Subject: review of draft-irtf-dragonfly-02 (triggered
   by [TLS] Working Group Last Call for draft-ietf-tls-pwd)).  Dan
   responds to many of Rene's points, and disagrees with many of his
   conclusions.

   Dec 03 2013.  (Subject: review of draft-irtf-dragonfly-02 (triggered
   by [TLS] Working Group Last Call for draft-ietf-tls-pwd)).  Watson
   Ladd says that there can be no security proof for Dragonfly.

   Dec 10 2013.  (Subject: Review of Dragonfly PAKE). Trevor Perrin
   reviews Dragonfly and concludes that it is inferior to other PAKE
   schemes.

   Dec 11 2013.  Dan challenges Trevor's conclusions, and Dan responds,
   over several message exchanges.



Observations:

   Trevor is right that there seems to be a timing channel in Dragonfly as
   it is specified in the current draft.

   Kevin was the first person to observe that resisting timing attacks
   should be a goal for the protocol.  It would be odd to blame him for
   endorsing a less-than-perfect description of how to achieve that goal.

   Kevin requested feedback on both Dragonfly and the comments provided
   on list many times.  This is what a Research Group chair should be
   doing, and it seems inconsistent with the claim that Kevin was
   trying to steer the protocol in a particular direction.   If he had 
wanted to
   influence the protocol without arousing suspicion, a far more effective
   way to have done that would have been to send private emails to Dan
   asking for changes to the draft.

   One of the considerations in Password Authenticated Key Exchange
   protocols (such as Dragonfly) is the desire to avoid patent
   infringement.  It is likely that some potential adopters of
   Dragonfly are motivated by that consideration, and they may feel
   that it trumps any consideration of provable security.

   There was no requirements analysis regarding PAKE protocols; it
   would have been useful to have surveyed the security, performance,
   and intellectual property status of PAKE protocols as a group.
   (Note that it is often difficult to get accurate public analysis on
   patent infringement, because business considerations discourage
   public statements on patent scope.)

   Over six months elapsed between the Last Call on
   draft-irtf-cfrg-dragonfly and the most substantial and most negative
   reviews on that protocol.  Those reviews followed the feedback that
   Kevin gave to the TLS WG.

   It is not clear what question CFRG was being asked regarding
   Dragonfly, "can you find a problem with it?" or "would you recommend
   it for use in TLS?"  The latter question would have been more
   appropriate.

   Once Dragonfly became a CFRG draft, the natural inclination of an RG
   chair is to ensure that the draft becomes useful.   Kevin was the chair
   managing Dragonfly, because his co-chair is lukewarm on the utility
   PAKE protocols in general.

   There is no formal record of either the TLS WG request to CFRG (I
   was in the TLS WG meeting when it was made, but I do not recall any
   specific well defined ask) or the CFRG statement to the TLS WG.

   Scott Fluhrer and Rene Struik both provided suggested multiple
   improvements to the Dragonfly protocol and specification.  This
   suggests that they did not oppose the protocol.  (This is in
   contrast to the suggestion that everyone besides Dan and Kevin were
   negative on Dragonfly.)

   An RG chair cannot be expected to fully vet all proposals made to
   the RG.  The main responsibility for the correctness of a CFRG draft
   should be the authors of that draft.  It may be the case that Kevin
   made or endorsed a suggestion on the list that would have reduced
   rather than improved security, but if true, it does not appear to be
   intentional.

   Kevin's use of an NSA email address is good for transparency, but it
   seems to be bad for communication, because it seems that he cannot
   access that email account when traveling or on vacation, and
   communication is slow.


Conclusions:

   The process was imperfect.  The TLS WG should have given CFRG a
   written request specifying what question they needed to be answered
   by CFRG.  The RG should have taken on the question only if it could
   have found a sufficient number of people who would commit in advance
   to review the work in a timely manner.  Finally, CFRG should have
   provided a response in writing.  In retrospect, a better response to
   the TLS WG would have been "The response to the Last Call was too
   weak, we can't give you an answer."

   It is essential that CFRG processes be transparent.

   CFRG chairs need to coordinate better to prevent communication lapses.

   The main challenge for CFRG, in taking on long-term tasks, is the
   engagement with a sufficient number of participants.  The protracted
   silence following the Last Call on Dragonfly shows this well. There
   is a risk that, in increasing the level of process, CFRG makes
   engagement more difficult.  When adding process, every attempt
   should be made to do it in a way that is accessible, inclusive, and
   encouraging to broad participation.

   CFRG should identify work that is compelling to its membership and
   is useful to the Internet community, and identify authors and
   reviewers to carry that work forward.  A call for new work should be
   issued, with the aim of addressing new concerns regarding crypto
   designs, goals, and implementation security.