Re: [Cfrg] advice about best current practices for HIP

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

Hi, I was wondering if anyone was going to be able to respond to the below questions, or if we should proceed otherwise.

- Tom

> -----Original Message-----
> From: Henderson, Thomas R
> Sent: Tuesday, April 24, 2012 5:03 PM
> To: '[e-mail]'
> Cc: 'Tobias Heer'; 'Robert Moskowitz'
> Subject: advice about best current practices for HIP
> 
> 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