On 06/27/2012 01:10 AM, 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.
This is a REALLY important shift for a crypto system. I feel we should
take it. Even with the ever increasing power in processors today, there
are many reasons of perfer ECDSA keys over RSA. And even with DEX, there
are 'mid size' systems plus constained communication links where ECDSA
will seriously outperform RSA.
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])
DES is dead. Long live the new king. I have spoken to a number of
serious cryptographers, and I am not overly concerned in only having one
block cipher here.
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.
I agree with this. There is ONE case and that is to have the ENCRYPT
content to have security context outside of the HIP flow. Say to an
authentication server. But as indicated, we can let the authors of the
ID that proposes such a use case to add the cipher.
Oh, I do see use cases where the ENCRYPTED parameter gets more use, but
it will be in NOTIFYs. Think of HIP as a secure messaging channel itself
without needing the overhead of a full transport protocol. Sort of like
secure UDP on the cheap.
Tom, thank you for your effort on this.
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
