Today it is fewer than 10%, but can't something close to that be said, at least recently, for AES?
With AES and its increased key sizes coming, shouldn't more EC groups be included? some with SHOULD for support of AES various key sizes and some additional MAYs? I believe consideration should be given to adding SECG's sect283k1 (a.k.a. 9th Oakley, ansit283k1), sect283r1 (8th, ansit283r1), sect409k1 (11th, ansit409k1), sect409r1 (10th, ansit409r1), sect571k1 (13th, ansit571k1), sect571r1 (12th, ansit571r1) to the draft, and perhaps secp256r1 (ansip256r1), secp384r1 (ansip384r1), and secp521r1 (ansip521r1). (See http://www.secg.org/collateral/sec2.pdf or ANSI 9.63)
> -----Original Message-----
> From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org]
> Sent: Monday, March 11, 2002 11:09 PM
> To: ipsec@lists.tislabs.com
> Subject: Remove SHOULD for elliptic curve groups in IKEv2
>
>
> Elliptic curve groups have barely been tested for interoperability.
> The SHOULDs in section 8.3 and 8.4 should be reduced to MAYs. As
> wonderful as EC cryptography is supposed to be, it is overkill to
> make it a near-requirement when probably fewer than 10% of
> implementations today use it.
>
> --Paul Hoffman, Director
> --VPN Consortium
>