Re: [Cfrg] ECC reboot (Was: When's the decision?)

Alyssa Rowan <akr@akr.io> Tue, 21 October 2014 13:13 UTC

Return-Path: <akr@akr.io>
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 CB24E1A1B6D for <cfrg@ietfa.amsl.com>; Tue, 21 Oct 2014 06:13:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.003
X-Spam-Level:
X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_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 G_onnEkR2DR4 for <cfrg@ietfa.amsl.com>; Tue, 21 Oct 2014 06:13:04 -0700 (PDT)
Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8E181A1B4B for <cfrg@irtf.org>; Tue, 21 Oct 2014 06:13:03 -0700 (PDT)
In-Reply-To: <201410211027.13608.manfred.lochter@bsi.bund.de>
References: <D065A817.30406%kenny.paterson@rhul.ac.uk> <842BF4E0-8132-42F6-BDE6-65717E004006@shiftleft.org> <54418A8F.3090506@cs.tcd.ie> <201410211027.13608.manfred.lochter@bsi.bund.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"
From: Alyssa Rowan <akr@akr.io>
Date: Tue, 21 Oct 2014 14:12:46 +0100
To: cfrg@irtf.org
Message-ID: <DA102AD0-54CF-4BEC-86AA-7568A05D964A@akr.io>
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/M4KKwscznuy3NHe1r2o4JS-pS7A
Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?)
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: Tue, 21 Oct 2014 13:13:07 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 21 October 2014 09:27:13 BST, "Lochter, Manfred" <manfred.lochter@bsi.bund.de> wrote:

>>> [MH] So is the thrust of this whole argument “have your special curves, but make Brainpool mandatory to implement”?  If so, just say so, and let the forum discuss it separately, and unblock the discussion of new curves.
>> [SF] If that were the case then CFRG would be the wrong forum. Which algs are MTI for which IETF protocols is an IETF issue.
> [ML] I can assure you that this is not the case. Actually, we do not even propose that the cfrg choose the Brainpool curves, we just propose to generate two sets of curves, one using special primes and one using [pseudorandom] primes. Here we assume the generation process to be a trusted process.

Perhaps I'm confused, or perhaps there's a language barrier? The position paper you posted says that Brainpool wants pseudorandom prime curves, whose description *exactly* matches those of the existing Brainpool curves, but generated via some (unspecified, yet assumed trusted) new process; that you want these alongside special curves; and you want the PSR curves to be mandatory to implement.

Um... Wasn't this what Brainpool was for? Don't you already have some? They've got codepoints assigned and everything, and not even all that long ago. The Brainpool hardware stakeholders were quite clear that what they wanted was, basically, Brainpool - which is why I assume they are in Brainpool. We have pointed out that they've already got that, and no change obviously unbeatably minimises the changes to deployed crypto hardware, which they were quite clear was one of their goals!

If you wanted another Brainpool: why, and what is stopping Brainpool from doing it? You didn't need to do it here before. You seem to be worried the BADA55 paper discredits the Brainpool curves by showing a plausible way they could have been rigged. It doesn't prove that they actually were rigged (indeed, Brainpool is listed on Safecurves as "somewhat rigid" and still has a tick in that box). Where's the fire?

And you aren't clear how you could avoid making enough choices in any new VPR process to address the BADA55 criticisms, because you haven't suggested any new VPR process, just assumed one will exist and be agreed within our timescales. A bold assumption.

I'm relatively new, but my understanding is that Stephen is correctly pointing out that mandatory-to-implement anything is way out-of-scope here. We make suggestions, recommendations; downstream WGs in IETF decide whether they have rough consensus to adopt them, and then implementers decide whether they actually care to.

I have expressed scepticism that pseudorandom Brainpool-style curves will meet the needs of the TLS WG bringing this request to us. They'll almost certainly come dead last in performance and complexity in most scenarios, and rigidity is, as the BADA55 paper points out, tricky to argue. You haven't refuted that.

>As the cfrg  also discusses parameter lengths I would like to add that it is completely adequate to use 384 bit curves even for highest security demands.

I agree, although there aren't any convenient special primes around that area. (I also think 256 is fine.)

>So, 384 bit curves must be included in any proposed set of curves.

Um, how does that follow? Do you propose just 256 and 384, then? Or...?

Why is 384-bit a must? What's so magical about it? Why not 417? 448? 512? 521? 607? 31337?

I'm just not clear about what you want from us, and why you don't already have it.

- --
/akr
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQI3BAEBCgAhBQJURlvOGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE
jtkWi2t6q1wQAKAKuURzrcnzTsvORUS4H/PrBTH1wwFNU5cFAq0KTRsGK4UFj8Rs
8ntzyoJ0lhzQht2puN9BVekby3z9zd0eDUuMMuhsDCMNtrlm8fHS8isKXMhgKJfK
tqRz8ps6PtTyKyxYu2oZH7jkplwzMbaGqraYvrgN72knFRv225Yr9fLsF2LCfsMY
86s6JMJremE5jXLkYTAFO3exksBdmSsvNOhUnPBfRYXxNQd/M6nWK3mLTJCZUTaj
7QNeRafcUUQMs6VU2bBvDwhxSMWAbXKsnKnfRM8UBk3v8pILu1xE7KablDRfetgg
TeI2Pb8TORlZOO7sEkVRyouuRN4SYt+nwFAlTKwpLDvj7VLMcUfv5G+5Pe/s5P2t
6+IfUtDpbreL8SPNvaj75Hx4LrIBzN1ueCXNLElqJEAZvAJeMsEenGbDy14GAVqM
KgGOpeD6qfA1G19tVAj+vuWRjGAnAOHU2Ze18wMJV2E5kfJOYFhY8qMgVFluYHfn
i4zVvTZPXFR7WA/ZruSwEQ0TsWK20IHdPtt0cjlQvYIttxipbe9zwQikdaJ2tlg5
qiztfZ1P+CwLQ6aufSgBZ4DaDt5fSvGGmCzpaSatW9NS+GAjlXxSM51RREqKJclf
u/LDIvRQ3QoGHSNAONDGW45wSfG0MlaqMo2xJ0ANxozxWcY9TmI5tU9a
=cCZj
-----END PGP SIGNATURE-----