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 protected] [mailto:[email protected]] 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 protected]]
> > 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 protected]
> https://www.ietf.org/mailman/listinfo/hipsec
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
