[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.
- [Cfrg] Dragonfly Timeline, Observations, and Conc… David McGrew