Re: [Cfrg] HIP Help (I hope!)

["Blumenthal, Uri - 0668 - MITLL" <[e-mail]>]

Oops, just noticed that this seems to be about transporting the keys. Sorry!
Yes, RSA-OAEP is very good for that (though my argument about not using RSA
if you already have a symmetric key established still holds). You may also
consider ECIES instead of or in addition to RSA, to support Elliptic Curve
suite.
-- 
Regards,
Uri Blumenthal                            Voice: [phone]


>> Kevin and all, ŠŠŠŠ..
>> For the keys used in HIP themselves (used for signing/authentication), HIP
>> specifies these types:
>>         DSA              3 [RFC2536 <http://tools.ietf.org/html/rfc2536> ]
>> (RECOMMENDED)
> Considering Suite B, I am not sure I'd still recommend DSA.
>>         RSA              5 [RFC3110 <http://tools.ietf.org/html/rfc3110> ]
>> (REQUIRED)
> Well, I'd move from RSA, but I recognize the reality ­ megatons of
> already-deployed RSA code and certsŠ
>>         ECDSA            7 [RFC4754 <http://tools.ietf.org/html/rfc4754> ]
>> (RECOMMENDED)
> Yes, and I'd consider elevating ECDSA to REQUIRED, to facilitate and encourage
> the move.
>>         ECDSA_LOW        9 [SECG
>> <http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-08#ref-SECG> ]
>> (RECOMMENDED)
> I would drop ECDSA_LOW altogether.
> 
>> The feedback that I received was to follow NIST 800-131A on key strength
>> regarding all of these key types, and to consider not using ECDSA_LOW.  We'd
>> like to retain ECDSA_LOW, suitably caveated ("defined for devices with low
>> computational capabilities").  For DSA, we could replace the existing
>> reference to a reference to FIPS 186-3 and also reference RFC 5114 2.3 with
>> 2048-bit subgroups for use with SHA2-256.
> At the very least. SHA3 should come out some time this year ­ do you care to
> waitŠ?
> 
>>  The hash used for RSA and DSA signature is SHA-256, so I don't think any
>> change is needed there.
> It should be sufficient, based on what we currently know.
> 
>>  For RSA signature padding, the RSAASA-PSS [RFC3447] should replace the
>> reference to RFC3110 above, and explicitly state that PSS instead of PKCS1.5
>> padding is used.  I am not sure whether we need to state anything about
>> padding for other signature types (guidance here would be helpful).
> I'll let others comment on this.
> 
>>  Regarding OAEP, currently HIP specifies these ciphers for use in the
>> ENCRYPTED parameter (used to encrypt small blocks of data):
>>    AES-128-CBC        2     ([RFC3602])  required
>>   3DES-CBC           3     ([RFC2451])
>>   AES-256-CBC        4     ([RFC3602])
>>  
>> I believe that we are being asked to also support RSA-OAEP here (RFC 4055).
>> Would specifing an additional (non-required) option for RSAES-OAEP
>> ([RFC4055]) suffice, or is OAEP a preferred technique for encrypting
>> parameters over AES-128-CBC?
> RSA-OAEP as a preferred technique to encrypt what? For passing along AES and
> other cryptographic keys ­ sure, it's a great mechanism. To encrypt data
> chunks (large or small) if/when you already have an AES key established
> between the parties ­ no way. To infrequently send small things when you don't
> have a symmetric key established ­ if you want to be 10% stateless, then yes,
> RSA-OAEP would do the job; but if you can afford setting up a symmetric
> channel and/or plan on exchanging a whole bunch of these small things ­ you're
> better off not using RSA-OAEP for data transfer...
>>   Also, I understand that we ought to consider clarifying that 3DES-CBC is
>> the three-key variant (NIST 800-131A), or removing it altogether (which I
>> think is what you advocated below).
> I would just remove it, as I see no purpose in carrying 3DES over.
> 
>>  Regarding encryption padding, the current draft specifies to use whatever
>> padding is specified by the encryption algorithm, citing PKCS5 for AES, and
>> not mentioning 3DES-CBC padding (in practice, our implementation also pads
>> this according to PKCS5).
> Why notŠ :)