Subject: [Cfrg] Question regarding CFRG process

From: Trevor Perrin <[email-masked]>
Date: Thu, 12 Dec 2013 16:06:12 -0800

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
 * The single in-depth discussion at an IETF meeting was a string of complaints
 * 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

...

Nov 2011
 - David McGrew appoints Kevin Igoe as CFRG co-chair
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03026.html

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

 - Adam Back questions necessity of it, and lack of security
   analysis
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03046.html

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

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

May 2012
 - Kevin Igoe points out a limitation due to "hunting-and-pecking"
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03099.html

 - 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

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

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

 - 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

 - 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

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

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

May 2013
 - Feng Hao asks CFRG to consider J-PAKE (an alternative)
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03430.html

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

 - 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

Aug 2013
 - draft-02 is uploaded with modifications to "hunting-and-pecking"
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03509.html

Sep 2013
 - SeongHan Shin asks CFRG to consider AugPAKE (an alternative)
 http://www.ietf.org/mail-archive/web/cfrg/current/msg03523.html

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

   - Many point out better alternatives:
     SeongHan Shin, Robert Ransom, Watson Ladd, Trevor Perrin

   - 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

   - 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

 - 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

Trevor

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 12 Dec 2013 17:58:56 -0800 (PST)

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.

> 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

  That's what comments are. And they get addressed.

>  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.

>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03026.html

  Completely and utterly irrelevant.

>  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.

>  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.

>  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.

>  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.

>  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.

>  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.

>  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.

>  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.

>  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.

>  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.

>  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.

>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03383.html

  That's correct. You are included in that "no one".

>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03430.html

  Completely irrelevant.

>  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.

>  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.

>  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.

>  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).

>      Douglas Stebila, Uri Blumenthal, Bodo Moeller, Rene Struik,

  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."

>      SeongHan Shin, Robert Ransom, Watson Ladd, Trevor Perrin

  And you're all free to write up Internet Drafts on them too!

  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.

>    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).

>    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.

>  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.

  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.

  Dan.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 12 Dec 2013 19:36:47 -0800

> 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.

> 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.
> Your attempt to spin this as "broken" is somewhat desperate.
Modern cryptographic practice demands constant time, jump-free,
no variable memory access cryptography.
>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03430.html
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.
> 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.
>   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?
> been raised and properly addressed.
Sorry, but review is not enough. Approval is. What standard is the
chair applying here?
>   Nothing you have raised here is reason to stop advancement of
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.

>
>   Dan.
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 12 Dec 2013 23:15:12 -0800 (PST)

> 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.

>>> Could the chairs please clarify how they decided to endorse Dragonfly
>>> to
>>> TLS WG?
>>>
>>>

  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.

> 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.

> Knuth discusses this in detail in Volume 2. Bleichenbacher got a lot

  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.

> 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.

> Sorry, but review is not enough. Approval is. What standard is the

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

> 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.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 13 Dec 2013 00:00:22 -0800

> susceptibility to attack.

The consequences of adopting a protocol we think is secure that
isn't: dead people.

The consequences of ruling out a protocol that is secure because we
think it isn't: In this case nothing as the usecase is already handled.

Are you seriously arguing that Dragonfly's security is independent of ZF?

> gatekeeper? What cryptographic protocols have you approved of?

I'm not the gatekeeper, merely someone with the training required to do
cryptography. By all accounts such a person hasn't been on the TLS WG
in a long time.

>   You are obviously very confused.

Your argument seems to be that even if dragonfly is later discovered insecure,
or we don't want to use it, it will be fine because people will configure
their systems appropriately. Our experience shows that is not the case.

I have a much more cynical view: systems are only fixed when broken, and
not even then. We are the sole line between a bunch of idiots and the NSA.

> review such a document. Why don't you offer to help Feng Hao?

He already wrote a such a draft. I'm not the right person to bri^H^H^H lobby
the WG chairs to get this through, because I don't have thousands of dollars of
other people's money to spend on junkets in Honolulu. I also don't have a need
for a PAKE: TOFU with certificates works well enough for my usecases. But for
embedded devices I see the utility.

> 2+ years ago, now they're just a delaying tactic.

SRP satisfies this use case and was available then. J-PAKE was 3 years
old then. The Socialist Millionaire's Protocol was 5 years old.

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

