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-----
- [Cfrg] Requirements for curve candidate evaluatio… Benjamin Black
- Re: [Cfrg] Requirements for curve candidate evalu… Salz, Rich
- Re: [Cfrg] Requirements for curve candidate evalu… Watson Ladd
- Re: [Cfrg] Requirements for curve candidate evalu… William Whyte
- Re: [Cfrg] Requirements for curve candidate evalu… Mike Hamburg
- Re: [Cfrg] Requirements for curve candidate evalu… Benjamin Black
- Re: [Cfrg] Requirements for curve candidate evalu… Phillip Hallam-Baker
- Re: [Cfrg] Requirements for curve candidate evalu… David Jacobson
- Re: [Cfrg] Requirements for curve candidate evalu… Salz, Rich
- Re: [Cfrg] Requirements for curve candidate evalu… Salz, Rich
- Re: [Cfrg] Requirements for curve candidate evalu… Phillip Hallam-Baker
- Re: [Cfrg] Requirements for curve candidate evalu… Phillip Hallam-Baker
- Re: [Cfrg] Requirements for curve candidate evalu… Benjamin Black
- Re: [Cfrg] Requirements for curve candidate evalu… Benjamin Black
- Re: [Cfrg] Requirements for curve candidate evalu… Alyssa Rowan
- Re: [Cfrg] Requirements for curve candidate evalu… Phillip Hallam-Baker
- Re: [Cfrg] Requirements for curve candidate evalu… Phillip Hallam-Baker
- Re: [Cfrg] Requirements for curve candidate evalu… Alyssa Rowan
- Re: [Cfrg] Requirements for curve candidate evalu… Watson Ladd
- Re: [Cfrg] Requirements for curve candidate evalu… D. J. Bernstein
- Re: [Cfrg] Requirements for curve candidate evalu… Tanja Lange
- Re: [Cfrg] Requirements for curve candidate evalu… Phillip Hallam-Baker