Re: [Cfrg] I-D Action: draft-irtf-cfrg-dragonfly-03.txt

[Watson Ladd <[e-mail]>]

On Feb 3, 2014 4:43 PM, "Paul Lambert" <[e-mail]> wrote:
>
>
>
> >From: Cfrg [mailto:[e-mail]] On Behalf Of Watson Ladd
> >Sent: Monday, February 03, 2014 2:11 PM
>
> >Sure: "Despite significant efforts, no variant of this protocol has been
proved
>
> >secure even in the random oracle model with nonstandard assumptions.
>
>
>
> A proof might be desirable but should not block the use of a proposed
protocol.
>
> For example there is no adequate proof that integer factorization is
“secure”.
>
> This is not a reason to stop using RSA based algorithms.  The lack of
> a  complete security proof for draft-irtf-cfrg-dragonfly-03.txt should not
> stop it’s use (in fact it’s already in other standards that would benefit
>
> from the analysis and improvements of this group).

But there is a proof that OAEP has a reduction to RSA security. PKCS 1.5
had no proof, and got broken a few times. RSA has been intensively studied
for decades, dragonfly hasn't. Slight variants of RSA (Rabin-Williams) are
provably reducible to factoring, an extensively studied problem for
centuries.

Kerberos is the poster child for provable security. v4 had a flaw that went
undiscovered until efforts to prove security were made. In retrospect the
flaw is obvious.

Ignoring the 40 years of cryptography in favor of "looks secure" is
malpractice. No structural engineer would ever build a bridge ignoring the
science of mechanics.

Protocols should use augpake or jpake instead.
>
>
>
> I would like to reverse the question.
>
>
>
> Watson, in your technical analysis of the
>
> protocol in its current form (draft-irtf-cfrg-dragonfly-03.txt),
>
> can you identify any exploitable security flaw specific to
>
> the protocol?

Yes: an algorithm exists that guesses passwords in time 2^40. I can't
exhibit it, but it exists. JPAKE doesn't have this issue.
>l
>
>
>
>
>
>
> Paul
>
>
>
>
>
> From: Cfrg [mailto:[e-mail]] On Behalf Of Watson Ladd
> Sent: Monday, February 03, 2014 2:11 PM
> To: David McGrew
> Cc: [e-mail]
> Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-dragonfly-03.txt
>
>
>
>
> On Feb 3, 2014 1:49 PM, "David McGrew" <[e-mail]> wrote:
> >
> > On 02/03/2014 02:47 PM, Watson Ladd wrote:
> >>
> >>
> >> On Feb 3, 2014 11:27 AM, "Dan Harkins" <[e-mail]> wrote:
> >> >
> >> >
> >> >   Hello,
> >> >
> >> >   I updated the dragonfly draft to incorporate the comments received
> >> > from Rene and Scott. Please take a look.
> >> >
> >>
> >> It still doesn't compare favorably to JPAKE or SPAKE2. TLS has shown
less then zero interest in it. No reduction or evidence for claims made is
forthcoming. The draft excludes curves with uniform hashing to points.
> >>
> >> Why is this specific PAKE a work item and not the other alternatives?
> >
> >
> > You mean like draft-irtf-cfrg-augpake-00?
> >
> > Drafts are taken up when someone is willing to write one, and there are
sufficiently many other people that are interested.
> >
> >> Was this a joke for groundhog day?
> >
> >
> > The sarcasm is not helpful.  Let's stick to a technical discussion.
> >
> > This draft most certainly should be reviewed, since security concerns
were raised regarding earlier versions of the draft, especially regarding
implementation guidance and timing channels.
> >
> > The process by which CFRG drafts can become RFCs is described in
http://wiki.tools.ietf.org/html/rfc5743#section-2.1   Note that there is a
paragraph in the RFC that describes the relationship of that work to the
research group.    This mechanism enables the sentiment of the RG to be
captured in the RFC.
> >
> > Let me ask: can you suggest text for the security considerations
section of this draft that captures your concerns regarding the lack of
reduction and uniform hashing?
>
> Sure: "Despite significant efforts, no variant of this protocol has been
proved secure even in the random oracle model with nonstandard assumptions.
None of the security claims are sensible in any accepted formalization of
security protocols. Significant dissent in the WG existed with publication
due to the lack of any more than superficial analysis. No Internet protocol
should use this PAKE when alternatives exist." Just about sums it up.
> >
> > David