Re: [Hipsec] Manditory to implement Host ID Lengths

[Robert Moskowitz <[e-mail]>]

On 04/27/2010 01:07 PM, Ahrenholz, Jeffrey M wrote:
>    
>>> Some help here, please, so I can finish up another loose
>>>        
>> end in 5201-bis.
>>
>> Here are some proposed cipher suites. Using RFCs 4308 and 4869 as
>> guidelines...
>>
>> HIP BEX Cipher suites:
>>
>> Suite Host_ID Diffie_Hellman Hash Recommended HIP-Transform
>>
>> 1 ECDSA-160 ECDH-160 SHA1 AES-128-CBC with HMAC-SHA1 or 3DES-CBC with
>> HMAC-SHA1
>> 2 RSA 1024 DH-1536 SHA1 AES-128-CBC with HMAC-SHA1 or 3DES-CBC with
>> HMAC-SHA1
>> 3 RSA-2048 DH-3072 SHA-256 AES-128-CBC with HMAC-SHA2 or AES-CCM-8
>> 4 ECDSA-256 ECDH-256 SHA-256 AES-256-CBC with HMAC-SHA2 or
>> AES-CCM-16 or
>> AES-GCM with a 16 octet ICV
>> 5 ECDSA-384 ECDH-384 SHA-384 AES-256-CBC with HMAC-SHA2 or
>> AES-CCM-16 or
>> AES-GCM with a 16 octet ICV
>>
>> 3 is Manditory. 1&  4 are recommended (1 for servers supporting weak
>> clients)? 5 is for Suite-B.
>>      
> These suites seem OK to me. Hopefully the above are well supported by OpenSSL or other libraries. We've been using 2 as the default with HIPv1 (RSA 1024 / DH-1536).
>
> It should be noted, with HIPv1 and an MTU size of 1500, that using large keys of RSA 4096 + DH-1536 will cause a 1458 byte I2 packet (proto 139 without UDP), and using RSA 4096 + DH-3072 causes fragmentation of the I2. That leads to problems (bugs?) at least with our OpenHIP implementation.
>    

p-384 gives you a greater strength at a smaller size with a much lower 
CPU cost.  For example see:

http://www.nsa.gov/business/programs/elliptic_curve.shtml

Yet another reason to move to EC.

Per Dave McGrew back on /4/9:

"so far, nobody has published software that specifically targets this 
draft.   The openssl implementation of ECC could be used as something 
interoperable (though it implements a lot more than just the fECC subset 
of ECC)."

We do need to get the OpenSSL authors looking at this draft....