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

Alyssa Rowan <akr@akr.io> Wed, 22 October 2014 12:59 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 2B9781A90F9 for <cfrg@ietfa.amsl.com>; Wed, 22 Oct 2014 05:59:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bHfLWK8YSgCR for <cfrg@ietfa.amsl.com>; Wed, 22 Oct 2014 05:59:44 -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 EC6461A90F8 for <cfrg@irtf.org>; Wed, 22 Oct 2014 05:59:43 -0700 (PDT)
In-Reply-To: <201410221404.36477.manfred.lochter@bsi.bund.de>
References: <D065A817.30406%kenny.paterson@rhul.ac.uk> <201410211027.13608.manfred.lochter@bsi.bund.de> <DA102AD0-54CF-4BEC-86AA-7568A05D964A@akr.io> <201410221404.36477.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: Wed, 22 Oct 2014 13:59:36 +0100
To: "Lochter, Manfred" <manfred.lochter@bsi.bund.de>,cfrg@irtf.org
Message-ID: <D93555CB-29B4-498A-9DC4-88FF87A02593@akr.io>
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/4ciomgww5a_hjtz_XU2e7u5BqP4
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: Wed, 22 Oct 2014 12:59:46 -0000

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

On 22 October 2014 13:04:36 BST, "Lochter, Manfred" <manfred.lochter@bsi.bund.de> wrote:
>And for me the reasoning from the BADA55 paper does not appear to be plausible.

I understand your defending your position, but there does appear to be professional disagreement on that point. (I think myself they are indeed plausible but not too likely, as the approach taken by Brainpool would have likely been the most obvious one at the time. However, I have not investigated this in detail.)

Like I've said, if you want new pseudorandom curves, nothing stopped you before and nothing's stopping you now - but: I don't think that's what the TLS WG asked us for; I don't think that's what anyone other than the Brainpool participants want; I don't think Brainpool needs our help to get the things it wants because it's already got them; I don't agree at all it's the best approach to take even in hardware, and; I don't think any further discussion on this point will bring our diametrically-opposed requirements into unison, it'll just delay matters and we don't want that.

I propose therefore, simply, that no changes need to be made to the curve criteria to accommodate the request of the Brainpool group. Let's move on from this.

>> …mandatory-to-implement anything is way out-of-scope here.
>Where did I suggest to make anything mandatory? I searched all my postings for "mandatory" without finding that source.

Um. It's… right there in the conclusions of the position paper you co-authored and linked here, Manfred.

"Requirements for Standard Elliptic Curves: Position of the ECC Brainpool", Cryptology ePrint Archive: Report 2014/832 <https://eprint.iacr.org/2014/832>:
>A potential compromise is the construction of new curves with similar properties as the Brainpool Curves, i.e., with verifiably pseudo-random primes, and make this set mandatory to implement.

I hope that clears that up for you. And as before, any mandatory agreement is not really within our gift to give, so that's not a compromise we can really make.

>To make it perfectly clear: If the group is going to only propose curves for two security-levels I'm opting for 128 and 192.

If 192 is strong enough, surely bigger ones would be stronger and also fine?

If 192 is not a good efficiency::security inflexion point, we'd probably rather choose another. If stronger ones are more efficient (and they are: Curve41417, Ed448-Goldilocks) we'd probably rather choose those, unless we can very clearly justify why 192, and not, say 256.

Why would you pick 192, in particular, given there are really no very good special primes in that area and, for example, AES-192 is seldom used? (secp384r1 and SHA-384 is only used anywhere because NSA Suite B picked it; even they couldn't get anyone who actually used AES-192.) This is, after all, the kind of thing meant by "rigidity": clear, justifiable, obvious reasoning, without arbitrary unexplained choices.

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

iQI3BAEBCgAhBQJUR6o3GhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE
jtkWi2t6ALwP/27zMX92hZxM2YS8iCfwfr3ozz03buCWDrg1KKIyiS5oiV32r1zD
nZLwlulnV8c7QkgTAFHqtrEODEsjVO5tb77mhYD0lDC2b/Ym6FHhSi+GyjX9kz8a
htgckWDnFxJ5jVviAXnFoOCsRKv0cjSfTdHmXAtyWj3PNJEOPicaj790Fio+SZSw
QK7oZvlqOSHCjPF0YP6Gpt00nLglnrjCFPg8zyAwJ++yNP4duDGcLAHLzEEBTgMB
BBX6fY3h3aNXxt7QG5uAwNN2hzKzyZN91ckgM2luDBrc7NFJ0iQvL7AB8w36uP5n
omgVn7V7ZeyDP9AdVg5+8JWSr8QERzkPHdVDGnQ95uJrJGLZQIXyiIarZn+BVtwM
8aQ3+7H7ZF9jURCwuAj93OyoZXZVBgjmx9RHmLmJXrdFW8FW0ftbDNAD6ENvWBXl
6ZfhF4Njv/VuV1V5CITikusDyt+sbplwVCq9H8luB6KU/RPcrozgu9o5bNwVCijF
F0q4s3qkCJEOHpFsTSZBHZI6bEb9gIDSMbkkEYhlPpBmIBTvmrnRrG/24yfDwec1
/Y2mKuv6h0jQ1YKI2JIpzQuXL3bqj3toDGCX/mhN5ibDDfl9Eb+NtZqaEvJMMN41
o2PFOUg+LDAf+NbMr87lcLwyFC5xFTUFS8M4QP9WxpT7LwGrtUREKLPj
=BUcz
-----END PGP SIGNATURE-----