Re: [Cfrg] Requirements for curve candidate evaluation update

Alyssa Rowan <akr@akr.io> Thu, 14 August 2014 05:49 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 B03371A077D for <cfrg@ietfa.amsl.com>; Wed, 13 Aug 2014 22:49:22 -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_40=-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 lheW9MMxOmoG for <cfrg@ietfa.amsl.com>; Wed, 13 Aug 2014 22:49:18 -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 D789C1A0776 for <cfrg@irtf.org>; Wed, 13 Aug 2014 22:49:17 -0700 (PDT)
Message-ID: <53EC4DDD.7010503@akr.io>
Date: Thu, 14 Aug 2014 06:49:17 +0100
From: Alyssa Rowan <akr@akr.io>
MIME-Version: 1.0
To: cfrg@irtf.org
References: <CA+Vbu7wuAcmtAKJYEgAaSBTf6sj8pRfYpJhz2qV_ER=33mrk8Q@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7185A0C8CEB@USMBX1.msg.corp.akamai.com> <CA+Vbu7zfbx-OqU=ggXgutDb+GNwvS3QpkTwzU1c+2Lcv=3Gawg@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7185A0C9094@USMBX1.msg.corp.akamai.com> <CAMm+Lwg8EZ-MWN4hKxzN+g5L9-GjgEGV49NqYNEnK=34qrkb+w@mail.gmail.com>
In-Reply-To: <CAMm+Lwg8EZ-MWN4hKxzN+g5L9-GjgEGV49NqYNEnK=34qrkb+w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/r6rhCt5mn83cnxuPZw6yF30KC8w
Subject: Re: [Cfrg] Requirements for curve candidate evaluation update
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, 14 Aug 2014 05:49:23 -0000

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

On 14/08/2014 03:42, Phillip Hallam-Baker wrote:

> To be clear, I am arguing that we put HSM support way ahead of a 
> single model. HSM support is essential, a single model is
> someone's idea of tidiness.

That is a null property. Anything we can specify can be implemented in
software or hardware. As I said before, there will _eventually_ be new
HSMs, and new HSM firmware. People have already begun work on that.

The commercial world of this are however glacially slow-moving, partly
due to onerous and ineffective governmental certification requirements
(one of the things that has been - rightly - criticised). Several do
not support ECDSA (or ECDHE, where applicable) properly or at all, and
this is why RSA is still far more common in the wild and ECDSA is
quite honestly barely used by anyone publicly (there are _very few_
ECDSA PKIX roots...) - those that are using it are running it in
software and are therefore not relevant to your 'essential' requirement.

That's about the same as Kevin's problem with military procurement
cycles (in fact, more identical than you think - we are actually
talking about the same vendors/fabs in some cases!).

Inertia mustn't hold us back from recommending anything new and
better, because otherwise we'd _never_ consider anything new.

The TLS WG asked for this because they have new requirements for trust
and performance reasons. Anyone using a commercially-available HSM
obviously doesn't, and are not the intended targets of this proposal
within the timeframe ECC will be useful at all.

Most TLS stakeholders are much, much more agile than that. You can
usually spot the ones that aren't: still using 3DES. :-)

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

iQIcBAEBCgAGBQJT7E3cAAoJEOyEjtkWi2t6A/IQAKSXS9PeWcpof1LyKugwFqkT
E19NZFcTMeZEZJiUpKakhwFSdrTDsHyDgVRdW8gyWiJ7ywNgZcHmEfUiCKvERHzP
Le/HNzB7T8/Dm4zukl8Mo739rTw0fr0kNQtPrA61E6hpIucpdX0jzk0c4vvCvo6Q
uQXqkqgEco5UVYDGsLkNOKBX0ZWkI8ILg1NTvwcjKy5c0ibqY3wcaf28YIq8QFQ0
QkgNYWJ77ATylhU+rGsinMs+17I19zHB0Did5O3dhMktGyqfuLYIr9+NAETFxAS3
BjQtSicBmHW1c8RDoz78IeK3lmkrHvCCou9a2esnPElnn2m7Q/13fQeJT7R+eqZc
nrGTdpXtJMgWvwJ2hu6wToocxQd01uyvq9ldLxW01NVLsniOIcr51dUfwTlaNJkn
Q5aPJh2y4nuUILafw8pv0gG64o1yOiL5UWLf4pr8lz5UkWqBTvyqeZcCOd6ll3jT
MeZ3vAPAVjParoiJQE9ZhJwlmP3kF2ik1e7U1brGZe4WvRjMjF3kAJJRxrrWh/AL
vBlYu19yaOThjO9DJ6VKE6EJ/17KBhg2ZM1ejH6/8/419hObnX65BQUsFpkl4nwa
qeRjxRcLScPKdhQoPOPh1fRjkazB127EeKJs2SYdCZddrxjkoXznj1aV96GRz2Sh
+cUrvAWucNkbiIW7w4/b
=a7Wl
-----END PGP SIGNATURE-----