Re: [IPsec] Using ECC Brainpool curves with ipsec

[Johannes Merkle <[e-mail]>]

Tero,

thank you for your valuable answers. Please find my responses below.

>> [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 might be good idea to get some usable elliptic curves too.
> The groups 19-21 is mostly unusable now as we messed up with their
> format in the original RFC4753 and they changes we made in RFC5903 are
> not backward compatible with the original RFC4753 and the
> interoperability problem just causes timeout on the initiator.

This is a good argument. Another one is that it is always advisable to have more than one curve per bit length just in
case that new cryptanalytic results point out weaknesses in one of them.  Moreover, the fact that the selection of the
seeds, from which the NIST curves have been generated, is not explained might also be considered as a missing link in
their property of being verifiably pseudo-random.

> 
>> [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.
> 
> I would be strongly against for including support for protocol which
> has been obsoleted 7 years ago. If people want to use this kind of
> groups in IKEv1 they can use the new group mode and negotiate groups
> on the fly. There is no need to add them to IKEv1.
> 

I have followed your dispute with Dan and do not take a clear position here as I have not your experience with
standardization of protocols. For me, IKEv1 does not have high priority, and I mainly aim at using the Brainpool curves
with 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.
> 
> Hmm... So you are talking adding them for both Diffie-Hellman and
> ECDSA uses?
> 
Yes, sorry for not stating this clearly. Why should an implementation use another parameter set for the signature as for
the key exchange unless the other peer doesn't support the primary parameters? In particular, implementations in
constraint environments would benefit from the option of using only a single set of domain parameters.


> Adding them for authentication use (ECDSA use) will most likely get
> more opposition. First of all, I am not at all happy how the ECDSA
> groups are added to the IKEv2 authentication method. The
> authentication methods registry is only 8-bit in IKEv2 (it is 16-bit
> registry in IKEv1). This does not matter if we have only few ECDSA
> groups with one hash algorithm for each, but when we are adding more
> groups it seems to bad idea for each of them having separate number.
> Especially if someone later decides that they want to use all ECDSA
> groups with SHA 3 too...

Today, I responded to Yoav's idea of taking algorithms details from the certificate. At least the EC domain parameters
could be taken from it, and for the hash function, a default could be defined per curve. So one new authentication
method ECDSA_generic or ECDSA_cert_defined could be sued for any EC domain parameters.


> 
> I think we should have made the ECDSA support for IKEv2 in such way
> that we had added some subfields to the authentication field, i.e.
> only allocated one value for ECDSA and put the curve number inside the
> authentication payload and perhaps even separated the hash algorithm
> from it. There is 3 bytes of reserved data in the authentication
> payload immediately after the auth method. Perhaps we could use those. 

Adding hash algorithm flexibility is of course a more general topic concerning not only ECDSA but also RSA and DSA. This
is out-of-scope of our endeavor and should be discussed separately.

> 
> It is most likely too late now, but we still want to make sure we do
> not allocate too many entries from that registry, i.e. is there need
> to add all the groups in there, do we really need that many different
> strengths? Which hash algorithm do we use with what group?
> 
> Also note, that authentication methods are not negotiated in IKEv2,
> i.e. there is no way to know whether the other end supports the
> authentication algorithm you wanted to use. On the other hand as you
> need to have credentials for the other end you are using, so most
> if other end would be accepting your authentication credentials it
> also supports the authentication method that needs to be used to use
> then.
> 
You touch the same point as Yoav, who pointed out that a generalized authentication method (e.g. ECDSA_generic) would
imply that the same certificate (for a key pair using one of the NIST curves listed in RFC 4754) could be used ith two
different authentication methods. Yoav has suggested to indicate support for the general method in the Notify payload,
another option could be to introduce a new transform type AUTH, so that support for this AUTH method is indicated in the
SA payload. Again, this is a protocol extension that exceeds our intended scope, and should be specified separately.

An alternative to avoid the interoperability problems with existing implementations of RFC 4754 could be to require that
ECDSA_generic MUST not be used for the curves listed in RFC 4754, or that implementations encountering authentication
failures by the other peer MUST re-try using the "old" authentication methods from RFC 4754.

> On the IKEv1 there is another problem. The authentication method is
> negotiated (in main mode), but it MUST be same for both directions, so
> both ends must support same types of credentials. Also as you pointed
> out the authentication algorithgms registry for IKEv1 is still
> Standard track RFC required and there has been multiple people in the
> WG opposing to changing it.
> 
After following your discussion with Dan I doubt that a WG consensus can be achieved on this issue. But as I said, IKEv1
is of minor importance for me.


> So adding support for authentication methods do require more work for
> both IKEv1 and IKEv2.
> 
I think my proposal (based on Yoav's idea) of introducing a generalized ECDSA authentication method could do the trick,
as long as the potential conflict with existing RFC 4754 implementations are not considered a no-go.


>> [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?
> 
> I would suggest writing separate RFCs for TLS. It might seem like good
> idea to write only one RFC, but that just causes confusion to the
> actual users of the RFC. They are either TLS or IPsec implementors,
> and it is confusing if you are not using the same terms which are
> already used in those protocols.
> 

This argument seems very reasonable.

> 
>> [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 $,1r|(Bquadratic
>> twist$,1r}(B of the other $,1rs(B 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?
> 
> For Diffie-Hellman groups with 16-bit registry, no. For the
> Authentication Algorithms registry with only 8-bit registry, yes. On
> the other hand if we do take those reserved fields in to use in the
> IKEv2 authentication payload and put the parameters there then I see
> no reason to limit the number of groups. 

This issue would be solved by the generic ECDSA method.

> 
>> [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?
> 
> I think it might be good idea for IKEv2 (and bad idea for IKEv1), but
> at least there I think we should add it differently than what is done
> for the current ECDSA code, i.e not make separate number for each
> group (which would be 28 (i.e. >10% of the whole registry) if we add
> all 7 strengths with 2 formats and each with both ECDSA and ECGDSA).
> 

Again, a generalizes ECGDSA method would achieve exactly what you indicate. Only one additional assignment.

>> [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 have been under impression that the point compression is one of
> those items which are patented and that is the reason why it is not

This is not an issue. According to http://cr.yp.to/patents/us/6141420.html the patent is almost certainly invalid
because its authors revealed the (known) existence of prior art to the patent office, and furthermore, the patent
expires in 2014.

> been used in the IKEv2. Also as I said earlier the authentication
> methods are not negotiated, thus if one ends send KE payload in point
> compressed format and other end does not implement point compression
> because of licensing reasons they cannot talk to each other.
> 

I am not talking about authentication but about key exchange. For authentication, no point compression can be applied,
as an ECDSA signature dies not represent a point on the curve but only to integers (mod the group order).

But I admit that there might be an issue when an implementation not supporting point compression receives a KE payload
of unexpected length. This might lead to undesired behavior. Thus, it might be necessary to use separate group
descriptions when using point compression. But I have not sufficient experience with implementations to assess that.

Johannes