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

"Dan Harkins" <dharkins@lounge.org> Fri, 13 December 2013 08:36 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 3D54E1AE6C3; Fri, 13 Dec 2013 00:36:06 -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 VDtH6cvOdz-d; Fri, 13 Dec 2013 00:36:02 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD001AE6C5; Fri, 13 Dec 2013 00:36:02 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D013610224008; Fri, 13 Dec 2013 00:35:55 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 13 Dec 2013 00:35:56 -0800 (PST)
Message-ID: <8cf8a51b9dcfd0c40b80ae2aad2cff7c.squirrel@www.trepanning.net>
In-Reply-To: <CACsn0ckBcxP=mOdxS-fZQL5upkPqsHHuQVZvD-G-tYSnmySVmg@mail.gmail.com>
References: <CAGZ8ZG0qnon4CYUh+2t201aioU1sHVQT9_8CMoez_5yM=N-cCA@mail.gmail.com> <18138981706be6221b2d05187da48394.squirrel@www.trepanning.net> <CACsn0ckiDG8bt+zMG=R3JErb4SD0mey+ou5tGZ30x2tjy9v7mA@mail.gmail.com> <bad4a1b3e1f5f799418ef3c6fab9492c.squirrel@www.trepanning.net> <CACsn0ckBcxP=mOdxS-fZQL5upkPqsHHuQVZvD-G-tYSnmySVmg@mail.gmail.com>
Date: Fri, 13 Dec 2013 00:35:56 -0800 (PST)
From: "Dan Harkins" <dharkins@lounge.org>
To: "Watson Ladd" <watsonbladd@gmail.com>
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 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 <dharkins@lounge.org>; wrote:
>>
>> On Thu, December 12, 2013 7:36 pm, Watson Ladd wrote:
>>> On Thu, Dec 12, 2013 at 5:58 PM, Dan Harkins <dharkins@lounge.org>;
>>> 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.
>
> 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.
>>
[snip]
>>>>   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?
>
> 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.
>>
[snip]
>>>>> 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.
>
> 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.

>>
[snip]
>>   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.

>>
[snip]
>>>>>  - 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.
>
> 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.

  Dan.