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

[Johannes Merkle <[e-mail]>]

Hi Tero,

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

Point compression is not the focus of our draft. Given the opposition it is facing here, I suggest to wait for further
replies and if point compression turns out to be objected by the majority on this list, I will not insist on this feature.
BTW: In an earlier thread Dan Haskins has already indicated his preference to leave point compression out.

> 
> Not sending the CERT, but replacing it with hash and url offers much
> bigger savings, and people are not even doing that.
You can not be sure that this option isn't used is some constrained environments.

Just a note: the relative saving of point compression is larger when sending hash + URL instead of the CERT.

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

What I had in mind are constraint environments where using bandwidth saving techniques like point compression can be
assumed to be the default.


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

The the patent expires in 2014.
http://cr.yp.to/patents/us/6141420.html

-- 
Johannes