Subject: Re: [Hipsec] rfc5201-bis issue 29: Use different RSA mode OAEP/PSS

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 18 Jun 2012 23:07:07 -0700

This message picks up a thread from April regarding one of our last remaining open issues against RFC5201-bis.

I started some discussion on the crypto-forum research group (CFRG) list about how to handle this comment from RFC 5201:

   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.

There were a few suggestions offered specific to RSA OAEP/PSS.  In the course of the discussion, some other suggestions were made.  I'll try to summarize below.

For the keys used in HIP, RFC5201bis 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.  There was also a suggestion to elevate ECDSA to REQUIRED, to encourage movement to that key type.  I believe that 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 section 2.3 with 2048-bit subgroups for use with SHA2-256.  Any opinions on either clarifying these constraints on DSA keys, or dropping their support entirely?  I am somewhat neutral about elevating ECDSA to REQUIRED, but might lean towards accepting the CFRG suggestion here; would this cause anyone any pain?

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 key types; suggestions on this point 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])

One piece of feedback was a recommendation to drop 3DES-CBC altogether; any concern about that?

I believe that the IESG note is suggesting to support RSA-OAEP here (RFC 4055).  OEAP is an RSA public key-based encryption (used for key transport but also for small blocks of data), while the AES-CBC ciphers are based on the symmetric keys drawn from the keymat.   I believe we could handle this comment a few ways:
1) we could choose to not adopt this method, since we have symmetric keys available, and stick with AES-CBC only
2) we could add RSA-OAEP (RFC 4055) as either optional or required
3) we could also consider ECIES if we are considering RSA-OAEP, to provide similar capability for EC keys; this was also suggested on the CFRG list

I did not sense that there was a strong opinion on what to do here, other than agreeing that RSA-OAEP would be a good fit for this ENCRYPTED parameter function.  Any other opinions from the HIP list?

- Tom

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Henderson, Thomas R
> Sent: Tuesday, April 17, 2012 9:53 PM
> To: 'Tobias Heer'
> Cc: HIP
> Subject: Re: [Hipsec] rfc5201-bis issue 29: Use different RSA mode
> OAEP/PSS
> 
> 
> 
> > -----Original Message-----
> > From: Tobias Heer [mailto:[email-masked]]
> > Sent: Tuesday, April 17, 2012 12:20 AM
> > To: Henderson, Thomas R
> > Cc: HIP
> > Subject: Re: [Hipsec] rfc5201-bis issue 29: Use different RSA mode
> > OAEP/PSS
> >
> > Hi,
> >
> > Am 22.03.2012 um 11:39 schrieb Henderson, Thomas R:
> >
> > > This is the specific IESG comment:
> > >
> > >   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.
> > >
> > > RFC 4055 defines RSASSA-PSS and RSAES-OAEP keys.  Were these ever
> > discussed/considered as HIP key formats?
> > I cannot remember any discussion related to this.
> >
> > > This might be addressed by defining these as new algorithms in
> 5201-
> > bis.
> > I agree. One could easily define a new suite. We could do that now or
> > on demand. We need a new suite anyway to stay somewhat compatible
> with
> > the existing HIP implementations.
> 
> Since there were no other comments, I will try to move this forward by
> generating a text proposal.
> 
> - Tom
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 26 Jun 2012 22:10:24 -0700

Regarding this open issue, which I posted about on June 18 [*], I propose the following changes to the RFC 5201-bis text:

1) Section 3

OLD TEXT:

   HIP implementations MUST support the Rivest Shamir Adelman (RSA)
   [RFC3110] public key algorithm, and SHOULD support the Digital
   Signature Algorithm (DSA) [RFC2536] algorithms, and Elliptic Curve
   Digital Signature Algorithm (ECDSA) for generating the HI as defined
   in Section 5.2.9.  Additional algorithms MAY be supported.

NEW TEXT:

   HIP implementations MUST support the Rivest Shamir Adelman (RSA)
   [RFC3110] public key algorithm and Elliptic Curve
   Digital Signature Algorithm (ECDSA) for generating the HI as defined
   in Section 5.2.9.  Additional algorithms MAY be supported.

2) Section 5.2.8, HIP cipher

OLD TEXT:

   The following Cipher IDs are defined:

        Suite ID           Value

        RESERVED           0
        NULL-ENCRYPT       1     ([RFC2410])
        AES-128-CBC        2     ([RFC3602])
        3DES-CBC           3     ([RFC2451])
        AES-256-CBC        4     ([RFC3602])

NEW TEXT:

   The following Cipher IDs are defined:

        Suite ID           Value

        RESERVED           0
        NULL-ENCRYPT       1     ([RFC2410])
        AES-128-CBC        2     ([RFC3602])
        DEPRECATED         3     
        AES-256-CBC        4     ([RFC3602])

3) Section 5.2.9, Host Id:

OLD TEXT:  

   The following HI Algorithms have been defined:

        Algorithm
        profiles         Values

        RESERVED         0

NEW TEXT:

   The following HI Algorithms have been defined:

        Algorithm
        profiles         Values

        RESERVED         0
        DSA              3 [FIPS 186-3] (OPTIONAL)
        RSA              5 [RFC3447]    (REQUIRED)
        ECDSA            7 [RFC4754]    (REQUIRED)
        ECDSA_LOW        9 [SECG]       (RECOMMENDED)

  For DSA, RSA, and ECDSA key types, profiles containing at least 112
  bits of security strength (as defined by [NIST SP 800-131A]) should
  be used.  For RSA signature padding, the PSS method of padding
  [RFC3447] MUST be used.

------------

Note, I decided not to bother with adding OEAP or ECIES to the cipher list, since we already have symmetric keys available and the ENCRYPTED parameter is lightly used.  If someone would like to support it in addition to AES-CBC, please propose a specific text proposal.

- Tom

[*] http://www.ietf.org/mail-archive/web/hipsec/current/msg03551.html

---

From: René Hummen <[email-masked]>
Date: Fri, 29 Jun 2012 11:02:09 +0200

A few comments from my side in line.

>   in Section 5.2.9.  Additional algorithms MAY be supported.

ECC libraries are available for most consumer-targeting platforms nowadays. Examples are the relic-toolkit [1] and OpenSSL. Hence, I don't see requiring both algorithms as a major concern. However:
1) What exactly are the practical implications of requiring both RSA and ECDSA?
2) Resource-constrained devices may only support ECC crypto. Would it make sense to move away from RSA as REQUIRED (seeing that ECC for PC-grade platforms is widely available) or is this perceived as too drastical of a measure?

[1] http://code.google.com/p/relic-toolkit/

>        AES-256-CBC        4     ([RFC3602])

I agree.

>  be used.  For RSA signature padding, the PSS method of padding

The only use case for OEAP that I can see is if the I1 or R1 should contain confidential information for some reason. Further ahead in the handshake, I also don't see the need to use PK crypto for the ENCRYPTED parameter as symmetric keys are already available at this point. However, if an extension of HIP should need confidential information in I1 or R1, it can specify this CIPHER_ID itself.

Regards,
René

--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 21462
web: http://www.comsys.rwth-aachen.de/team/rene-hummen/