Hi David, > I strongly encourage you to remove the "Compressed" point format. Doing > so will minimize the changes between RFC 5903 and make the draft easier to > support, and improve the overall implementation by making it simpler. > Also, it is not clear that there is any advantage to the "compressed" > format. It saves at most 64 bytes in total for a complete IKEv2 key > establishment, and since IKEv2 exchanges typically send a lot more data > than that, it sounds like a false economy to add complexity in order to > avoid a little bit of data.
I do not think that using point compression is complex. The rule, how to determine the representation of the KE payload (by bit length) is very simple and common crypto libraries like OpenSSL provide EC point expansion functions, so there is not much an implementation could do wrong. On the other hand, there may be environments where every byte savings counts. For instance, when using IPsec for communications between military radio equipment, bandwidth can be very limited. Another example could be implementation in embedded environments. For instance, I have talked with major car manufacturers who are really concerned about bandwidth limitations on their internal bus in the context of secure communication between control units. IKE is an option for such communications. Point compression is a quite common technique and supported by relevant ECC standards, i.e. ANSI X9.62/X9.63, IEEE P1363 and SEC, but also by many IETF standards like TLS, CMS, PKIX, SSH. IMHO, IKE should allow this option like TLS does. Actually for IKE, the bandwidth limitations may be more relevant than for TLS, where point compression is supported as well. > > The paragraph starting "The corresponding twisted curves ..." is a > distinct and self-contained topic. I suggest putting it into its own > section. > This is a good point, I will do this in the next revision. > > In some places, the draft gives [SEC1] as a normative reference, where > RFC6090 is also applicable (Sections 4.1 and 6 apply jn Section 2.2 of > draft-merkle-ikev2-ke-brainpool, for instance). > RFC 6090 does not define a FieldElement-to-OctetString conversion but only Integer-to-OctetString. In order to use a reference to RFC 6090, I would have to change the text to +++ ... by representing the field element as integer in the interval [0,p-1] and then using the Integer-to-OctetString conversion method specified in [RFC6090]... +++ This makes the whole sentence more difficult to comprehend. On the other hand, I do not see any advantage in pointing to RFC 6090 instead to SEC1. Johannes _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
