[Cfrg] HIP Help (I hope!)

["Igoe, Kevin M." <[e-mail]>]

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]] 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]

> http://www.irtf.org/mailman/listinfo/cfrg