Re: [Cfrg] PAKEs in general (was; Re: draft-irtf-cfrg-dragonfly document status)

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

On Thu, October 9, 2014 1:53 pm, Yoav Nir wrote:
>
> On Oct 9, 2014, at 7:55 PM, Paul Lambert <[e-mail]> wrote:
>
>>>
>>> I'll just note that there were also voices (incl. mine) saying:
>>> "I really don't care about work on PAKEs. Seems like a waste of
>>> time to me. But go ahead and spend time on that if you wish."
>>
>> +1 mostly.
>>
>> Shared passwords are architecturally problematic.  They are
>> more useable ways to authenticate.
>
> I wish I had a dollar for every time someone said that in the last 20
> years…

  Me too.

  If I got a dollar every time authentication on the Internet involved
a password and I had to pay a dollar every time authentication on
the Internet did not, I would be a billionaire many times over.

>> The Œmostly' is that the Dragonfly draft should be published
>> so it can be used a little better in a couple of specific
>> environments where it is already being wired into systems.
>> Specifically, IEEE 802.11 has the SAE protocol which uses
>> the Dragonfly exchange for mesh networks.
>
> That’s the part I don’t understand. Since the first revision of this
> document, the group made some suggestions for improvement that have been
> incorporated into the draft.
>
> We also have Dan’t message ([1]) describing differences between the 802.11
> version and this draft, including attacks that work on earlier versions of
> this draft that don’t work on the 802.11 version.

  I think you misunderstood my email. This draft was supposed to be a
generic specification for the key exchange underlying an authentication
method in several other protocols. So the point of my mail was to explain
that the attacks mentioned on this list-- the small subgroup attack and
the reflection attack-- are not new, they were known and addressed in the
other specifications, but in my haste to get the I-D out (if you look at the
Acknowledgements section you'll see that it's actually the xml2rfc
boilerplate, it was that sloppy) I did not address them in the generic
protocol description.

  After these omissions were pointed out the appropriate checks were
added to subsequent versions of this draft.

> Given all that, I don’t think this is a document that describes existing
> practice, in the same vein as an SSLv3 document or a PKCS#12 document.
> This is a document describing an entirely new PAKE, so it should be judged
> as such.

  Actually, it now closer to existing practice. It is a generic description
of which there are other specific instantiations of it. There were no
comment resolutions that changed the underlying protocol and to say
it is an "entirely new PAKE" is just wrong.

  regards,

  Dan.

> Yoav
> [1] http://www.ietf.org/mail-archive/web/cfrg/current/msg05210.html
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg
>