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? 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/ > 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]) I agree. > 3) Section 5.2.9, Host Id: > > OLD TEXT: > > The following HI Algorithms have been defined: > > Algorithm > profiles Values > > RESERVED 0 > DSA 3 [RFC2536] (RECOMMENDED) > RSA 5 [RFC3110] (REQUIRED) > ECDSA 7 [RFC4754] (RECOMMENDED) > ECDSA_LOW 9 [SECG] (RECOMMENDED) > > 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. 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/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
