René, a few replies are inline below: > From: René Hummen [mailto:[email protected]] > Sent: Friday, June 29, 2012 2:02 AM > To: HIP WG > Cc: Henderson, Thomas R > Subject: Re: [Hipsec] rfc5201-bis issue 29: Use different RSA mode > OAEP/PSS > > A few comments from my side in line. > > On 27.06.2012, at 06:10, Henderson, Thomas R wrote: > 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. > > 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?
I don't see much of an implementation burden in requiring both (at least for implementations like OpenHIP). I anticipate that HIP DEX will likely be the spec used for resource constrained devices, so this shouldn't impact that use case. > 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/ I don't have a strong opinion on this, but it was the suggestion offered by Uri Blumenthal on the cfrg list to move away from RSA, although he also alluded to the large RSA installed base; hence the suggestion to make both RSA and ECDSA required to facilitate the migration: http://www.ietf.org/mail-archive/web/cfrg/current/msg03151.html <snip> > > 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. > > 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. > I came to a similar conclusion. Thanks for the feedback, Tom _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
