Re: [Cfrg] ECC reboot

Alyssa Rowan <akr@akr.io> Thu, 23 October 2014 17:41 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 D94D41A8AA9 for <cfrg@ietfa.amsl.com>; Thu, 23 Oct 2014 10:41:08 -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 dK0RJKnjxaEl for <cfrg@ietfa.amsl.com>; Thu, 23 Oct 2014 10:41:05 -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 265591A8AD2 for <cfrg@irtf.org>; Thu, 23 Oct 2014 10:41:05 -0700 (PDT)
Message-ID: <54493DB1.5070204@akr.io>
Date: Thu, 23 Oct 2014 18:41:05 +0100
From: Alyssa Rowan <akr@akr.io>
MIME-Version: 1.0
To: "cfrg@irtf.org" <cfrg@irtf.org>
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> <90C609A5-ECB2-4FDC-9669-5830F3463D2B@akr.io> <5448DBE2.10107@comodo.com> <CACsn0cne95adtTbCf6WyAZGyCSyLXo5L0302rm7238yHAsE5EQ@mail.gmail.com>
In-Reply-To: <CACsn0cne95adtTbCf6WyAZGyCSyLXo5L0302rm7238yHAsE5EQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/gBdBnCKTFSHmH42MimDk-aSs5uk
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: Thu, 23 Oct 2014 17:41:09 -0000

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

On 23/10/2014 15:27, Watson Ladd wrote:

>> I'm inclined to agree with my colleague PHB, who wrote recently:
>>  "The Web PKI will almost certainly be based exclusively on the 
>> ~512 level curve. The roots certainly will."
> Previously, when given a choice of curves, the one with size 384 or
> thereabouts was picked. Now you are saying you want the biggest 
> possible curve, regardless of the performance impact.

Not wishing to speak for Rob, but what I _think_ he means here is simply
that if there was one curve picked, he'd use it in principle; but given
the choice between two curves (a strong fast curve, and a paranoid
curve), he'd probably be tempted to go for the paranoid one for the roots?

Seems sensible to me: they're the Web PKI roots, after all. They're much
longer-lived signing keys than servers, and they will in practice be
under sustained, well-funded attack from nation state adversaries. Under
those circumstances, the more paranoid level may seem appropriate, but a
server key would probably far rather plump for the strong fast curve.

I echo your concerns about verification performance and secp384r1, but
that _is_ a particularly ugly baby. We can do better than that, even if
we pick a curve which is more secure, which is indeed the selling point
of Curve41417 and/or Ed448-Goldilocks. (I actually wonder how a
well-optimised E-521 would do, even. I guess we'll find out.)

Future reference note: May be useful to have state-of-the-art
implementations of NIST secp256r1, NIST secp384r1, NIST secp521r1 in the
performance shootout as anchors?

The way the sign/verify workload is on ECDSA works out well for many
servers (where sign's the bottleneck) but it's a little unfortunate for
roots (where verify is).

> How long do you think it would take to make an HSM that supports 
> our choice?

Depends: from what I've seen a few HSMs are flexible enough to run
whatever we choose. (I'll refrain from discussion of specific vendors:
it is for them to speak up if they wish.)

By the way, as a matter of practicality, would we perhaps be looking at
some kind of hybrid transition period where existing ECDSA-P384-SHA384
roots sign (purely by way of example) EdDSA-Curve25519-SHA512 end-entity
certificates? How would the choice of end-entity algorithms be
restrained by the signing algorithms and curves used on the roots, or
not? (I appreciate that may not really be a question for here, but for
upstream in TLS or PKIX.)

> Is this a matter of grab an ARM chip, add some custom firmware, 
> bypass caps, and epoxy (say ~ 6 months), or is it a more involved 
> process?

Yes, you _could_ indeed do that. It depends what you want out of it;
whether that's a _good_ approach is another question entirely. (Epoxy
doesn't really do a lot of good, by the way! <g>)

But it's _certifying_ one that's the ridiculously involved process, as
Philip raises. The big challenge in making a commodity security
device today is not cryptography, but bureaucracy!

However, I have an inkling that those who mistrust the NIST curves may
not entirely trust the NIST certifications for _exactly_ the same
reasons - so in practice, I wonder about its actual relevance, or the
relevance of other certifications. (Besides, we're not picking
NIST-approved curves here.)

Transparency and open verifiability will probably be way more important
in practice to what we're doing here than any government/other existing
certifications. An openly-verifiable HSM would be highly desirable.

> (I'm also unsure of how ECDSA handles cofactors. Will check this)

I think djb posted about that one?

Picking a new curve but using an old, relatively-fragile signature
scheme when we know we could do better and safer now that the Schnorr
patent expired seems a little silly to me, too. That's a discussion for
a future date, however.

- -- 
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUST2xAAoJEOyEjtkWi2t6NeUQAKjXFfzlgMXOCeNBBSHoD7BI
7nrTiMTM+iGqj+5F0xwQ4KRJTmd9hf6y+MbLAv7HZGDNdVcrNOJPomnj8bQu35dd
cK+C7R/Jr/JDdAC5/TOychR8IEpkfwsI5fLYwkoYHL4vwNSQ8ENAt2oGst3D3Tm3
bRKjve0vw9TzGLcn8sdEo83dkfvxW8WJjJrZ44U5gP9MElVio7yqmk4XZrw4ZIoV
fAgmWXgpTciIP7yaoHkHo19JMbFkRnpmcraIcqaScf4XOUEMvF0LwyYGxkh8QiQD
Cp3cPvatef+mWUoDuhvFNIVwBGJJYD/8RGlXVqWdbC/NidgUpCsHg4DYbBhLlTLT
i0DTr9u1QsRGkuRa9CZuXFxAyN9jFiorYqz+F4CnCgrhWm4VYPjPT3XxZYtLshkP
txVNKsrxv6N6GCa3yEjkOIdnjdZxY2p7aoa8hqz6irvWNgOORw8nVn/ZTPz3NDVj
2jDixxj1QfBWHp0VAaYv6/xt2kZTXYXcY7/vHFHoMF43O/C5n6qWgYiTmdyg3GZJ
/W/Q+lYXYVgSZYSRGYFB2HfltzxJkZc0ZXFX7A2bqRcvMrnwoqn+YjI2uC1jYZXv
rlTK+VZN90VtbmuFy2i+gFLpysNIHz5C1SEL9xEtYq4kOoeles14uKtVWLhwsmQ5
61tjNSHkFEAdCn17o2mL
=PGsM
-----END PGP SIGNATURE-----