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