Hi, in RFC 5639, we have specified a new set of elliptic curve parameters for use in cryptographic applications. Meanwhile, support for these "Brainpool Curves" has been included in some crypto libraries as openssl (recently) and crypto++. However, in order to use the Brainpool Curves with IKE and IPSec, still some specifications and IANA registry updates are needed. We are now planning to prepare such an RFC to allow usage of the ECC Brainpool curves with ipsec.
In order to go forward with this effort, we would like to discuss some questions and potential issues. The WG feedback on these is most appreciated. [Question 0] Is the WG interested in shepherding an RFC specifying all that's necessary to use the Brainpool curves in ipsec? And what category would be preferred, standard track or informational. [Question 1] Should we include IKEv1 in the specs as well? It seems that some people in the WG do not like the idea of updating this obsolete protocol. On the other hand, many applications still use IKEv1 and specifying the use of the Brainpool curves only for IKEv2 would exclude these. [Question 2] If IKEv1 is to be considered, the registry for IPSEC Authentication Methods (Value 3) needs to be updated, because the values for ECDSA are specific for each curve. What policy for updating this IANA registry can be assumed? IANA currently requires a standard track RFC, but there has recently been some discussion on relaxing this, in particular, http://www.ietf.org/mail-archive/web/ipsec/current/msg07428.html and http://www.ietf.org/mail-archive/web/ipsec/current/msg07654.html . For the corresponding IKEv2 registry (Auth Method), only Expert Review is required. [Question 3] If IKEv1 is to be considered, it seems reasonable to write only one RFC covering IKEv1 and IKEv2. Actually, we also plan to prepare analogous specifications for TLS, so an option would be to write a common RFC for IKE and TLS analogously to RFC 5114. However, according to the update policy of the IANA registry EC Named Curve for TLS, such an RFC would have to be shepherded by the tls WG. Does this prevent or considerably complicate the creation of a joint RFC for IKE and TLS? Would preparing separate RFCs for IKE and TLS be preferable? [Question 4] In RFC 5639, for each of the bit lengths 160, 192, 224, 256, 320, 384, 512 two curves are defined, one being the “quadratic twist” of the other – their algebraic structure (and hence, security level) is equivalent, but one of them allows particular efficient arithmetic. In order to leave the choice of the curve for a given bit length to the implementation we propose to register IANA values (for Auth method and Diffie-Hellman Group) for both curves for each bit length. Of course, this doubles the number of number assignments. Any objections on this? [Question 5] In Germany, not only ECDSA is in use with IKE and IPSec but also ECGDSA (Elliptic Curve German Digital Signature Algorithm) according to ISO 14888-3, which is a slight variant of ECDSA. The advantage of ECGDSA over ECDSA is that signature generation does not need any inversion modulo the group order, which removes the necessity of corresponding code. This advantage is particularly interesting when using devices with limited computation power and storage like smart cards or electronic control units in cars. In particular, car manufacturers have expressed their desire to deviate from EDSA For this reason, we would like to specify values for ECGDSA (with the individual bit lengths and curves) as Authentication Method as well. Would the WG support inclusion of this additional signature algorithm? [Question 6] In cryptographic applications using elliptic curves, point compression (see Section 4.2 in RFC 6090) is frequently used in particular in environments with limited bandwidth and storage capacity. However, in IKE this mechanism is currently not supported as, according to RFC 5903, the KE payload consists of the concatenation of two components, x and y, each of which having the same length as the underlying finite field. We propose to add support for point compression for the KE Payload to IKE by allowing also the use of a compressed form of x, e.g. of 64 bits, representing only the least significant bit. In contrast to the (obsolete) draft-ietf-ipsec-ike-ecc-groups-10, RFC 5903 does not specify a data format for the ECDH KE payload in which the uncompressed form is explicitly specified (e.g. in a leading byte), uncompressed and compressed form could only be implicitly distinguished by their bit length (as specified in the KE header). Does this raise any issue with implementations? What are your opinions and preferences? Johannes -- Johannes Merkle secunet Security Networks AG johannes.mer...@secunet.com www.secunet.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
