Re: [Cfrg] ECC reboot

Alyssa Rowan <akr@akr.io> Mon, 20 October 2014 13:05 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 E0C101A872F for <cfrg@ietfa.amsl.com>; Mon, 20 Oct 2014 06:05:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.798
X-Spam-Level:
X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 iV93IhZcKd2N for <cfrg@ietfa.amsl.com>; Mon, 20 Oct 2014 06:05:26 -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 0EBEC1A872A for <cfrg@irtf.org>; Mon, 20 Oct 2014 06:05:24 -0700 (PDT)
In-Reply-To: <5444D89F.5080407@comodo.com>
References: <D065A817.30406%kenny.paterson@rhul.ac.uk><54400E9F.5020905@akr.io><CAMm+LwhVKBfcfrXUKmVXKsiAMRSTV+ws+u07grmxkfnR2oYJoQ@mail.gmail.com><5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org><m3r3y6z3z8.fsf@carbon.jhcloos.org> <CA+Vbu7x4Y_=JZ9Ydp=U5QnJokL28QMQnV4XUn9S6+CUZR9ozEw@mail.gmail.com> <5444D89F.5080407@comodo.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
From: Alyssa Rowan <akr@akr.io>
Date: Mon, 20 Oct 2014 14:05:13 +0100
To: "cfrg@irtf.org" <cfrg@irtf.org>
Message-ID: <90C609A5-ECB2-4FDC-9669-5830F3463D2B@akr.io>
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/TmojEgEwKPHvrCQxHW_ZlqaNEns
Subject: Re: [Cfrg] ECC reboot
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: Mon, 20 Oct 2014 13:05:29 -0000

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

On 20 October 2014 10:40:47 BST, Rob Stradling <rob.stradling@comodo.com> wrote:

>When we generated our ECC root CA keys in 2008, secp384r1 seemed like the best choice.  secp521r1 wasn't in Suite B, and it seemed likely that Suite B compliance would be a requirement for some of our customers.

Why not secp256r1? (I'm guessing the big reason was because the TS profile required ≈WF192 and you wanted one root to be suitable for both profiles if you could?)

It's a bit early to say, but (open question to all) if we picked one curve at ≈WF128, would you in principle be comfortable with having roots of that strength?

What about if we picked two: one fast secure curve at 128 and one at some higher "paranoid" grade (be it 384, 448, 480, 512, 521, 607...)? Which would you perhaps consider using when? Would you have one root at each level, or a shared root at the paranoid level?

What kinds of things would you need to be able to have such a root? I'm guessing, bringing it back home to the weekly topic, that 'high-assurance' crypto hardware of some form would be highly desirable for that. But what does that mean to *you*?

I say this because I don't think the initial target market for these new curves necessarily includes those mandated to use Suite B (although never say never!), I don't think government approval will drive adoption this time, and also the assurances people ask of Web PKI CAs in particular seem to be strengthening considerably relative to where they were (cf: Certificate Transparency, et al).

>TLS clients commonly don't specify RSA/SHA-512 and ECDSA/SHA-512  in the TLS signature_algorithms extension.  Some servers respond by refusing to serve certs with SHA-512 signatures.

Thanks for that note. The TLS WG and user-agent participants should probably bear this in mind, down the line, if whatever we come up with is to be accepted and used.

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

iQI3BAEBCgAhBQJURQiIGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE
jtkWi2t6lFAP/04NXnjKWHI34cZ2OYIs+qCP4q35hKFvbtAX+7MECPmlF+4lrpbS
/Hzu8bjjsLVphsTWbXo8bW7sXCLWzHGkcL4QuvZM56ArngvP17EK3tZIgkFiOjKY
D+hlGskjcAgXDhRvyaEvimuUHQ9BVWmGft0XPnMSucBckq634Bbw3VSdzhq+0yAV
5awXzKeTkrI9sYrwSXZ/P9TN/ejVjfI0t3KU+RxdMPWTY8psbmXsuaMT8ny4EkOi
PhskwFNb5rndfRBEq/rnenhXAgTnUJVf51vBhU8YOKZLy2NojcZ2Wjy5YOQuDepQ
GE3phWRqxCA4hnhbnNHcguxnlh5B6y5OzEYd/9/Iaia/brj7H3eYvc84RnG1H9Fl
VTkBrAZUUmtcmdnTlNnEBQQ/pmSlGWZsIhLYPueXD43yAggMvP8YffURKADFfm6J
Om5BmI2JVWjFpDjQA7e9NKL6niTJUccqUkHNjm54wEwIuh0zcKJCBzZ4P4cUU+vk
T5BDy3AoVLFT9uVOXV/vXkTA3xcOtlLaUgnTa3CzRR9IuoIewPncK1MurP6I37jA
XzcupAFmTgiDcITjKAm2xzaVzJwWByBbtuvaMBKRFbA1UK++y9/YWnhalwsEmNYf
lo5LnvTuJa/SvmPcpLHqtqeTIIV3rWVdn5GVbZOx5jxao5KK19b/7kMF
=tB0e
-----END PGP SIGNATURE-----