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

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

Kevin and all,

Here is an attempted rollup of the advice that I received; if no other comments, I'll take this back to the HIP WG.  I'm summarizing this below in the hopes that it could be sanity checked by CFRG.

To recap, we were asked by the IESG to consider the use of OEAP and PSS in HIP.  In the course of this discussion, some other suggestions were made.

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)
        RSA              5 [RFC3110<http://tools.ietf.org/html/rfc3110>] (REQUIRED)
        ECDSA            7 [RFC4754<http://tools.ietf.org/html/rfc4754>] (RECOMMENDED)
        ECDSA_LOW        9 [SECG<http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-08#ref-SECG>]    (RECOMMENDED)

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.

The hash used for RSA and DSA signature is SHA-256, so I don't think any change is needed there.

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

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

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

Thanks for the feedback so far,
Tom


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.

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.

From: [e-mail] [mailto:[e-mail]] On Behalf Of Igoe, Kevin M.
Sent: Monday, May 14, 2012 9:35 AM
To: [e-mail]
Subject: [Cfrg] HIP Help (I hope!)


I do have an obvious observation on the use of DSA.



In SP-800-131A, NIST states that for signing, a 1024 bit DSA modulus with a 160-bit subgroup is acceptable through 2010, deprecated from 2011 through 2013, and disallowed after 2013. While we are not bound by NIST's authority, I for one feel it would be prudent to follow their lead.

(SP-800-131A= http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf )



RFC 5114  [Additional Diffie-Hellman Groups for Use with IETF Standards] provides an alternative to 1024-bit/SHA1 DSA.  Sections 2.2 and 2.3 lists 2048 bit groups suitable for use with DSA/SHA2-224 and DSA/SHA2-256 respectively. Is either of these this in the latest version of openSSL?  In all the excitement, I've kinda lost track myself.



Comments anyone?





Anyone with comments on the padding?  My gut instinct so  to keep it as simple as possible, avoid defining new key types & use as much pre-existing code as possible. Dare to be consistent!





<impassioned_plea>

We could really use some input here from folks with concrete experience on the

padding issues!  Speak now or forever hold your peace.

</impassioned_plea>



P.S. I'm impressed by the amount of detailed work that went into this draft.

Well done!





> -----Original Message-----

> From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]<mailto:[mailto:[e-mail]]> On Behalf Of

> Henderson, Thomas R

> Sent: Friday, May 11, 2012 10:30 AM

> To: '[e-mail]'

> Cc: 'Robert Moskowitz'

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

>

> 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

> _______________________________________________

> Cfrg mailing list

> [e-mail]<mailto:[e-mail]>
> http://www.irtf.org/mailman/listinfo/cfrg