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

From: Nico Williams <[email-masked]>
Date: Thu, 1 Jan 2015 14:37:39 -0600

[Reply-To set to [email-masked].]

On Thu, Jan 01, 2015 at 05:52:55PM +0000, Alexey Melnikov wrote:
> > On 31 Dec 2014, at 22:14, Nico Williams <[email-masked]> 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 [email-masked] 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
--

---

From: Watson Ladd <[email-masked]>
Date: Thu, 1 Jan 2015 18:37:54 -0500

> logjam won't soon be broken.]

Can we at least wait until next week when everyone is back to work,
and not send emails to multiple mailing lists that will fracture the
thread in all sorts of bad ways?

> engineers pick from among them.  I.e., what we've always done at the

The IETF isn't adept at making choices either, nor is it the case that
we would have an easier time of doing what was suggested as an
alternative. Obviously proponents would try to ensure their work is
represented in the best light, and would try very hard to muddle the
issues if they had problems.

The hope that some of the participants had is we would imitate the
contest based model of ECRYPT and AES and SHA3. But this didn't happen
for a variety of reasons too boring to go into here.

> (and other) WGs can then choose what they like.

There is substantially less distance between ECDH proposals at the 255
bit length then there was before.  In fact, the only difference is
whether the same generator as the existing Curve25519 code should be
used, or not. This was not true when the original proposals were made:
one group substantially modified their proposal to make it approach
the other one, and did so very recently.

Yes, it took us a year to decide that the original draft that kicked
this off was okay. I'm not happy about it either, but it doesn't seem
to have slowed down the TLS WG, which also way behind. I'd recommend
seeing what happens next week, and then hitting the red button.

Sincerely,
Watson

> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Nico Williams <[email-masked]>
Date: Thu, 1 Jan 2015 17:55:38 -0600

> thread in all sorts of bad ways?

I should have, yes.

> issues if they had problems.

There are more engineers than cryptologists.  It seems likely to be
easier to find rough consensus among a larger group of informed
participants than a smaller group (though getting 11 answers out of 10
people is always a possibility).  More importantly, asking cryptologists
to make decisions that the engineers could have just as well... strikes
me as an inefficient use of the cryptologists' time.

> for a variety of reasons too boring to go into here.

That would have been nice.

> bit length then there was before.  [...]

If I'd waited a few hours to post, and had read this mornings' posts to
CFRG, I'd have realized this.  My apologies.  There still would have
been something to say (see above), but with less urgency.

> seeing what happens next week, and then hitting the red button.

Fair enough.  Thanks,

Nico
--

---

From: Nex6|Bill <[email-masked]>
Date: Wed, 28 Jan 2015 22:37:58 -0800

> On Jan 1, 2015, at 12:37 PM, Nico Williams <[email-masked]> wrote:
> 

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