Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange

[Tero Kivinen <[e-mail]>]

Johannes Merkle writes:
> I see your point, but I am not sure, if it is good to maintain a
> limitation of the previous RFCs for the new curves as 
> well. At least not, if we agree that point compression is a
> reasonable feature (which is still discussed below). 

Every single option adds complexity, so I do not think we should add
more optional things. 

> If using certificate-based authentication, probably the largest
> payload is the CERT. It contains a public key and a signature,
> which, when using the same curve as for KE, are (together) 3-4 times
> larger than a compressed KE payload. In addition, some smaller data
> fields as the DNs, algorithm identifiers, validity, serial, and some
> ASN.1 overhead. But according to RFC 5480 one can use point
> compression for the public key contained in the certificate as well,
> which means that the implementation must be able to handle this
> anyway.

You can replace X.509 cert in CERT payload with hash and url, which
will make the payload to be around 60 bytes or so depending on the
length of the url used (5 bytes for header + 20 bytes for hash, and 29
bytes for url in format of "http://123.123.123.123:1234/"). Bit more
if the URL has IPv6 address.

> I agree with you that the saving is small, but from what I have
> heard about constrained environment, even a saving below 10% can be
> desirable.

Not sending the CERT, but replacing it with hash and url offers much
bigger savings, and people are not even doing that.

> > More importantly, the TLS ECC RFC allows the
> > negotiation of supported point formats; only uncompressed format is a
> > MUST-implement (see Section 5.1.2 of RFC4492).  
> 
> That is a good point, but unfortunately in IKE, KE methods are not
> negotiated at all. This is not only an special issue for ECC or
> point compression. If the other peer does not understand the curve
> you are using or ECC at all, that you end up in INVALID_KE_PAYLOAD
> notification and have to re-try.

Note, that negotiating the use of point compression without retry or
not would waste more bytes then the point compression saves... The KE
payload is in the first packet, which means that to be able to
negotiate it beforehand would require one extra roundtrip. The IKEv2
headers + notify payloads etc would be 2 * (28 + 8 bytes) = 72 bytes
which is already quite big EC key Y part... 

> Yes, introducing point compression doubles the number of new
> possibilities to choose from: 8 instead of 4 in the case of the 4
> groups defined in the draft. But this number is still moderate.

I would prefer not to do that.

> As to the definition of separate transform IDs, I don't understand,
> why only this should allow point compression to be optional. The
> transform Id serves for identifying the group. The encoding
> (compressed or uncompressed) can be determined from the length of
> the KE payload and the group.

If I remember right the reason IKEv2 does not use point compression
for the current groups was that there was some IPR. Is that issue
already been cleared?
-- 
[e-mail]