[Reply-To set to tls@xxxxxxxx.] On Thu, Jan 01, 2015 at 05:52:55PM +0000, Alexey Melnikov wrote: > > On 31 Dec 2014, at 22:14, Nico Williams <nico@xxxxxxxxxxxxxxxx> 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@xxxxxxxx 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 --