Dan, thanks for your reply. You happen to be the first one. See my comments below.
>> [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. This is also our perception but we would prefer a WG consensus on that. > >> [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? A similar question has been raised as response to my analogous posting on the tls mailing list. The reason why some people might prefer the "normal" curves is that for these it is easier to avoid patents. This is always a big issue with ECC. While the Brainpool curves avoid special primes to facilitate patent-free implementations, we still wanted to leave the implementors a choice between "fast" and "slower but more patent-safe" by introducing the quadratic twist. > >> [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. So, you mean not to allow point compression? Our proposal is *not* to change the KE payload syntax but only to allow variation in its bit length and to define rules for interpretation depending on its length. This means merely an extension of the rules defined for the NIST curves (RFC 5903), not a contradiction. BTW: TLS explicitly allows point compression. Johannes -- Johannes Merkle secunet Security Networks AG [email protected] www.secunet.com
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
