Re: [IPsec] Using ECC Brainpool curves with ipsec

["Dan Harkins" <[e-mail]>]

  Hello,

On Tue, July 3, 2012 8:59 am, Johannes Merkle wrote:
> 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.

  I think that's a great idea.

> 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.

  I can't speak for the group but I would like to see an RFC that defines the
IANA considerations for using these curves in IKE. Informational is probably
fine unless the answer to question 2 below requires Standards Track.

> [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.

  Absolutely yes. There are still a lot of IKEv1 implementations out there
and also there are other protocols that use the IANA registry from IKEv1,
namely IEEE 802.11-2012. Any curve that you add to the IKEv2 registry
has to be added to the IKEv1 registry.

> [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.

  Hopefully that will be relaxed.

> [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?

  This seems reasonable. The body of the RFC will probably just be IANA
considerations. The domain parameter sets of the curves are already defined
so you just need to get IANA to allocate magic numbers for their use.

> [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?

  There's approximately 65k available assignments so this shouldn't be a
problem. Why would anyone want to do the untwisted version if the twisted on
is more efficient? Are there any IPR considerations to the twisted version?

> [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?

  Unless this got wider acceptance my personal take is: pass.

> [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?

  My preference would be to leave the KE payload alone.

  regards,

  Dan.

> Johannes
> --
> Johannes Merkle
> secunet Security Networks AG
> [e-mail]
> www.secunet.com
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>