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

"Dan Harkins" <dharkins@lounge.org> Fri, 13 December 2013 01:59 UTC

Return-Path: <dharkins@lounge.org>
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 9AEBF1AE166; Thu, 12 Dec 2013 17:59:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level:
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_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 rnAh_VoZRG-k; Thu, 12 Dec 2013 17:59:02 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 44C6F1ADFDF; Thu, 12 Dec 2013 17:59:02 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 3D74D10224008; Thu, 12 Dec 2013 17:58:56 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 12 Dec 2013 17:58:56 -0800 (PST)
Message-ID: <18138981706be6221b2d05187da48394.squirrel@www.trepanning.net>
In-Reply-To: <CAGZ8ZG0qnon4CYUh+2t201aioU1sHVQT9_8CMoez_5yM=N-cCA@mail.gmail.com>
References: <CAGZ8ZG0qnon4CYUh+2t201aioU1sHVQT9_8CMoez_5yM=N-cCA@mail.gmail.com>
Date: Thu, 12 Dec 2013 17:58:56 -0800 (PST)
From: "Dan Harkins" <dharkins@lounge.org>
To: "Trevor Perrin" <trevp@trevp.net>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: cfrg@ietf.org, "tls@ietf.org" <tls@ietf.org>, saag@ietf.org
Subject: Re: [TLS] [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 01:59:04 -0000

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.

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

  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.

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

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

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

  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.

  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.