Re: [TLS] [Cfrg] [saag] Question regarding CFRG process
Sean Turner <TurnerS@ieca.com> Fri, 13 December 2013 15:54 UTC
Return-Path: <TurnerS@ieca.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A98431AE2C0 for <tls@ietfa.amsl.com>; Fri, 13 Dec 2013 07:54:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 luY5RTX2dP2M for <tls@ietfa.amsl.com>; Fri, 13 Dec 2013 07:54:26 -0800 (PST)
Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [64.5.38.13]) by ietfa.amsl.com (Postfix) with ESMTP id EF33B1ADBF7 for <tls@ietf.org>; Fri, 13 Dec 2013 07:54:25 -0800 (PST)
Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id AE3D7CBC6003; Fri, 13 Dec 2013 09:54:19 -0600 (CST)
Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway09.websitewelcome.com (Postfix) with ESMTP id 82FDFCBC5F85 for <tls@ietf.org>; Fri, 13 Dec 2013 09:54:19 -0600 (CST)
Received: from [96.231.219.103] (port=59166 helo=[192.168.1.5]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from <TurnerS@ieca.com>) id 1VrV4D-0000Ql-Jr; Fri, 13 Dec 2013 09:54:18 -0600
From: Sean Turner <TurnerS@ieca.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_04771388-67F5-48AB-8A62-F66AEEA0C686"; protocol="application/pkcs7-signature"; micalg="sha1"
Message-Id: <1D142D8E-2BBE-4BD2-B454-A07A7D31ECD1@ieca.com>
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Date: Fri, 13 Dec 2013 10:54:58 -0500
References: <CAGZ8ZG0qnon4CYUh+2t201aioU1sHVQT9_8CMoez_5yM=N-cCA@mail.gmail.com> <18138981706be6221b2d05187da48394.squirrel@www.trepanning.net> <CAGZ8ZG0_xiXqu9GGSLL1LUpUp26Gi1KX5FGiWbhw_5Bm_VLGaQ@mail.gmail.com>
To: cfrg@ietf.org, "tls@ietf.org" <tls@ietf.org>, saag@ietf.org
In-Reply-To: <CAGZ8ZG0_xiXqu9GGSLL1LUpUp26Gi1KX5FGiWbhw_5Bm_VLGaQ@mail.gmail.com>
X-Mailer: Apple Mail (2.1822)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator3286.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source-IP: 96.231.219.103
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: ([192.168.1.5]) [96.231.219.103]:59166
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 11
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Subject: Re: [TLS] [Cfrg] [saag] Question regarding CFRG process
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Dec 2013 15:54:29 -0000
All further responses to this thread need to be sent to the CFRG list not the TLS or SAAG list. spt On Dec 13, 2013, at 05:29, Trevor Perrin <trevp@trevp.net> wrote: > Dan, all, > > My message was directed at the CFRG chairs. I believe CFRG consensus > has been misrepresented regarding Dragonfly. > > I'd appreciate if the chairs would respond to this. > > > Regarding Dan's objections to my summary, I attempt to set the record > straight below. > > On Thu, Dec 12, 2013 at 5:58 PM, Dan Harkins <dharkins@lounge.org> wrote: >> >>> >>> Below is a summary of all CFRG discussion of Dragonfly. >>> >>> ===== >>> >>> Feb 2008 >>> - Dan Harkins proposes early Dragonfly to CFRG >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg02205.html >>> >>> - Scott Fluhrer breaks it >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg02206.html >> >> An event mentioned in the acknowledgments. Thank you Scott. >> His review and comments have been most helpful. >> >>> >>> Nov 2011 >>> - David McGrew appoints Kevin Igoe as CFRG co-chair >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03026.html >> >> Completely and utterly irrelevant. >> >>> Dec 2011 >>> - Dan Harkins asks CFRG to look at TLS-PWD, based on Dragonfly >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03044.html >>> >>> - Scott Fluhrer points out a problem >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03045.html >> >> A simple "sanity" check that the an ECC point is not "infinity". Again, >> a good comment. > > A crucial security check! > > >>> - Adam Back questions necessity of it, and lack of security >>> analysis >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03046.html >> >> He does no such thing. He notices that SRP is not mentioned in the >> draft. Quite true. And he asks what key exchange is being implemented >> because "its harder than it looks". Which is also quite true. > > I believe my description is accurate. > > >>> Jan 2012 >>> - Kevin Igoe's first email to CFRG: >>> "I really like this idea & can find no problems." >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03047.html >>> >>> - Jonathan Katz questions lack of security analysis, points out >>> problems >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03052.html >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03053.html >> >> Yes, helpful comments on the draft. The susceptibility to attack under >> the random oracle model is, in fact, mentioned in my slide deck when >> I presented to the CFRG in Paris at IETF 83. It is a highly contrived >> scenario and completely unlikely a real world protocol but it does raise >> the question of making a formal proof in that model. >> >> You should link to my slide deck in your next broadside. > > The random oracle model is a well-accepted methodology for analyzing > crypto protocols. > > The SPEKE protocol, which Dragonfly is based on, has some degree of > formal security proof in the random oracle model. If this proof does > not carry over to Dragonfly, that's a source of concern: > > https://eprint.iacr.org/2001/057.pdf > > >>> March 2012 >>> - At IETF 83 CFRG meeting, concerns are raised about: >>> - SPEKE patents >>> - necessity of a new scheme >>> - timing attacks >>> - non-augmented properties >>> http://www.ietf.org/proceedings/83/minutes/minutes-83-cfrg.txt >> >> Wow, you make it sound as if you were there. But you weren't. And >> your summary is not an accurate description of the meeting. > > I wasn't there. I believe my summary of the minutes is accurate. > > >> The >> sole mention in the minutes of SPEKE is from me. > > """ > Yoav Nir - there are no IPR? Really? Is it really enough different > from speke that they won't go after. > """ > > >> And the "concerns" >> are a recitation of comments received. That's how it works. You get >> comments and you resolve them. > > The "concerns" seem critical of the whole enterprise: > - "there are no IPR? Really?" > - "Why the not use what IEEE already had defined in P1363" > - "The difference between the scheme and SRP. Here both > sides need to have same secret." > - "could you scheme be made to be like SRP." > > This don't sound like CFRG approval. Yet after no significant further > discussion, at IETF 84 the CFRG chair claims: > > """ > Kevin Igoe: We approve of it, very clear and usable for general setting. > """ > > >>> May 2012 >>> - Kevin Igoe points out a limitation due to "hunting-and-pecking" >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03099.html >> >> He does no such thing. He just said that if the prime defining the >> curve p = 3 mod 4 that it's easier to compute the square root. > > Kevin recommended constraining Dragonfly to elliptic curves over those fields. > > This would eliminate Curve25519, and probably some other curves. > > >>> - Zhou Sujing and Dan have an exchange that's hard to follow. >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03115.html >>> >>> July 2012 >>> - At IETF 84 TLS meeting (CFRG does not meet): >>> - Kevin Igoe informs TLS WG, as the CFRG chair: >>> "We approve of it, very clear and usable for general setting." >>> http://www.ietf.org/proceedings/84/minutes/minutes-84-tls >> >> Also note the comment: "Tie Dragonfly into EST would be very useful" >> Yes, it would. > > I appreciate that the CFRG chairs are fond of Dragonfly. > > I'd like to understand where this approval comes from. > > >>> Oct 2012 >>> - Kevin Igoe calls CFRG attention to Dragonfly draft-00 >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03214.html >>> >>> - Jonathan Katz asks for a security proof - there is none >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03215.html >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03216.html >> >> Correct. There is no formal proof of security. See my slides from >> IETF 83. > > I read Jonathan's re-iteration of this point as expressing concern. > > >>> Dec 2012 >>> - Kevin Igoe calls CFRG attention to Dragonfly >>> - raises timing attack issue, proposes 2 fixes, including >>> rediscovery of Dan's original broken method (2008) >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03258.html >> >> This is further discussion on addressing a side channel attack. >> Your attempt to spin this as "broken" is somewhat desperate. > > Kevin's paragraph starting "A possible fix" is a rediscovery of the > older Dragonfly technique which Scott Fluhrer broke in 2008. > > >>> - Rene Struik points out the error in Kevin's proposal, and >>> the inefficiency of Dragonfly relative to SPEKE >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03259.html >> >> He does no such thing. His "Suppose A and B…" is a recitation of >> a version of SPEKE that does not hash the password into a group in >> the domain parameter set. It's neither here nor there with respect >> to dragonfly. > > Rene describes how Kevin's proposal leads to an attack, in the context > of SPEKE. I agree it would be clearer if he described it in the > context of Dragonfly, but the attack is more or less the same. > > >> He further goes on to suggest on a check for "point at >> infinity". Which is already part of dragonfly. >> >> There is no "error" noted and no "inefficiency" mentioned either. > > "...but requires two full scalar multiplications (rather than one > scalar multiplication as, e.g., SPEKE requires)." > > >>> - Scott Fluhrer points out the error in Kevin's proposal, and >>> proposes a flawed "mostly constant time" fix. Dan and Kevin >>> embrace it. >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03260.html >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03262.html >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03263.html >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03264.html >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03265.html >> >> As noted in the email thread, the described fix was added to the >> draft at the time. Your opinion on it being "flawed" has already been >> noted. > > If you've "noted" the significant sidechannel risk, and the simple > mitigation that's been suggested repeatedly (don't mix in the nonces), > why doesn't your latest TLS-PWD (as of hours ago) include that fix? > > >>> Feb 2013 >>> - draft-01 is uploaded with flawed sidechannel fix >>> - also quietly fixes security issue reported by Dylan Clarke >>> and Feng Hao >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03309.html >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03529.html >> >> This is a small sub-group attack possible if one does not check >> validity of received elements. All incarnations of dragonfly-- TLS-PWD, >> EAP-PWD and 802.11 already did this. It is entirely my fault that I left that >> crucial step out of the -00 version of the CFRG draft but it is hardly >> a flaw. > > I described it as a "security issue", which it is. > > >>> Apr 2013 >>> - Kevin Igoe mentions a last call for Dragonfly >>> "The design looks mature, it addresses a real need, and no one >>> has raised any issues." >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03383.html >> >> That's correct. You are included in that "no one". > > I don't think that's correct: > * The design remains immature, with a major problem regarding timing > side-channels. > * I doubt the design addresses an important need. There are many > better PAKEs, including SRP, which has been standardized and deployed > in TLS (RFC 5054). In any case, there is little demand for TLS PAKE. > * Many issues were raised. > > >>> May 2013 >>> - Feng Hao asks CFRG to consider J-PAKE (an alternative) >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03430.html >> >> Completely irrelevant. > > I think it's relevant that CFRG was made aware of other PAKEs, yet > made no effort to perform a comparative analysis, or question whether > Dragonfly was the best tool for the job. > > >>> July 2013 >>> - Rene Struik points out spec bugs, raises timing attack issue >>> again >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03486.html >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03489.html >> >> "Spec bugs", in other words typos. Yes, he brings up an issue that >> had previously been addressed. > > Rene doesn't seem to think the timing attack issue has been properly > addressed, and neither do I. > > >>> - IETF 87, CFRG meeting: >>> - "The author is working on a new (and hopefully final) draft" >>> http://www.ietf.org/proceedings/87/minutes/minutes-87-cfrg >> >> Sadly, it's not. I have to address the "Spec bugs" and address >> Rene's other comments, none of which demonstrate security flaws. > > Rene's last message does, indeed, describe security flaws: > > http://www.ietf.org/mail-archive/web/cfrg/current/msg03527.html > > >>> Aug 2013 >>> - draft-02 is uploaded with modifications to "hunting-and-pecking" >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03509.html >> >> Don't forget comments dealing with internationalization! >> >> The change is from a comment received from, if I recall, Russ Housley >> to use the technique from FIPS 186-3 to hide the bias added by the >> modular reduction. Again, a very nice comment, happily accepted. > > Another security fix. > > >>> Sep 2013 >>> - SeongHan Shin asks CFRG to consider AugPAKE (an alternative) >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03523.html >> >> Completely irrelevant. (Again, not sure why you're have become such >> a cheerleader for AugPAKE). > > I'm not. There are many PAKEs that are superior to Dragonfly *and* > have a clearer IPR situation: SPAKE2, DH-EKE, SRP, J-PAKE, AugPAKE, > and probably others. > > >>> Nov/Dec 2013 >>> - Joe Saloway begins TLS-PWD last call, and informs TLS WG that: >>> "The underlying cryptographic protocol for TLS-PWD has been >>> reviewed by the IRTF CFRG group with satisfactory results." >>> http://www.ietf.org/mail-archive/web/tls/current/msg10476.html >>> >>> - Uproar on TLS WG: >>> >>> - Many object to lack of formal security analysis: >>> Douglas Stebila, Uri Blumenthal, Bodo Moeller, Rene Struik, >>> Watson Ladd >> >> Missing, of course, the caveat "-- except I believe that whenever >> possible the IETF should aim to standardize cryptographic protocols >> that are unencumbered by license fees and patents. If the choice >> arises between a protocol that carries both (provable security and >> Intellectual Property) and a protocol that has neither - I'd strongly >> prefer the latter." > > That choice doesn't have to be made. There are protocols without > current patents *and* with formal security arguments (SPAKE2, DH-EKE, > J-PAKE). > > >>> - Many point out better alternatives: >>> SeongHan Shin, Robert Ransom, Watson Ladd, Trevor Perrin >> >> And you're all free to write up Internet Drafts on them too! > > I did, years ago - RFC 5054. TLS/SRP is a better PAKE than Dragonfly, > has royalty-free IPR, and has been deployed. > > >> In fact, SeongHan Shin has been following me around EMU, IPsec, >> CFRG and now TLS doing just that. After I write a dragonfly I-D he >> writes an AugPAKE I-D. Nothing is stopping you from doing it too. >> >>> - Security flaws are pointed out by Bodo Moeller and >>> CodesInChaos >>> http://www.ietf.org/mail-archive/web/tls/current/msg10708.html >>> http://www.ietf.org/mail-archive/web/tls/current/msg10768.html >> >> Bodo's comment has been addressed. I dispute the use of the term >> "security flaw" to describe it but that is consistent with the rest of >> your email. > > The flaw is only present in the TLS-PWD draft, not the CFRG draft. > > I don't believe your latest TLS-PWD draft fixes it, however. You > would have to introduce mandatory-to-implement domain parameters, as > in RFC 5054. > > >> CodesInChaos suggested using PBKDF2 to hash the password. This >> really provides no additional benefit,, as I noted in a subsequent >> email (see coWPAtty and family attacks against a protocol that uses >> PBKDF2). > > Using an "expensive" password hash is standard practice for > server-side password storage, to mitigate the effect of a server-side > compromise. > > >>> - Rene Struik and Bodo Moeller dispute that CFRG approved this >>> http://www.ietf.org/mail-archive/web/tls/current/msg10769.html >>> >>> http://www.ietf.org/mail-archive/web/tls/current/msg10812.html >> >> Actually, Rene notes that CFRG has not issued a LC. He does raise >> some comments, many of which are already addressed in the draft >> and he points out the "Spec bug" you allude to earlier. He suggests >> relaxation of one of the restrictions on parameter generation that I >> decline to accept. And he finds some additional typos and an >> erroneous description of point addition. Helpful comments. >> >>> - Eric Rescorla (TLS WG chair) states: >>> "we did have a verbal report back from the chair of the CFRG >>> that they considered it satisfactory" >>> http://www.ietf.org/mail-archive/web/tls/current/msg10819.html >> >> Indeed. >> >> So what you've brought up is that there has been discussion of >> dragonfly on the list and it has, in fact, been reviewed. Quite a few >> comments have been made and resolved, security critical issues have >> been raised and properly addressed. > > I agree that Dragonfly has had light review. Some bugs have been > picked out of the CFRG and TLS drafts, some bugs remain. > > What I don't understand is how the CFRG chairs decided the protocol > was "satisfactory". This seems a decision made by the chairs that > neither reflects CFRG consensus nor was communicated to the broader > CFRG group prior to informing TLS. > > > Trevor > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg
- Re: [TLS] [saag] Question regarding CFRG process Dan Harkins
- [TLS] Question regarding CFRG process Trevor Perrin
- Re: [TLS] [saag] Question regarding CFRG process Watson Ladd
- Re: [TLS] [saag] Question regarding CFRG process Dan Harkins
- Re: [TLS] [saag] Question regarding CFRG process Watson Ladd
- Re: [TLS] [saag] Question regarding CFRG process Dan Harkins
- Re: [TLS] [saag] Question regarding CFRG process Trevor Perrin
- Re: [TLS] [Cfrg] [saag] Question regarding CFRG p… Sean Turner
- Re: [TLS] [Cfrg] [saag] Question regarding CFRG p… Basil Dolmatov