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

["Henderson, Thomas R" <[e-mail]>]

To clarify, the ENCRYPTED parameter is currently used (optionally) in only
one HIP message (the I2), to encrypt another HIP parameter (the initiator's
host identity):

http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-08#section-5.2.18 

I suppose that other uses could be invented for this parameter in the
future.

 

My sense of this issue is that OEAP is not required (we have symmetric keys
available at this point), but OEAP could be used, and opinions differ on
whether OEAP is the best technique for this.

 

- Tom

 

From: Blumenthal, Uri - 0668 - MITLL [mailto:[e-mail]] 
Sent: Thursday, June 14, 2012 8:21 AM
To: Blumenthal, Uri - 0668 - MITLL; Henderson, Thomas R; 'Igoe, Kevin M.';
[e-mail]
Cc: 'Robert Moskowitz'
Subject: Re: [Cfrg] HIP Help (I hope!)

 

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