Valery, >>> I suggest to change this as following. Instead of >>> adding IKE registry, listing hash algorithms, >>> add registry listing combinations of hash&signature >>> algorithms, as listed in Appendix A. >>> So, the registry would look like: >>> >>> RESERVED 0 >>> sha1WithRSAEncryption 1 >>> sha256WithRSAEncryption 2 >>> sha384WithRSAEncryption 3 >>> sha512WithRSAEncryption 4 >> >> The problem here is that RSA Encryption is not enough. For example >> there might be implementations which only support 1024-bit RSA keys, >> as they have old crypto hardware.
Your proposal creates exactly the issue which the draft is trying to solve: The lack of flexibility by relying on IPsec code points for the signature algorithm (as opposed to using existing OIDs commonly used in certificates and CMS) and the coupling of signing algorithms and signature hash functions. > And the problem with the current SIGNATURE_HASH_ALGORITHMS > is that it decouples hash from signature, assuming that any hash > could be used with any signature algorithm. This decoupling was explicitly stated as objective by the WG chairs when the design team was set-up: Yaron Sheffer wrote on 24.07.2012 18:08: > - Allows flexibility in associating hash functions with EC groups. Therefore, this feature is not the problem, it is the solution. > Actually this is not true, as some algorithms are administratively defined > only in conjunction with particular hash function. This is the exception. For the most commonly used algorithms, RSA and ECDSA, There are no requirements to use fixed combinations. For ECDSA, there is only a minimum requirement relating to the targeted security level. > For example GOST signature algorithm is defined ONLY with GOST hash. The current proposal allows to use that combination, so what is the problem? > > And even if you could use DSA with SHA-2 or even SHA-3, > I would more likely expect the existence of crypto > that supports DSA only with SHA-1, than the crypto, > that supports only RSA with 1024 bit keys and no other RSA key sizes. > I do not think, DSA is used much at all. Even if it was, SHA-1 is phasing out due to (not so) recent advances in cryptoanalysis. Thus, I would expect either implementations to change to allow the use of DSA with SHA-2/3, or the (limited) prevalence of DSA to end soon. >>> dsa-with-sha1 5 >>> dsa-with-sha256 6 >>> ecdsa-with-sha1 7 >>> ecdsa-with-sha256 8 >>> ecdsa-with-sha384 9 >>> ecdsa-with-sha512 10 >> >> Or there is implementation which support ECDSA only with NIST curves, >> and not with brainpool curves. > > Probably they should also be added. There are 4 Brainpool curves registered and 5 NIST curves. Each can be combined with a bunch of hash functions (from the SHA-2 and SHA-3 families). > >>> RSASSA-PSS-default 11 >>> The default is with SHA-1 which will soon be outdated. Thus, you would need to allow many further PSS combinations. -- Johannes _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