I don't think you noticed that this standard produced IPSEC with
encrypt only, IKE1,
TLS bugs galore, and many other issues. As I mention below, this seems to be the
real difference: you are the first person who ran into the tougher
standards many of
us think are warranted.

> it as a box on which to stand so as to shout more loudly.

Could you please define what you mean by secure? I've been trying for
the past week to come up with a formal definition for the security of
dragonfly, and
not one of them has been any good.

>   Lacking any valid issue with dragonfly I suggest you go back to

If RC4 was the only cryptography mistake the TLS WG made, life would be nice.

>   Dan.
Sincerely,
Watson Ladd

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 13 Dec 2013 00:35:56 -0800 (PST)

> Are you seriously arguing that Dragonfly's security is independent of ZF?

  You obviously read too much fiction and have too little practical
experience. Dragonfly is not a threat to human life. Get a grip.

>>   So instead of "that is not quite true", it actually is. Quite.
[snip]
>>> On the contrary: "it looks secure to me" is not an acceptable
>>> foundation
>>> for

  Yet you're not; you're just bloviating.

>> in the future. Something to pad your CV.
[snip]
> not even then. We are the sole line between a bunch of idiots and the NSA.

  Uhm, no. My _statement_ was that I never said anything about RC4
or how often, or not, if ever, RC4 is used. Nor did I mention my employer.

  You spun this entire thing out of thin air.

  Or, possibly, you have confused me with someone else.

[snip]
> embedded devices I see the utility.

  Your ignorance of IETF process has been well demonstrated.

> old then. The Socialist Millionaire's Protocol was 5 years old.

  No, it doesn't. TLS-SRP does not support ECC and it is an augmented
PAKE scheme. And your suggestion now to use something else is, as
I have said, useless and 2+ years late.

[snip]
> real difference: you are the first person who ran into the tougher

  I don't know what "IPSEC (sic) with encrypt only" is. But I am aware
of IKEv1. It's provably secure in its signature-mode of authentication.

  I'm also familiar with well-respected cryptographers who participated
in the IPsec WG in the 90s. You are nobody compared to them and your
ignorant reference confirms that.

> not one of them has been any good.

  Try harder.

> If RC4 was the only cryptography mistake the TLS WG made, life would be

  And if you made useful contributions to TLS it would be nice.

  Dan.

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 13 Dec 2013 02:29:21 -0800

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.

>   A simple "sanity" check that the an ECC point is not "infinity". Again,

A crucial security check!

> because "its harder than it looks". Which is also quite true.

I believe my description is accurate.

>   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

> 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"

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.
"""

> 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.

>   Also note the comment: "Tie Dragonfly into EST would be very useful"

I appreciate that the CFRG chairs are fond of Dragonfly.

I'd like to understand where this approval comes from.

>   Correct. There is no formal proof of security. See my slides from

I read Jonathan's re-iteration of this point as expressing concern.

> 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.

> 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

"...but requires two full scalar multiplications (rather than one
scalar multiplication as, e.g., SPEKE requires)."

> draft at the time. Your opinion on it being "flawed" has already been

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?

> crucial step out of the -00 version of the CFRG draft but it is hardly

I described it as a "security issue", which it is.

>   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.

>>  http://www.ietf.org/mail-archive/web/cfrg/current/msg03430.html

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.

> had previously been addressed.

Rene doesn't seem to think the timing attack issue has been properly
addressed, and neither do I.

> 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

> modular reduction. Again, a very nice comment, happily accepted.

Another security fix.

> 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.

> Intellectual Property) and a protocol that has neither - I'd strongly

That choice doesn't have to be made.  There are protocols without
current patents *and* with formal security arguments (SPAKE2, DH-EKE,
J-PAKE).

>   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.

> "security flaw" to describe it but that is consistent with the rest of

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.

> email (see coWPAtty and family attacks against a protocol that uses

Using an "expensive" password hash is standard practice for
server-side password storage, to mitigate the effect of a server-side
compromise.

> 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

---

From: Sean Turner <[email-masked]>
Date: Fri, 13 Dec 2013 10:54:58 -0500

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 <[email-masked]> wrote:

> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

---

From: Basil Dolmatov <[email-masked]>
Date: Sun, 15 Dec 2013 12:35:49 +0400

Was impressed by the quality of arguments used in discussing of new cryptographic protocols. :-/

dol@

...