Re: [Cfrg] draft-irtf-cfrg-dragonfly document status
Watson Ladd <watsonbladd@gmail.com> Thu, 09 October 2014 01:22 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 B49E81A8895 for <cfrg@ietfa.amsl.com>; Wed, 8 Oct 2014 18:22:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_39=0.6, SPF_PASS=-0.001] autolearn=no
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 BmoSIhu6_3pR for <cfrg@ietfa.amsl.com>; Wed, 8 Oct 2014 18:22:30 -0700 (PDT)
Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6829F1A8891 for <cfrg@irtf.org>; Wed, 8 Oct 2014 18:22:30 -0700 (PDT)
Received: by mail-yk0-f173.google.com with SMTP id 200so132755ykr.32 for <cfrg@irtf.org>; Wed, 08 Oct 2014 18:22:29 -0700 (PDT)
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:content-transfer-encoding; bh=ZK3/x92c5ZoSd2LjjsCVIVCWIc8KXlqWlfZlJdZ9ewA=; b=emP2cmc3L9k11Sd6glNN6Fms8WLvv53USoDoh4rY1T3EGgWFivCkqbdkjrbA2eMeNU c12fOVd530Kv8EuS24hw9btVS+FZes0BkrXdSRfTu1e3bUIi88ZOqTPRygkCAzCalFkf vsJjxYWp4PX0/5MQb3u00rAePEtvohckuaWZM4swRSxIRY7BrQ0P6CMoHmbwfSNyGELv 1C+wRXg+mNg8ar0xtbp80ruK/qYQiMIrwjI03jZDO+tZokrWTBFgFwu7BfZwhjwbSlV+ O6+E0xiiQTP/RdARg09I/o+fNEH++NXsBOe+Mr22c70W+YWjxzP+9tDoozsRUIA2GSwI D55g==
MIME-Version: 1.0
X-Received: by 10.236.134.81 with SMTP id r57mr113150yhi.172.1412817749343; Wed, 08 Oct 2014 18:22:29 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Wed, 8 Oct 2014 18:22:29 -0700 (PDT)
In-Reply-To: <73d51db893a4b847db6d8eaae7f45cf5.squirrel@www.trepanning.net>
References: <54357A2A.2010800@isode.com> <CACsn0c=222g7HHpPh++noS3H1jEhawtQAdeA1WbPObN3wZr6jQ@mail.gmail.com> <D05AE162.50264%paul@marvell.com> <CACsn0ckGqUVeOeP17opaynVYm5E7RLJnF4=r20zBYMidBZzEKw@mail.gmail.com> <73d51db893a4b847db6d8eaae7f45cf5.squirrel@www.trepanning.net>
Date: Wed, 08 Oct 2014 18:22:29 -0700
Message-ID: <CACsn0c=vW1TS-zE1jmcRo3H6jPWgmGUF_DPUcGzV0Xo5N0ujPQ@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Dan Harkins <dharkins@lounge.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/ORc5df4ZDCaNvBkX-1WSranAPQ0
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] draft-irtf-cfrg-dragonfly document status
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: Thu, 09 Oct 2014 01:22:32 -0000
On Wed, Oct 8, 2014 at 4:40 PM, Dan Harkins <dharkins@lounge.org> wrote: > > Watson, > > On Wed, October 8, 2014 3:46 pm, Watson Ladd wrote: >> On Oct 8, 2014 3:26 PM, "Paul Lambert" <paul@marvell.com> wrote: >>>> >>>> On Oct 8, 2014 10:53 AM, "Alexey Melnikov" <alexey.melnikov@isode.com> >> wrote: >>>> > >>>> > Hi, >>>> > My apologies for taking so long on this. But I felt I needed to >>>> review >> mailing list discussions to make up my own mind on this topic. >>>> > >>>> > After reviewing mailing list discussions about this draft, I would >> like to do another RGLC on it. I've seen negative comments on the mailing >> list, but I've also seen some interest in this work and I am also aware >> that some variants of the algorithm are already implemented/deployed. >> Also, >> there were a couple of new revisions of the draft and it is not clear >> whether people who reported original problems are happy with how they got >> resolved. So I would like to see a bit more positive feedback on the >> latest >> version, in particular I would like to know if specific issues raised by >> earlier reviews are addressed in the latest version. >>> >>> This draft should be published as an RFC. There is considerable value >>> in >> having a published stable reference document. The market should be >> allowed to do the estimations of risk and value to field this protocol. >> >> Just as they did with RC4 and renegotiation? > > This has nothing to do with RC4 and renegotiation (I assume you mean > in TLS). I'm questioning the ability of market participants to evaluate cryptography. > >>> >>> Versions of the protocol have been adopted and fied. This protocol was >> first introduced into IEEE 802.11s in 2008. The base protocol exchange >> has >> also been adopted in the Wi-Fi Alliance. The protocol has been improved >> by the review in the cfrg and if published, the specification would >> positively impact the application of the protocol in other forums. >>> >>>> My comment (there is no security proof, and alternatives with better >> provable security) has been acknowledged to be unresolveable. >>> >>> Yes, this may be considered a negative point by some but not all. >>> While >> not a proof, the protocol has been analyzed: >>> Cryptanalysis of the Dragonfly Key Exchange Protocol >>> It was interested that the only issue mentioned was a small subgroup >> attack if the public key is not validated …. which it always should. >> >> This analysis ignores Rene Struik's timing attack, my reflection attack, >> and other comments incorporated into the draft. > > And I thanked Rene, you, and others for your comments and, as you note, > incorporated resolutions into the draft. Once again, thank you for helping > improve the draft. All of the comments have been resolved in -04. > > (I will note that the reflection attack you mentioned is not possible > in the IEEE 802.11 version of dragonfly, which predated your comment > and this draft by a few years, and neither was small subgroup attack > described by Clarke and Hao mentioned above. The -00 version of this > draft was rushed, take a look at the Acknowledgements in section 4 to > see just how bad, and I left some things out that I shouldn't have. All > this has all been addressed in -04). Why did the draft not track the IEEE 802.11 version? Also, as I remember from discussing this issue in the TLS WG, the CFRG draft version and the TLS draft version differed substantially, enough to make the reflection attack not work. (There were interactions with the rest of TLS that prevented it) While only tangentially relevant to the issue, this is the kind of issue which leads to all sorts of bugs in protocols that should be secure. It also is not clear how relevant the proposed draft will be > >>>> >>>> The draft authors knew this from the very beginning. >>>> >>>> I don't think we should approve a protocol that doesn't have a security >> proof, particularly given that we are going to work on alternatives. >>> >>> “… Going to work on …” is the issue. The draft under discussion >>> has been >> on IETF servers for 2 years. It has been used in other industry forums >> for >> four or five years. >> >> Plenty of alternatives have been put forward in those two years, including >> EKE+Elligator, SPAKE2, JPAKE, and SMP based solutions. The failure to >> advance these is inexplicable. > > Oh no, it's very easily explained. It's because no one has stepped forward > to actually write the I-Ds. You have stated on numerous occasions that these > should be written up but you have never actually taken on the task of > actually doing it. Please, write up a draft or four. Whether or not you do, > though, this really has nothing to do with the RGLC underway right now. JPAKE was described in a series of drafts that weren't made WG work items. I see no reason that the eventual disposition of SPAKE2, SMP, or EKE+Elligator drafts would be any different, and thus see no reason to write the drafts. > > If there was a security proof of dragonfly it would not be, nor should it > be, part of this draft. It would be a stand-alone paper. The complaint about > the lack of a security proof is really procedural and not technical as it is > not a comment on the draft that can be resolved by changing the draft. > The IRTF (and the IETF as well) has never put a security proof as a process > requirement for advancement of I-Ds. You may think it should but that > is an argument for a different place, not a RGLC. It could be resolved by opening the draft, deleting the contents, inserting contents describing a protocol with a security proof and referring to the proof published elsewhere, and submitting the new version, so clearly it is an issue with the contents of the draft. I think what you meant to say is it couldn't be resolved without substantially changing the protocol, which also isn't true: if the shared secret was a hash of all the messages, and the peer-scalars were removed, the result would be a secure PAKE with a security proof. But unfortunately it would be a patented one. There are plenty of drafts that have piled up in various nooks and crannies that never get adopted as WG items, despite requests from authors. I don't see why we need to publish this draft, and I don't see why we need to publish a draft for a protocol inferior to alternatives that have been well-studied and are well-regarded. The argument you are making seems to be that anything will get published, provided it's sufficiently polished, no matter how much better the alternatives are. Sincerely, Watson Ladd > > regards, > > Dan. > >>> >>> Yes, the cfrg should work as quickly as possible to make alternatives. >> Stopping the progression of this draft does not accelerate new work, but >> does prevent existing applications from utilizing a reviewed and improved >> specification. >> >> The nonexistence of this draft did not stop adoption in Wifi. By contrast >> advancing a number of PAKEs will kick the issue to WGs without the >> capacity >> to evaluate the issues. >> >>>> >>>> There is plenty of terrible crypto in IEEE standards >>> >>> … and IETF standards. Bringing in other good or bad protocols into >>> the >> discussion is irrelevant to the decision at hand. >>>> >>>> we don't issue drafts for because it is so terrible. >>> >>> Since when did the IETF mandate a security proof … There are >>> terrible >> protocols with proofs, so why does the lack of a proof made something >> ‘terrible’. >>> >>> Paul >>> >>> >>> >>>> To the extent our publication leads to use of dragonfly as opposed to >> known - good protocols, it's a problem. >>> >>> >>> >>> >>>> > >>>> > Considering how difficult previous Last Call on the document was, I >> would like to ask people to: >>>> > 1) keep in mind that CFRG chairs believe that the RG should work on >> PAKE requirements and after that on other PAKE proposals. This was >> suggested by our previous co-chair David McGrew: >>>> > http://www.ietf.org/mail-archive/web/cfrg/current/msg03723.html >>>> >>>> Why doesn't this apply to dragonfly, but only other proposals? >>>> >>>> > 2) be professional, in particular no ad hominem attacks >>>> > 3) be constructive. In particular if you would like a disclaimer >>>> being >> added to the document, please suggest specific text. >>>> > 4) simple statements of support for publishing the document or >> objection to publishing it are fine and encouraged. Sending them directly >> to RG chairs is fine. But please avoid saying "but what about PAKEXXX?", >> due to 1). >>>> > 5) unlike IETF, IRTF RGs are not required to reach rough consensus. >> However I would like to see us try. >>>> > >>>> > Best Regards, >>>> > Alexey, >>>> > on behalf of chairs. >>>> > >>>> > _______________________________________________ >>>> > Cfrg mailing list >>>> > Cfrg@irtf.org >>>> > http://www.irtf.org/mailman/listinfo/cfrg >>> >>> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg >> > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin
- [Cfrg] draft-irtf-cfrg-dragonfly document status Alexey Melnikov
- Re: [Cfrg] draft-irtf-cfrg-dragonfly document sta… Watson Ladd
- Re: [Cfrg] draft-irtf-cfrg-dragonfly document sta… Paul Lambert
- Re: [Cfrg] draft-irtf-cfrg-dragonfly document sta… Watson Ladd
- Re: [Cfrg] draft-irtf-cfrg-dragonfly document sta… Paul Lambert
- Re: [Cfrg] draft-irtf-cfrg-dragonfly document sta… Dan Harkins
- Re: [Cfrg] draft-irtf-cfrg-dragonfly document sta… Watson Ladd
- Re: [Cfrg] draft-irtf-cfrg-dragonfly document sta… Peter Gutmann
- Re: [Cfrg] draft-irtf-cfrg-dragonfly document sta… Dan Harkins
- Re: [Cfrg] draft-irtf-cfrg-dragonfly document sta… Schmidt
- [Cfrg] PAKEs in general (was; Re: draft-irtf-cfrg… Stephen Farrell
- Re: [Cfrg] draft-irtf-cfrg-dragonfly document sta… Watson Ladd
- Re: [Cfrg] PAKEs in general (was; Re: draft-irtf-… Paul Lambert
- Re: [Cfrg] PAKEs in general (was; Re: draft-irtf-… Andy Lutomirski
- Re: [Cfrg] PAKEs in general (was; Re: draft-irtf-… Mike Hamburg
- Re: [Cfrg] draft-irtf-cfrg-dragonfly document sta… Alexey Melnikov
- [Cfrg] JPAKE and a few other things (was Re: draf… Alexey Melnikov
- [Cfrg] Writing proposals as drafts first (was Re:… Alexey Melnikov
- [Cfrg] PAKE requirements Alexey Melnikov
- Re: [Cfrg] draft-irtf-cfrg-dragonfly document sta… Watson Ladd
- Re: [Cfrg] PAKEs in general (was; Re: draft-irtf-… Yoav Nir
- Re: [Cfrg] PAKEs in general (was; Re: draft-irtf-… Dan Harkins