Re: [Cfrg] [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: cfrg@ietfa.amsl.com
Delivered-To: cfrg@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
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: Trevor Perrin <trevp@trevp.net>, cfrg@ietf.org, "tls@ietf.org" <tls@ietf.org>, saag@ietf.org
Subject: Re: [Cfrg] [TLS] [saag] Question regarding CFRG process
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.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.
- [Cfrg] Question regarding CFRG process Trevor Perrin
- Re: [Cfrg] [saag] Question regarding CFRG process Dan Harkins
- Re: [Cfrg] [TLS] [saag] Question regarding CFRG p… Watson Ladd
- Re: [Cfrg] [TLS] [saag] Question regarding CFRG p… Dan Harkins
- Re: [Cfrg] [TLS] [saag] Question regarding CFRG p… Watson Ladd
- Re: [Cfrg] [TLS] [saag] Question regarding CFRG p… Dan Harkins
- Re: [Cfrg] [saag] Question regarding CFRG process Trevor Perrin
- Re: [Cfrg] [saag] Question regarding CFRG process Sean Turner
- Re: [Cfrg] [TLS] [saag] Question regarding CFRG p… Basil Dolmatov