Re: [Cfrg] [saag] Question regarding CFRG process

[Trevor Perrin <[e-mail]>]

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 <[e-mail]> 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