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

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

> 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Š :)


From: [e-mail] [mailto:[e-mail]] On Behalf Of
Igoe, Kevin M.
Sent: Monday, May 14, 2012 11:55 AM
To: Igoe, Kevin M.; [e-mail]
Subject: Re: [Cfrg] HIP Help (I hope!)
 
I did some double checking with  some certificate guru¹s & they agree that
RSA-OAEP is precisely what you should be using.
If you have a hammer, the whole world starts looking like a nail. :)

 I¹ve also had some discussions about HIP¹s use of 3DES.  It will be
difficult to uproot once it has been fielded, so it might be prudent to
remove it now.  The same applies to DSA SHA1/2048 and ECDSA_low.
I concur.