Re: [Cfrg] Curve selection revisited
Hannes Tschofenig <hannes.tschofenig@gmx.net> Mon, 28 July 2014 17:58 UTC
Return-Path: <hannes.tschofenig@gmx.net>
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 210111A0A81 for <cfrg@ietfa.amsl.com>; Mon, 28 Jul 2014 10:58:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 t-FoUaqjnW54 for <cfrg@ietfa.amsl.com>; Mon, 28 Jul 2014 10:58:53 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D32A11A0A8F for <cfrg@irtf.org>; Mon, 28 Jul 2014 10:58:13 -0700 (PDT)
Received: from [172.16.254.119] ([80.92.116.212]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MTjMy-1X381T3Z3o-00QPBG; Mon, 28 Jul 2014 19:58:12 +0200
Message-ID: <53D68F33.3010802@gmx.net>
Date: Mon, 28 Jul 2014 19:58:11 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Michael Hamburg <mike@shiftleft.org>, Robert Moskowitz <rgm-sec@htt-consult.com>
References: <CA+Vbu7xroa68=HOZtbf=oz7kK2EeUv_z1okpnjxHPR0ZtHD5cA@mail.gmail.com> <53D66506.4080809@htt-consult.com> <C0C42541-06A2-465B-82CF-00DA63BE1398@shiftleft.org>
In-Reply-To: <C0C42541-06A2-465B-82CF-00DA63BE1398@shiftleft.org>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="KDuxmG8S6e1iRCJIcDOmdfDQnM8Ge6EB7"
X-Provags-ID: V03:K0:OubpG2Vzb7SFs/ZkvDuQfMiPiroUuGK/gbL+8aJIubIXXQbtXJH D4XwiVXQ/rtp7Uewl5AEfD3L+4btjPzcKrR8tSdDs6jfTAZxQrzc+8NQKPSamW8Gpxi2H5G vwrUeyUfEqscpMcXXT9wwZne2o/HmCRLBenN5UmPKFrFZVqq3ECsrIbIWHEIDEDYIZzCmUU 7dZZbifIStakB49WduSfw==
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/14M7PEUI3m-K6mQDuTkpQvI4LXs
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Curve selection revisited
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, 28 Jul 2014 17:58:58 -0000
Hi Mike, Hi Bob, Saying that you need hardware acceleration because of performance, RAM and ROM size supported by some boards running 8-bit microcontrollers is a bit lying to ourselves. The hardware acceleration might in fact involve a chip with 32-bit. 8-bit microcontrollers have been great for devices that are not connected to the Internet. For example, many early Arduino boards have used a 8-bit microcontroller and their RAM/ROM configuration does not make the use of crypto feasible to any realistic extend. Now, we are past that point and it turns out that you get a Bluetooth Smart chip that happens to have (internally to the chip) an 80kb stack just for the actual link layer. New Arduino boards also run on 32-bit processors and so do most of the IoT gear that gets brought to market these days. Also, the cost of 32-bit microcontrollers is sufficiently low that it makes no sense to focus development effort on a 8-bit microcontroller anymore. Just think about the software development cost here as well (and not only on the pure hardware cost). While the world is indeed cost sensitive real product managers look beyond the pure hardware cost and also take other factors into account. Of course, everything depends on the volume. 32-bit processors can also be energy efficient as the widespread deployment shows. It is also important to note that energy consumption does not only depend on the processor - it is the result of the entire system. So, just focusing on the processor makes it a bit difficult to have a useful discussion about energy efficiency. Since the IETF does not focus on products / entire systems I fear it will be very difficult to have a meaningful conversation about this topic. Since we have these discussions regularly in ACE I am planning to schedule a Webex conference call to have one of my co-worker (who works on hardware many years already) to explain what the industry trends are. Having said that I am happy to take the results that come out of this group and let them run on ARM processors to see what the performance is. Ciao Hannes PS: Regarding the ASN.1 format I am wondering whether the IEEE has done some more detailed analysis of the over-the-wire and the software implementation cost. This would be useful for us in the ACE working group. On 07/28/2014 07:05 PM, Michael Hamburg wrote: > You’re going to need a hardware accelerator for some of these small > things. Eg for v2v safety, the real ask has to be “fast and small > and easy in hardware”. The best solution to this is binary curves, > though they are considered slightly edgy right now. > > But yeah, 8-bit processor performance is important too. > > Cheers, — Mike > > On Jul 28, 2014, at 7:58 AM, Robert Moskowitz > <rgm-sec@htt-consult.com> wrote: > >> The whole world is NOT TLS. For example I am working in IEEE 1609 >> which is Vehicle-to-vehicle safety communications and their need is >> for signed data objects that are quickly generated and verified >> (you have ~100ms from the braking event to all the cars being able >> to act on that information). I also work in IEEE 802.15.4 highly >> constrained devices (some much smaller than what many IETF groups >> accept as their lower limit). >> >> 8 bit processors are the norm, and NO, Dr. Moore is NOT going to >> change that. Lower energy demand is much higher on the design plan >> than faster processing. Also whatever is done will be running on >> fielded devices for the next 10 - 20 years. Hardware acceleration >> is acceptable, but that could make in-field corrections impossible. >> Over-the-air firmware updates may also be impossible (802.15.4k is >> 40kb/s) or only done in the dealership (yes! another recall!). >> >> So getting on to my thoughts of curve selection requirements for >> the world of small: >> >> 1) Low over-the-air demands. Every BIT counts. We have to live >> with 32 bytes; but 64 bytes may be too much. Oh, IEEE 1609.2 has >> its own 'certificate' and signature format as even the standard >> asn.1 is too wasteful of the very limited channel. This applies >> also in 802.15.4 where adding another MAC frame might mean that the >> whole thing fails because now it is more likely that one frame got >> lost. >> >> 2) Easy/size of implementation. There has been lots of chatter >> here about how NIST p256 can be implemented wrongly. Here it is of >> greater concern, as it might require a physical swap-out to correct >> an implementation error. Manufacturers look at the cost of a >> programmer to save 5K code cheaper than that extra 5K footprint. >> So little code and easy to code. This world is extremely price >> sensitive. >> >> 3) Performance on an 8 bit processor. Performance is measured in >> time and energy. In-vehicle devices tend to have a ready source of >> electrons (except for tire gauges!), but some devices have limited >> battery (your front door lock) or NO battery (MEMEs energy >> harvesters on bridge stress sensors). So low energy is as >> important as quickly done. Here 10% faster IS 10% faster; and it >> could make a life-or-death difference. (In Positive Train Control, >> the automatics MUST take over if the human can no longer respond in >> time and bullet trains can take 7Km to stop safely) >> >> 4) preserving ECDSA and ECDHE. This is what is currently in use, >> and in some cases written into regulations (urgh), so we have to >> still keep them working. But if something 'new' and provably good >> makes a big difference in one of the previous needs I suspect there >> will be an attentive audience. >> >> I have tried to keep things general so as not too much to limit >> choices. I never claimed to be a crytographer or to have the math >> skills to evaluate the various contenders. Others working in this >> area might have their own reading on the needs of constrained >> devices/communications. >> >> But please just don't solve this for TLS on octo-core 64-bit >> systems. >> >> >> On 07/25/2014 01:10 AM, Benjamin Black wrote: >>> Inspired by some comments from other and in hopes of returning to >>> a more productive debate rather than the pointed back and forth, >>> of which I am absolutely guilty, I'm suggesting a few >>> constraints. These are not priority ordered and none of them deal >>> with the math, instead focusing on process and practice. >>> >>> 1) As we are discussing this in the context of TLS, the >>> performance of various kx options must be evaluated for ECDHE as >>> typically deployed. ECDH is neither common nor recommended in the >>> TLS BCP draft. In addition, I hope there will be discussion of >>> benchmarking methodology, with the understanding the ultimate >>> choice is for the CFRG chairs. >>> >>> 2) Performance must be measured using "production-quality" >>> implementations. By this I mean implementations which employ the >>> sort of techniques/optimizations appropriate for large scale >>> deployment. This is specifically intended to exclude discussion >>> of how simple or fast an implementation _could_ be, in favor of >>> what they actually are in practice. However, the goal is to >>> select curves which strike the best balance between various >>> requirements, not simply the fastest. >>> >>> 3) The timeframe for a decision constrains the scope of this >>> process. If a decision is desired within a few months, then it is >>> difficult to include options beyond new curves. If a decision can >>> take a year, new algorithms could be considered. Given the >>> importance, impact, and contentiousness of new algorithms, I >>> believe it would be difficult to complete a thorough, careful >>> algorithm and curve selection process in a short amount of time. >>> >>> 4) The precise set of security levels needed should be specified >>> in advance (whether by TLS or CFRG) and curve recommendations >>> delivered together for all levels. A stated goal is to use these >>> curves in new drafts, and it minimizes work to specify all >>> security levels for a proposal in the same draft. This is >>> strictly a practical matter recognizing the chairs and area >>> directors have limited bandwidth and implementors can get >>> everything done in a single go. >>> >>> 5) Selections must efficiently support TLS 1.2. Adoption of new >>> curves, and potentially new algorithms, can't be gated on >>> completion and widespread deployment of TLS 1.3. >>> >>> 6) Drop-in replacement for the NIST curves is _not_ a requirement >>> in this process. >>> >>> 7) I don't think the chairs are signing up for a full-on, >>> NIST-style selection competition and we should aim to keep things >>> are lightweight as possible while still achieving the required >>> level of rigor. I hope they will address this point soon. >> >> _______________________________________________ Cfrg mailing list >> Cfrg@irtf.org http://www.irtf.org/mailman/listinfo/cfrg > > _______________________________________________ Cfrg mailing list > Cfrg@irtf.org http://www.irtf.org/mailman/listinfo/cfrg >
- [Cfrg] Curve selection revisited Benjamin Black
- Re: [Cfrg] Curve selection revisited Yoav Nir
- Re: [Cfrg] Curve selection revisited Paterson, Kenny
- Re: [Cfrg] Curve selection revisited David Jacobson
- Re: [Cfrg] Curve selection revisited Watson Ladd
- Re: [Cfrg] Curve selection revisited Robert Ransom
- Re: [Cfrg] Curve selection revisited Watson Ladd
- Re: [Cfrg] Curve selection revisited Robert Ransom
- Re: [Cfrg] Curve selection revisited Robert Ransom
- Re: [Cfrg] Curve selection revisited Watson Ladd
- Re: [Cfrg] Curve selection revisited Andrey Jivsov
- Re: [Cfrg] Curve selection revisited Ilari Liusvaara
- Re: [Cfrg] Curve selection revisited Robert Ransom
- Re: [Cfrg] Curve selection revisited Robert Moskowitz
- Re: [Cfrg] Curve selection revisited Michael Hamburg
- Re: [Cfrg] Curve selection revisited Michael Jenkins
- Re: [Cfrg] Curve selection revisited Michael Hamburg
- Re: [Cfrg] Curve selection revisited Hannes Tschofenig
- Re: [Cfrg] Curve selection revisited Hannes Tschofenig
- Re: [Cfrg] Curve selection revisited Robert Moskowitz
- Re: [Cfrg] Curve selection revisited Stephen Farrell
- Re: [Cfrg] Curve selection revisited Michael Hamburg
- Re: [Cfrg] Curve selection revisited Robert Moskowitz
- Re: [Cfrg] Curve selection revisited Robert Moskowitz
- Re: [Cfrg] Curve selection revisited Robert Moskowitz
- Re: [Cfrg] Curve selection revisited Robert Moskowitz
- Re: [Cfrg] Curve selection revisited Michael Hamburg
- Re: [Cfrg] Curve selection revisited Robert Moskowitz
- Re: [Cfrg] Curve selection revisited Paul Lambert
- Re: [Cfrg] Curve selection revisited Paul Lambert
- Re: [Cfrg] Curve selection revisited Mike Hamburg
- Re: [Cfrg] Curve selection revisited Robert Ransom
- Re: [Cfrg] Curve selection revisited Andrey Jivsov
- Re: [Cfrg] Curve selection revisited Robert Ransom
- Re: [Cfrg] Curve selection revisited Robert Ransom
- Re: [Cfrg] Curve selection revisited Phillip Hallam-Baker
- Re: [Cfrg] Curve selection revisited Robert Moskowitz
- Re: [Cfrg] Curve selection revisited Russ Housley
- Re: [Cfrg] Curve selection revisited Salz, Rich
- Re: [Cfrg] Curve selection revisited Phillip Hallam-Baker
- Re: [Cfrg] Curve selection revisited Salz, Rich