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

["Dan Harkins" <[e-mail]>]

On Thu, December 12, 2013 7:36 pm, Watson Ladd wrote:
> On Thu, Dec 12, 2013 at 5:58 PM, Dan Harkins <[e-mail]> wrote:
>>
>> On Thu, December 12, 2013 4:06 pm, Trevor Perrin wrote:
>>
>>   ...an extremely misleading email.
>>
>>   Using pejoratives like "bug", "flaw", and "attack" he attempts a
>> smear of people, a protocol, and process. In reality there is no
>> security bug or flaw or attack with dragonfly.
>>
>>   There is obviously some personal animosity and taste involved
>> but that is not technical. Read on.
> This is not quite true. Dragonfly's vaunted resistance to offline
> attack doesn't hold
> in the standard model or the ROM because there are some hash functions
> (like hashing+exponentiation)
> which break it. This is a very serious issue: it means we don't know
> what it means for Dragonfly to be secure.

  "vaunted"? The fact that you have to exaggerate reveals much.

  If "it looks good to me" is not enough for you then certainly
"it doesn't have a security proof" is not evidence of flaws and
susceptibility to attack.

  So instead of "that is not quite true", it actually is. Quite.

>>> Dear CFRG (cc: TLS, SAAG),
>>>
>>> I'd like to understand how the CFRG decides on guidance to provide IETF
>>> WGs.
>>>
>>> It appears the CFRG chairs provide this guidance based on their own
>>> opinions, disregarding any feedback from the mailing list or IETF
>>> meetings.
>>>
>>> In particular, the CFRG chairs have repeatedly endorsed the
>>> "Dragonfly" protocol to the TLS WG.  However, I find no evidence of
>>> *ANY* positive feedback regarding Dragonfly in the CFRG mailing list
>>> or meeting minutes, except from the draft's author and CFRG co-chair
>>> Kevin Igoe.
>>>
>>> Compared to Kevin's enthusiasm, note:
>>>  * Respected cryptographers and security engineers like Jonathan Katz,
>>> Adam Back, and Rene Struik expressed skepticism on the list
>>
>>   Let's look at those, read on.
>>
>>>  * The single in-depth discussion at an IETF meeting was a string of
>>> complaints
>>
>>   That's what comments are. And they get addressed.
>>
>>>  * Alternative proposals were made to CFRG (J-PAKE, AugPAKE).
>>>
>>> Could the chairs please clarify how they decided to endorse Dragonfly
>>> to
>>> TLS WG?
>>>
>>>
>>> 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.
>>
>>>  - 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.
>>
>>> 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.
> On the contrary: "it looks secure to me" is not an acceptable foundation
> for
> cryptographic protocols. I do not want any protocol I approve to be a
> CRYPTO
> keynote in the future.

  Cryptographic protocols that you approve? Since when are you the
gatekeeper? What cryptographic protocols have you approved of?

  Here's an idea: find an attack on dragonfly and present it to CRYPTO
in the future. Something to pad your CV.

>>   You should link to my slide deck in your next broadside.
>>
>>> 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. The
>> sole mention in the minutes of SPEKE is from me. And the "concerns"
>> are a recitation of comments received. That's how it works. You get
>> comments and you resolve them.
>>
>>> 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.
>>
>>>  - 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.
>>
>>> 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.
>>
>>> 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.
> Modern cryptographic practice demands constant time, jump-free,
> no variable memory access cryptography.
>>
>>>  - 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. 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.
>>
>>>  - 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.
>>
>>> 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.
>>
>>> 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".
>>
>>> 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 don't think so. Your repeated insistence to the contrary, there are
> people who
> will use RC4 on TLS connections, etc, etc. Our endorsing a protocol
> when superior
> alternatives exist is a bad thing, because insecure options have a
> nasty habit of being
> turned on. You've argued that because you and your employer don't see
> an issue, we should
> be happy to endorse this.

  RC4? What the hell does that have to do with anything?

  And when did I insist that people will not use RC4? And when did I
mention my employer? Never and never.

  You are obviously very confused.

>>> 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.
>>
>>>  - 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.
>>
>>> 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.
> Knuth discusses this in detail in Volume 2. Bleichenbacher got a lot
> of mileage from
> this.

  So? Aside from giving you an opportunity to name drop, what does
that have to do with anything? The comment was made, it was not
asserted as being some original insight, and it was accepted.

>>> 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).
>>
>>> 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."
>>
>>>    - 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!
> Why do you want Dragonfly as opposed to J-PAKE? If you think it is
> going to slow, call up Feng Hao and offer to help. That would satisfy the
> need you identify in your usecase in the TLS WG.
> Or is this not about solving the problem of password authenticated key
> exchange,
> but putting your protocol into things?

  Why don't you do a draft on J-PAKE? I asked you before to please write
an Internet Draft. Please. I would really appreciate the opportunity to
review such a document. Why don't you offer to help Feng Hao?

  What this has to do with is a desire to have a TLS cipher suite to
satisfy legitimate use cases yesterday. You come along 2+ years late
and then say that it should all be abandoned and something else pursued.
Because _you_ don't approve. Your suggestions might've been helpful
2+ years ago, now they're just a delaying tactic.

>>   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.
>>
>>   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).
>>
>>>    - 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.
> Sorry, but review is not enough. Approval is. What standard is the
> chair applying here?

  The existing standard that is in place for TLS and the IETF.

>>   There are no flaws in the key exchange. It has some aspects to it
>> that some may feel is a benefit and some may feel is a detriment.
>> Personal taste is not something that can be universally accommodated.
>>
>>   Nothing you have raised here is reason to stop advancement of
>> this draft.
> I disagree. This draft is reminiscent of the worst of 90's
> cryptography: ad-hoc assumptions,
> no formal statement of security, gratuitously not a circuit, and not
> subject by review by anyone
> who is a cryptographer. It may be that this draft has exposed a fault
> line between those who think
> the current process is acceptable and those who do not.

  It lacks a formal security proof. That is all. There is no other problem
with it. The side channel attack issue was already addressed after a
long thread a long time ago. One might consider revisiting it if the
people harping about it really wanted a change, instead of just using
it as a box on which to stand so as to shout more loudly.

  Lacking any valid issue with dragonfly I suggest you go back to
obsessing over RC4.

  Dan.