Re: [Cfrg] 40 bit loop and DragonFly

"Dan Harkins" <> Tue, 07 January 2014 08:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CE14A1AE48D for <>; Tue, 7 Jan 2014 00:36:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PaQSI5ACUg1X for <>; Tue, 7 Jan 2014 00:36:31 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id EAE3A1AD687 for <>; Tue, 7 Jan 2014 00:36:30 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 15C9810224008; Tue, 7 Jan 2014 00:36:17 -0800 (PST)
Received: from (SquirrelMail authenticated user by with HTTP; Tue, 7 Jan 2014 00:36:17 -0800 (PST)
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <>
Date: Tue, 7 Jan 2014 00:36:17 -0800 (PST)
From: "Dan Harkins" <>
To: "Trevor Perrin" <>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "" <>, "Scott Fluhrer \" <>"
Subject: Re: [Cfrg] 40 bit loop and DragonFly
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Jan 2014 08:36:33 -0000

  Hi Trevor,

  I guess it was just an idle threat then for you to say you would "give
up participating in IETF/IRTF any further" if Kevin was endorsed through
an open process (note: he actually was, and that decision has been
confirmed by the IRTF chair). Oh wellÂ….

On Mon, January 6, 2014 6:02 pm, Trevor Perrin wrote:
> On Mon, Jan 6, 2014 at 9:18 AM, Watson Ladd <> wrote:
>> On Mon, Jan 6, 2014 at 8:46 AM, Igoe, Kevin M. <> wrote:
>>> I believe there aren't any insurmountable issues associated
>>> with DragonFly, but that doesn't mean Dan and the RG don't
>>> have some work to do.
> [...]
>> Why are we still trying to fix Dragonfly? We've got alternatives that
>> don't have the
>> significant theoretical issues, don't have the implementation issues,
>> don't have the IPR issues
>> (pith and marrow makes me think Dragonfly is covered by SPEKE patent),
>> and have been
>> vetted far more extensively.
> I share Watson's incredulity that Kevin expects further work on
> Dragonfly.  As Watson states, there are better alternatives (SPAKE2,
> J-PAKE, SRP, AugPAKE, and Elligator-based variants).
> Dan insists that he wants a balanced EC PAKE without patents, so let's
> talk about SPAKE2 and J-PAKE.  Both have been around for years, have
> formal security analysis, and are easily implemented without
> side-channels.
> Kevin and Dan: please explain why you prefer Dragonfly to these protocols.

  Where did you divine Kevin's preferences from? I have not heard
or read any statements from him that he prefers dragonfly as a PAKE
over any other protocol.

  I think SPAKE2 and j-PAKE are great. But for the uses I'm interested in
right now they are not the best choice. I'm looking for something to
protect an EST exchange where the group used for the PAKE is the same
as the group in which the key-to-be-certified was generated in, and I'm
also looking for something also to allow for small, constrained devices
in a home network setting to be provisioned by people with no security
clue so they can securely connect to a local server-- this means ECC
and it means as simple and idiot-proof a configuration as possible.

  SPAKE2 requires establishment of additional elements in the group that
are assigned to the players. This increases provisioning cost and requires
a certain amount of security clue on the part of the person doing the
provisioning. Dragonfly does not; just configure a simple password on each
end and voila. In addition, SPAKE2 cannot support different groups on the
fly so it won't work with the EST need. SPAKE2 does not work for either of
my two primary uses of Dragonfly.

  J-PAKE does not fit into TLS very well. It has an additional round of
message exchanging. Dragonfly fits in perfectly, key establishment
is done entirely in the client/server key exchange messages and
key confirmation fits into the finished message.

  But even if those were not the case and J-PAKE and/or SPAKE2
were acceptable, it's because there are no alternatives ready RIGHT
NOW. As I have explained numerous times to you, this is already late.
EST was already published and implementations exist. The need for a
certificate-less TLS cipher suite that supports ECC and does not bind
a single group to a password is already several months past due.

  Also, I have stated to you earlier that I think EKE with elligator curves
would be perfect. But such a draft doesn't exist. Even if you had a -00
draft written today we're still looking at 2+ years before it's published
as an RFC. So that doesn't work.

  Of course, you are more than welcome to write a draft specifying
any other kind of PAKE you want. You have previously stated that
you see no need for another PAKE in TLS so doing so would be,
according to you, a pointless endeavor. But, as we have seen, your
statements (e.g. "I will give up participating in IETF/IRTF") seem to
be made primarily for effect. So hopefully your statement against
any other PAKEs in TLS besides SRP was similarly made just for
effect and you will be advancing a PAKE draft really soon now.

  I await your draft of J-PAKE or SPAKE2 or anything else you think
is more appropriate. But, unfortunately, it is not of any use to me
right now.