[prev in list] [next in list] [prev in thread] [next in thread]
List: cfrg
Subject: Re: [Cfrg] [saag] Question regarding CFRG process
From: Sean Turner <TurnerS () ieca ! com>
Date: 2013-12-13 15:54:58
Message-ID: 1D142D8E-2BBE-4BD2-B454-A07A7D31ECD1 () ieca ! com
[Download RAW message or body]
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
["smime.p7s" (smime.p7s)]
0 *H
010 + 0 *H
0|0d XJ6Ty0
*H
0"10 UUS10U
IECA, Inc.0
130403145118Z
140403145118Z0810 UUS10U
IECA, Inc.10USean Turner0"0
*H
0
B$i=f)-9jKgD} \
M!+~ր5WDXu^-Ei_ӃFѵzJ_mîta[(ִe].0L \
G}(>[#ގ`:3S"7)emxm@{1ձ;4t)awDy5C3J \
눸ӻg; F*NfQkmvΈķVrG+1ם 00U0U#0 tlIRaqMV8a
0U0TurnerS@ieca.com02U+0)0' % \
#!http://www.ieca.com/crls/ieca.crl0U 00 + 0
*H
"6&iN./+IHr &\F
Өt|0[D%ʃFIIVsb3dl&a!sPxA{+?RAo!Wҟx,8u7XqWOʗq?Y0*АŘSvaЮE#]BY{[aJCmX&(ݗkJs \
5UCuۀ8q A|TBLaOk_ljtbZpxJnj/?!pEGWۂz@8~88 \
mW1`䉿L֤tx2#o9ڛoKcabiP!axx`pOE.+Q6U.'*+QhZX{dmtSxUY?)![Xڥn
}tPwGr%-;_zs
jCw-}ܾ<8lZl{
Y`9%ƗW5ݞ>ߔ! ̣>xs&AY%ʐp$L1,0,18040/0"10 UUS10U
IECA, Inc. XJ6Ty0 + 0 *H
1 *H
0 *H
1
131213155458Z0# *H
16u#wTZkN?gjAx7 0> +7110/0"10 UUS10U
IECA, Inc. XJ6Ty0@*H
11 /0"10 UUS10U
IECA, Inc. XJ6Ty0
*H
aE6mp}Q]gO^Z[ @<l_y \
uj- 3Sa}tw zlAN <~O}b XXYx0`SIgB
vh8V}^b tOyN4%BjnZ8>?+ E+*?m~ٵ"7j}eClbk|#joUթ4<?
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic