[Cfrg] advice about best current practices for HIP

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

Hello, I'm one of the authors working on revising HIP [*], and I would like advice on how to respond to an IESG comment on RFC5201.

The IESG comment in the experimental specification for HIP reads as follows:

   HIP defines the usage of RSA in signing and encrypting data.  Current
   recommendations propose usage of, for example, RSA OAEP/PSS for these
   operations in new protocols.  Changing the algorithms to more current
   best practice should be considered.

This comment was made over four years ago, and I'm not an expert on cryptography, so I thought I'd check with the CFRG for advice on how to respond now.

1) signature padding

Presently, the HIP draft specifies these algorithms for keys (section 5.2.9 of the draft):

        DSA              3 [RFC2536] (RECOMMENDED)
        RSA              5 [RFC3110] (REQUIRED)
        ECDSA            7 [RFC4754] (RECOMMENDED)
        ECDSA_LOW        9 [SECG]    (RECOMMENDED)

However, the specification of how to compute the signature is somewhat vague:

   3.  Compute the signature using the private key corresponding to the
       Host Identifier (public key).

I believe that, in practice, whatever default padding was provided by OpenSSL RSA_sign() has been used (I believe it to be PKCS#1 v1.5).  I'm wondering whether the way to address this comment is to mandate that, when signatures are computed, and RSA is the key type, the RSAASA-PSS [RFC3447] method of padding is required, and to replace the reference to RFC3110 above with RFC3447.

The above discussion is limited to RSA.  Do we need signature specifications for all of these key types, or is it well implied for the other key types how to perform the signatures?

2) encryption padding

HIP uses a block cipher to generate ENCRYPTED parameters, using encryption keys generated by the Diffie Hellman exchange.  In practice, the Host Identity (a public key) may be encrypted for privacy in the I2 message.

These ciphers are specified for HIP (section 5.2.8 of the draft): 

        AES-128-CBC        2     ([RFC3602])
        3DES-CBC           3     ([RFC2451])
        AES-256-CBC        4     ([RFC3602])

The draft specifies also 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).

I understand that RSAES-OAEP is a padding technique for key transport in particular.  However, HIP does not specify RSA for encryption, and does not use 'key transport' mode but rather 'data encryption' mode.  Does RSAES-OAEP apply in this case?  Should HIP be considering another best practice algorithm for doing this?

In closing, an important consideration for our implementations is availability in OpenSSL, so required algorithms should be supported there.

Thanks,
Tom

[*] http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-08