Re: [TLS] [Cfrg] Reconsider TLS/CFRG relationship (Re: should the CFRG really strive for consensus?)

Nex6|Bill <n6ghost@yahoo.com> Thu, 29 January 2015 06:38 UTC

Return-Path: <n6ghost@yahoo.com>
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 178FF1A0021 for <tls@ietfa.amsl.com>; Wed, 28 Jan 2015 22:38:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
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 1cyqZy6dtZTb for <tls@ietfa.amsl.com>; Wed, 28 Jan 2015 22:38:09 -0800 (PST)
Received: from nm2-vm6.bullet.mail.gq1.yahoo.com (nm2-vm6.bullet.mail.gq1.yahoo.com [98.136.218.133]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 561CB1A8F41 for <tls@ietf.org>; Wed, 28 Jan 2015 22:38:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1422513487; bh=XtQEFzNVZTvhD+SEMTc2HjYXVg9v9cEWzhWQLiufdG8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=KCf86FqQ3du5Z8OKwFtCMmBMmZxu8vk143IZOoKxBOMUR8ozNo5cC4dXbodkvE2nSl3l1HKCtBzvmr1EKNjBhp54GFDVTlN2znr1DRZ3QCSP5DVeE9OOrjN8mDNQxzHBK2nkO3COsL8Ttoe4JkG7eVcwXxMcN1A6dYxnYFk19hASKKo09uLZHBASoJN2By+VcTIP54K332mymgTPQcgbuZEubKUBruZY4lFYwvNqFh+BNv56rY+4NRMM2kK3/5YHPrTpHRo4ViRryZATuE2uo4PL2OwVLVpRy9ymIP1EVwRUbl2Uq98NuiDq/vk5QGwBh2Ipu7LmjJpGhPZ46mfasw==
Received: from [98.137.12.58] by nm2.bullet.mail.gq1.yahoo.com with NNFMP; 29 Jan 2015 06:38:07 -0000
Received: from [98.136.164.74] by tm3.bullet.mail.gq1.yahoo.com with NNFMP; 29 Jan 2015 06:38:07 -0000
Received: from [127.0.0.1] by smtp236.mail.gq1.yahoo.com with NNFMP; 29 Jan 2015 06:38:07 -0000
X-Yahoo-Newman-Id: 734105.77297.bm@smtp236.mail.gq1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: tjJXRqoVM1lenUA4Rnwj3tIKMVNPqxvWdO95p8BR8KUve5P Xz2kflu0PIQE5HF2Vv_NEjQsXJZCeg0pegC_.TLUtD3U9QQE3OcJDCAhYNn3 .iwnuXV8p3e.emFaidctb9oAa4j0NmlH1tLcHGhIfb8sVaKRrtv3.508FPDK eRwG0fPPLlwfKQmVes84tzv1Pt9__PNYfgYZ7XjVRAV49_SYZIaBKT2o0nL2 I0wAfnSIIZp6rFG3eVBay2YPV5MnGAL8CNPBx84PnXAqCKIu.5wEz1vl8P7T FLhY7ow3QS964eO4PzoWUYei7NmknTAwjUwykeOycHmrtst_6KOUNJYgPdm5 COEit4_h9MGz.P0.RenXEocpgRcsQKufADtE7EovtPTExPdmIoBhqZ_NoNMx uC06Hoo4XRh2ztg8ManBW2.PBWDUPF9BrkdtztNBjRobZg5k1gLvPqc71_XR jvFcrYU_OGZtPP9hp0jkjSMN4qlPRlklaHZp4O_kZn2M7kBhnH7CuD60axzz KUdHK6S.wzXB2IjyJ.Q_xpxMdDKwiMf9pZQ--
X-Yahoo-SMTP: wgdooiaswBDebjkzZfF3YfFOtEw-
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_D1A45340-026A-4486-9BCB-971E786EF32A"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.5b4
From: Nex6|Bill <n6ghost@yahoo.com>
In-Reply-To: <20150101203734.GF24442@localhost>
Date: Wed, 28 Jan 2015 22:37:58 -0800
Message-Id: <493F162A-E924-49C9-A5B6-D169CFED7DD0@yahoo.com>
References: <CAMfhd9V4tnjQL-orjTjX3KS=-XZRn0snAPrVwmP6pZH_20Cfgg@mail.gmail.com> <1420033807.4638.16.camel@scientia.net> <CAMfhd9V5-Y60fGqCDfmCvk9+9bqm0zpm3kSHmR5_mzELZ2K+Dw@mail.gmail.com> <1420042774.10106.10.camel@scientia.net> <CACsn0c=jEXhbUQt7FqZ_KqYQqq0NJsdZow=TEZ2G0te2SUb0RA@mail.gmail.com> <20141231221420.GX24442@localhost> <EF65C8DD-840B-48AA-8B84-73E8FD809ECA@isode.com> <20150101203734.GF24442@localhost>
To: tls@ietf.org
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/np2oVotubYqZzJtG4yD_TYBfU-I>
X-Mailman-Approved-At: Fri, 30 Jan 2015 11:15:17 -0800
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, ietf@ietf.org
Subject: Re: [TLS] [Cfrg] Reconsider TLS/CFRG relationship (Re: should the CFRG really strive for consensus?)
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: Thu, 29 Jan 2015 06:38:11 -0000

> On Jan 1, 2015, at 12:37 PM, Nico Williams <nico@cryptonector.com> wrote:
> 
> [Reply-To set to tls@ietf.org.]
> 
> On Thu, Jan 01, 2015 at 05:52:55PM +0000, Alexey Melnikov wrote:
>>> On 31 Dec 2014, at 22:14, Nico Williams <nico@cryptonector.com> wrote:
> 
> [Elided here is a sub-thread about how much trouble CFRG has had making
> decisions, and how unsuited they are to the task.  These were opinions
> stated by others.  My response was that if CFRG can't choose, that's
> fine, let CFRG do what it's good at (cryptology), and let the IETF do
> what it's good at (engineering).
> 
> For the benefit of ietf@ietf.org readers, the context is that CFRG was
> tasked with producing recommendations for the TLS WG, but CFRG seems
> mired in debate about them.  From my point of view the risk is that the
> logjam won't soon be broken.]
> 
>>> Let the IRTF publish one or more documents describing various curves
>>> suitable for use in Internet protocols.  The IETF can pick from among
>>> those.
>> 
>> That is not what TLS WG /SEC AD asked for. They would rather CFRG make
>> a choice that can be used in TLS and other places, instead of letting
>> each IETF WG make their own different choice.
> 
> We may have to reconsider this then.
> 
> If it is really true that CFRG is not adept at making choices, then let
> the cryptologists document algorithms (including their cryptographic
> attributes, pros, cons, cryptanalysis, general performance analysis,
> security considerations, and an overall assessment), and let the
> engineers pick from among them.  I.e., what we've always done at the
> IETF.
> 
> This might require some process (a call for consensus in the TLS WG?),
> but once done CFRG will be freed to do what it's good at, and to do it
> more quickly because there will be no more lengthy arguments about what
> to choose.  Authors will publish I-Ds, reviewers will review them, and
> barring any serious problems, CFRG will progress those I-Ds.  The TLS
> (and other) WGs can then choose what they like.
> 
> I don't mean to start a debate about this _now_.  Rather, now is the
> time point out that we may have to have this debate, possibly before the
> next time we ask the IRTF for recommendations.
> 
> Nico
> 

I have been following this list for awhile, but have not posted anything, but; I am not sure I agree with the above.
if the CFRG does not “pick” or recommend, and instead just publish about said algorithms, and IETF then just picks
whatever they want, not sure how that would ensure the best algorithms get picked and put into standards.

would it not be better, to work on CFRG processess so it can produce a recommendation? is not good debate good?
why would it be better to have less debate?

I think in this day and age, we need to be careful and which algortithms get into standards.

-Nex6