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

"Dan Harkins" <> Fri, 13 December 2013 08:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3D54E1AE6C3; Fri, 13 Dec 2013 00:36:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.867
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VDtH6cvOdz-d; Fri, 13 Dec 2013 00:36:02 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3BD001AE6C5; Fri, 13 Dec 2013 00:36:02 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id D013610224008; Fri, 13 Dec 2013 00:35:55 -0800 (PST)
Received: from (SquirrelMail authenticated user by with HTTP; Fri, 13 Dec 2013 00:35:56 -0800 (PST)
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <>
Date: Fri, 13 Dec 2013 00:35:56 -0800 (PST)
From: "Dan Harkins" <>
To: "Watson Ladd" <>
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: Trevor Perrin <>,, "" <>,
Subject: Re: [Cfrg] [TLS] [saag] Question regarding CFRG process
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Dec 2013 08:36:06 -0000

On Fri, December 13, 2013 12:00 am, Watson Ladd wrote:
> On Thu, Dec 12, 2013 at 11:15 PM, Dan Harkins <> wrote:
>> On Thu, December 12, 2013 7:36 pm, Watson Ladd wrote:
>>> On Thu, Dec 12, 2013 at 5:58 PM, Dan Harkins <>
>>> wrote:
>>>> On Thu, December 12, 2013 4:06 pm, Trevor Perrin wrote:
>>>> 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.
> 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?

  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.
>>>>   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
>>> keynote in the future.
>>   Cryptographic protocols that you approve? Since when are you the
>> 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.

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

>>   Here's an idea: find an attack on dragonfly and present it to CRYPTO
>> in the future. Something to pad your CV.
>>>>> May 2013
>>>>>  - Feng Hao asks CFRG to consider J-PAKE (an alternative)
>>>>   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.
> 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.

  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.

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

  Your ignorance of IETF process has been well demonstrated.

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

  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.

>>>>>  - Eric Rescorla (TLS WG chair) states:
>>>>>    "we did have a verbal report back from the chair of the CFRG
>>>>>    that they considered it satisfactory"
>>>>   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.
> 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.

  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.

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

  Try harder.

>>   Lacking any valid issue with dragonfly I suggest you go back to
>> obsessing over RC4.
> If RC4 was the only cryptography mistake the TLS WG made, life would be
> nice.

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