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

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 13 Jun 2012 14:28:06 -0700

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

> Henderson, Thomas R

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

> To: [email-masked]'

> 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: [email-masked]'

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

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

---

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Thu, 14 Jun 2012 11:12:32 -0400

> Kevin and all, ŠŠŠŠ..
>         DSA              3 [RFC2536 <http://tools.ietf.org/html/rfc2536> ]
> (RECOMMENDED)
Considering Suite B, I am not sure I'd still recommend DSA.
>         RSA              5 [RFC3110 <http://tools.ietf.org/html/rfc3110> ]
> (REQUIRED)
Well, I'd move from RSA, but I recognize the reality  megatons of
already-deployed RSA code and certsŠ
>         ECDSA            7 [RFC4754 <http://tools.ietf.org/html/rfc4754> ]
> (RECOMMENDED)
Yes, and I'd consider elevating ECDSA to REQUIRED, to facilitate and
encourage the move.
>         ECDSA_LOW        9 [SECG
> <http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-08#ref-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
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):
> 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: [email-masked] [mailto:[email-masked]] On Behalf Of
Igoe, Kevin M.
Sent: Monday, May 14, 2012 11:55 AM
To: Igoe, Kevin M.; [email-masked]
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.

---

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Thu, 14 Jun 2012 11:20:45 -0400

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

> Yes, and I'd consider elevating ECDSA to REQUIRED, to facilitate and encourage
> the move.
>>         ECDSA_LOW        9 [SECG
>> 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?
> 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).

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 14 Jun 2012 08:47:38 -0700

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:[email-masked]] 
Sent: Thursday, June 14, 2012 8:21 AM
To: Blumenthal, Uri - 0668 - MITLL; Henderson, Thomas R; 'Igoe, Kevin M.';
[email-masked]
Cc: 'Robert Moskowitz'
Subject: Re: [Cfrg] HIP Help (I hope!)

-- 

Regards,

 

Kevin and all, ......

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

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

        ECDSA_LOW        9 [SECG

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.

  3DES-CBC           3     ([RFC2451])

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

Why not. :)