Subject: [Hipsec] Manditory to implement Host ID Lengths

From: Robert Moskowitz <[email-masked]>
Date: Fri, 23 Apr 2010 14:20:28 -0400

I don't see any text on Manditory to implement Host ID lengths.  Kind of 
do what you think is right and we will probably get interoperability.  
Seems this is the one area we missed.

So what is the smallest RSA key size, what is manditory, and what is 
recommended?

Given that we had manditory DH-1536, is RSA 1536 the matching manditory 
Host ID length?  Or does DH-1536 match up with RSA 1024?

We recommend DH-3072, but go with RSA 2048?

I would REALLY like to have some reasonable recommendations here for RSA 
and DSA.

For ECDSA and ECDH, we are starting clean, and I **THINK** I have the 
literature figured out.  We will mandate p-256 and recommend p-384 for 
suite-b compliance.

Some help here, please, so I can finish up another loose end in 5201-bis.

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 23 Apr 2010 16:59:12 -0400

This leads to thoughts on cipher suites. See the end....

On 04/23/2010 02:20 PM, Robert Moskowitz wrote:
> I don't see any text on Manditory to implement Host ID lengths. Kind 
> of do what you think is right and we will probably get 
> interoperability. Seems this is the one area we missed.
>
> Given that we had manditory DH-1536, is RSA 1536 the matching 
> manditory Host ID length? Or does DH-1536 match up with RSA 1024?
>
> I would REALLY like to have some reasonable recommendations here for 
> RSA and DSA.
>

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.

---

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Tue, 27 Apr 2010 10:07:45 -0700

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

-Jeff

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 27 Apr 2010 13:32:49 -0400

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.
>>
>> 3 is Manditory. 1&  4 are recommended (1 for servers supporting weak

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

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 27 Apr 2010 14:04:37 -0400

> 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 fra…

Oh, and with the addtion of ECDSA, I will be recommending RSA key size 
maxlimit of 2048.  This is in line with NIST and NSA recommendations and 
with fECC, we SHOULD avoid IPR issues (unless you want the IPR 
algorithms for even greater efficiency).