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

Watson Ladd <watsonbladd@gmail.com> Tue, 04 February 2014 01:08 UTC

Return-Path: <watsonbladd@gmail.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 64AFD1A02D2 for <cfrg@ietfa.amsl.com>; Mon, 3 Feb 2014 17:08:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 uWK-ElrkQRRu for <cfrg@ietfa.amsl.com>; Mon, 3 Feb 2014 17:08:45 -0800 (PST)
Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) by ietfa.amsl.com (Postfix) with ESMTP id 919BD1A02D0 for <cfrg@ietf.org>; Mon, 3 Feb 2014 17:08:45 -0800 (PST)
Received: by mail-yk0-f178.google.com with SMTP id 79so43972718ykr.9 for <cfrg@ietf.org>; Mon, 03 Feb 2014 17:08:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XM5huAsX2zmwPllULMoBR9PtucFDSC2LuZxIb8AC1po=; b=S4k3MCdDiNursgViOCaLgUEOLL+25azxKnnmaCZNgVE5+XHkitTSIEyoEJiWino/v7 vNXFAsnHjEHv8ca10eNgc52+1BL54EP89blRMq2szLjSTf4wT8WWfM8w2EWBxQqk7hH4 3jv8KwtpaPODyuZu4uCws44ByXsXvkJ3gFHAnrRcODrJ88KVgvKVCcjdPY6V/p/r4N0M 4KxFFzNyS8hEyVFa2eirLI4A1V/lTAdoRpTNJirKwB/jIk/wsOvxTH6aYnEjLuBmObaC Tcf4xrDgAFpJAG71ImdW35iwbPtTg6NwkD+g+bz5BsttVvZkSYlbvlItdDye00UUi54w FzpA==
MIME-Version: 1.0
X-Received: by 10.236.74.73 with SMTP id w49mr3820878yhd.87.1391476125243; Mon, 03 Feb 2014 17:08:45 -0800 (PST)
Received: by 10.170.126.76 with HTTP; Mon, 3 Feb 2014 17:08:45 -0800 (PST)
Received: by 10.170.126.76 with HTTP; Mon, 3 Feb 2014 17:08:45 -0800 (PST)
In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D018B81B7DE5@SC-VEXCH2.marvell.com>
References: <20140203192451.6268.76511.idtracker@ietfa.amsl.com> <7af2f9df96e5867d493c614806235363.squirrel@www.trepanning.net> <CACsn0cm1f-P95je5AbEbZ02Ut3+HM7Hx28P6j46TqE-=06eZDg@mail.gmail.com> <52F00EF3.3040505@cisco.com> <CACsn0c=zS5GKex3eF_hKgTsL1kH=TiBi3iAP9oMrJ9hDQcT4Gw@mail.gmail.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B81B7DE5@SC-VEXCH2.marvell.com>
Date: Mon, 3 Feb 2014 17:08:45 -0800
Message-ID: <CACsn0cn0TaHsDkyN2ewOorxxBzXivCg=QGR-ZnBiC3nJhvhpRg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Paul Lambert <paul@marvell.com>
Content-Type: multipart/alternative; boundary=20cf3005155228a21204f18a48f5
Cc: cfrg@ietf.org, David McGrew <mcgrew@cisco.com>
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-dragonfly-03.txt
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: Tue, 04 Feb 2014 01:08:48 -0000

On Feb 3, 2014 4:43 PM, "Paul Lambert" <paul@marvell.com> wrote:
>
>
>
> >From: Cfrg [mailto:cfrg-bounces@irtf.org] 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:cfrg-bounces@irtf.org] On Behalf Of Watson Ladd
> Sent: Monday, February 03, 2014 2:11 PM
> To: David McGrew
> Cc: cfrg@ietf.org
> Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-dragonfly-03.txt
>
>
>
>
> On Feb 3, 2014 1:49 PM, "David McGrew" <mcgrew@cisco.com> wrote:
> >
> > On 02/03/2014 02:47 PM, Watson Ladd wrote:
> >>
> >>
> >> On Feb 3, 2014 11:27 AM, "Dan Harkins" <dharkins@lounge.org> 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