headers
Igoe, Kevin M. | 14 May 2012 15:35
Picon

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: cfrg-bounces <at> irtf.org [mailto:cfrg-bounces <at> irtf.org] On Behalf Of

> Henderson, Thomas R

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

> To: 'cfrg <at> irtf.org'

> 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: 'cfrg <at> irtf.org'

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

> Cfrg <at> irtf.org

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

_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg
Permalink | Reply |
headers
Igoe, Kevin M. | 14 May 2012 20:55
Picon

Re: 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: cfrg-bounces <at> irtf.org [mailto:cfrg-bounces <at> irtf.org] On Behalf Of Igoe, Kevin M.
Sent: Monday, May 14, 2012 9:35 AM
To: cfrg <at> irtf.org
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: cfrg-bounces <at> irtf.org [mailto:cfrg-bounces <at> irtf.org] On Behalf Of

> Henderson, Thomas R

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

> To: 'cfrg <at> irtf.org'

> 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: 'cfrg <at> irtf.org'

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

> Cfrg <at> irtf.org

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

_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg
Permalink | Reply |
headers
Henderson, Thomas R | 13 Jun 2012 23:28
Picon
Favicon

Re: HIP Help (I hope!)

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] (RECOMMENDED)

        RSA              5 [RFC3110] (REQUIRED)

        ECDSA            7 [RFC4754] (RECOMMENDED)

        ECDSA_LOW        9 [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: cfrg-bounces <at> irtf.org [mailto:cfrg-bounces <at> irtf.org] On Behalf Of Igoe, Kevin M.
Sent: Monday, May 14, 2012 11:55 AM
To: Igoe, Kevin M.; cfrg <at> irtf.org
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: cfrg-bounces <at> irtf.org [mailto:cfrg-bounces <at> irtf.org] On Behalf Of Igoe, Kevin M.
Sent: Monday, May 14, 2012 9:35 AM
To: cfrg <at> irtf.org
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: cfrg-bounces <at> irtf.org [mailto:cfrg-bounces <at> irtf.org] On Behalf Of

> Henderson, Thomas R

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

> To: 'cfrg <at> irtf.org'

> 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: 'cfrg <at> irtf.org'

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

> Cfrg <at> irtf.org

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

_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg
Permalink | Reply |
headers
Blumenthal, Uri - 0668 - MITLL | 14 Jun 2012 17:12
Picon

Re: HIP Help (I hope!)

Kevin and all, …………..

For the keys used in HIP themselves (used for signing/authentication), HIP specifies these types:

        DSA              3 [RFC2536] (RECOMMENDED)

Considering Suite B, I am not sure I'd still recommend DSA.

        RSA              5 [RFC3110] (REQUIRED)

Well, I'd move from RSA, but I recognize the reality – megatons of already-deployed RSA code and certs…

        ECDSA            7 [RFC4754] (RECOMMENDED)

Yes, and I'd consider elevating ECDSA to REQUIRED, to facilitate and encourage the move.

        ECDSA_LOW        9 [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… :)


From: cfrg-bounces <at> irtf.org [mailto:cfrg-bounces <at> irtf.org] On Behalf Of Igoe, Kevin M.
Sent: Monday, May 14, 2012 11:55 AM
To: Igoe, Kevin M.; cfrg <at> irtf.org
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.

If you have a hammer, the whole world starts looking like a nail. :)

 

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.

I concur.
Attachment (smime.p7s): application/pkcs7-signature, 5124 bytes
_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg
Permalink | Reply |
headers
Blumenthal, Uri - 0668 - MITLL | 14 Jun 2012 17:20
Picon

Re: 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: (781) 981-1638


Kevin and all, …………..

For the keys used in HIP themselves (used for signing/authentication), HIP specifies these types:

        DSA              3 [RFC2536] (RECOMMENDED)

Considering Suite B, I am not sure I'd still recommend DSA.

        RSA              5 [RFC3110] (REQUIRED)

Well, I'd move from RSA, but I recognize the reality – megatons of already-deployed RSA code and certs…

        ECDSA            7 [RFC4754] (RECOMMENDED)

Yes, and I'd consider elevating ECDSA to REQUIRED, to facilitate and encourage the move.

        ECDSA_LOW        9 [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… :)
Attachment (smime.p7s): application/pkcs7-signature, 5124 bytes
_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg
Permalink | Reply |
headers
Henderson, Thomas R | 14 Jun 2012 17:47
Picon
Favicon

Re: HIP Help (I hope!)

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:uri <at> ll.mit.edu]
Sent: Thursday, June 14, 2012 8:21 AM
To: Blumenthal, Uri - 0668 - MITLL; Henderson, Thomas R; 'Igoe, Kevin M.'; cfrg <at> irtf.org
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: (781) 981-1638

 

 

Kevin and all, …………..

For the keys used in HIP themselves (used for signing/authentication), HIP specifies these types:

        DSA              3 [RFC2536] (RECOMMENDED)

Considering Suite B, I am not sure I'd still recommend DSA.

        RSA              5 [RFC3110] (REQUIRED)

Well, I'd move from RSA, but I recognize the reality – megatons of already-deployed RSA code and certs…

        ECDSA            7 [RFC4754] (RECOMMENDED)

Yes, and I'd consider elevating ECDSA to REQUIRED, to facilitate and encourage the move.

        ECDSA_LOW        9 [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… :)

Attachment (smime.p7s): application/x-pkcs7-signature, 6420 bytes
_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg
Permalink | Reply |

Gmane