Re: [IPsec] Using ECC Brainpool curves with ipsec

["David McGrew (mcgrew)" <[e-mail]>]

Hi Johannes,

On 7/3/12 11:59 AM, "Johannes Merkle" <[e-mail]> 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.
>
>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 think it could be reasonable to define new IKE groups based on RFC 5639.
 We need to avoid adding complexity to the IPsec RFC family and its
implementations, so it would be important to align the use of new groups
as much as possible to the existing uses of ECC in IKE, and to clarify the
intended use of the new IKE groups.  For instance, when should the new IKE
groups be used?   Which of the new groups is recommended for use?   What
other crypto algorithms should be used with each of those groups, to form
an acceptable security policy?   What are the technical merits of these
new groups?  I encourage you to take up these questions in your draft.

Ideally, any new ECP ECC groups would retain as much of RFC 5903 as
possible, such as Section 7 of that RFC, would include test cases, and
would be compatible with RFC 6090.


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

The important question here is: are the anticipated users of RFC 5639 in
IPsec able to use IKEv2?   Perhaps this could be considered in the draft
that you are planning.  I would guess that the answer for most would be
"yes".  

Currently, the main driver for the use of ECC in IPsec is RFC 6380, which
requires IKEv2.  

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

No objection, there are about 1000 values available, and using 14 seems
reasonable.  

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

Adding a new algorithm brings a lot more complexity than adding a new
group, and there should be some considerable technical justification put
forward before new algorithms get adopted.

I understand how ECGDSA avoids the modular inverse, but I do not
understand how that is a significant advantage for a signature algorithm
used in IKE.   When ECDSA is used in IKE, the computational effort of the
ECDSA modular inverse is small relative to the overall amount of
computation that is done.   Also, compact implementations of IKE would
want to minimize the number of new algorithms that they support.

Is there an expectation that users of RFC 5639 based groups in IKE would
also use of ECGDSA?  If not, then I encourage you to take up the ECGDSA
issue in a separate draft, so that the new group work could advance
independently.

Are the car manufacturers that you mention potential adopters of RFC 5639
in IKE?

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

I think compatibility with existing standards would make both the
implementations and the standards simpler, and should be the preferred
direction.   

It is true that there are limited-bandwidth scenarios in which compact
representation for ECDH might be interesting, but I am somewhat skeptical
that the bandwidth savings would be worth the deviation from existing
RFCs.  If the draft that you are preparing includes an option for compact
representation, I suggest that these potential bandwidth savings be
quantified and compared to the overall bandwidth used by IKE.

Regards,

David

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