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

[Yoav Nir <[e-mail]>]

On Nov 8, 2012, at 4:24 PM, David McGrew (mcgrew) wrote:

> 
> 
> On 11/8/12 3:26 AM, "Johannes Merkle" <[e-mail]> wrote:
> 
>> 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.
> 
> What's the scenario here?   If hash + URL is sent, the certificate still
> has to be retrieved.  It might not be part of the IKE exchange, but moving
> it to HTTP doesn't mean that it doesn't contribute to bytes on the wire
> (or over the air, in the case of wireless).
> 

Since we tend to meet the same people all the time (or communicate with the same parties), usually the hash+URL would lead to retrieving the certificate from a cache, rather than from a remote web server.

Of course, if my implementation is running on a "thing", it doesn't have a cache and this argument doesn't apply.

Yoav