Re: [Cfrg] 40 bit loop and DragonFly

[Watson Ladd <[e-mail]>]

On Tue, Jan 7, 2014 at 12:36 AM, Dan Harkins <[e-mail]> wrote:
>
>   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 <[e-mail]> wrote:
>>> On Mon, Jan 6, 2014 at 8:46 AM, Igoe, Kevin M. <[e-mail]> 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.

Why "the same?". Why not more secure?

128-bits can be represented as 26 elements of a 32 character alphabet.
Divide it into 4 groups of 6, and you have something that a major consumer
product has people type in.

PAKE is likely to be less secure than this: it also will permit a break
in one of the devices to be extended to a break in all of them.

You can also use TOFU, or a distance-bounded initial connection. Some
of these are significantly better from a UI perspective then passwords.

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

Why can't M&N be global: one for the client, one for the server?
I agree with you this means picking one group, but M-511 exists.
AGL has this working for Pond.

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

Why do you care how well it fits? If we can shoehorn it in, it will work.

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

I think you are ignoring the fact that the TLS WG will not consider dragonfly
for the foreseeable future. You are also ignoring the fact that the 2+ years
are primarily a function of very avoidable process delays: a last call takes
4 weeks. Try writing up SPAKE2, submit it, and see how long it takes to
get a good standard through.

Dragonfly has unfixable flaws relating to its provable security that will
prevent me from endorsing it for any protocol, ever. I am not alone in
thinking that we should expect more from the protocols we standardize.

Also, is this implemented in OpenSSL or NSS or PolarSSL? Not yet.
So the vaunted readiness is really overstated. Granted, SPAKE2 would
take a while, but we already have an implementation to use living at
https://github.com/agl/panda.

Lastly, if this was needed for EST to work, they should have noticed
this dependency, and tackled it head on. That they punted on
this problem does not mean it is our responsibility to fix it.

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

Dan, if this is such a need, why haven't you used TLS-SRP while
waiting for something better?
Even if this is standardized, you still need the browser makers to follow suite.
Besides, you can also turn a paper into a draft: why you didn't do
this instead of come up
with Dragonfly n years ago is beyond me.

Of course, there are drafts for J-PAKE and AugPAKE sitting around, one for TLS.
I still haven't figured out why AugPAKE couldn't be used for the
example use case.

>
>   Dan.
>
>
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin