Hi Tero, > I posted first version of the signature authentication method. This is > based on the design team work on the ECDSA, but as the design team > decided not to forbid other authentication methods, I named the draft > to signature-auth, not ecdsa-auth.
Thanks for your work. > > To fully support RSASSA-PSS we would need to include full > AlgorithmIdentifier ASN.1 including the parameters. I myself would > think that would be best option, as that would allow widest possible > use for this new method, i.e. we can support whatever PKIX does. Some > design team members disagreed, and we ended up with the current > compromize... If RSA-PSS keys are used then this should not be an issue. In this case the SPKI of the cert specifies the parameters to be used. However, RSA-PSS keys are hardly supported yet. If the SPKI includes just an rsaEncryption OID, there are several problems: - A peer with an RSA signing key supporting RSA-PSS has no means to determine if the other peer supports PSS as well or if he should better fall back to PKCS#1v1.5. At least he can find out with trial and error. - When verifying a RSA-PSS signature based on a certificate specifying rsaEncryption in SPKI, additional information on the parameters used are needed. I would also advocate inclusion of parameters in the AlgorithmIdentifier inside Authentication Data. In most cases (except RSA-PSS with non-standard parameters) it is NULL, but I don't think, this is a problem. > Other things: > > In my draft I say: > ---------------------------------------------------------------------- > For the hash truncation the method of > X9.62, SEC1 and IO 14888-3 MUST be used. XXX Need reference for > X9.62/SEC1 etchere XXX. > ---------------------------------------------------------------------- > > I.e. the draft points to this hash truncation method. Does anybody > have proper reference for that, and it might be good if we could > summarize it here too, as not all people have access to those other > specifications. I have been the one bringing up this issue, so I should comment on this ;-) The issue is that ISO 15946-2 defines a different hash truncation method. But actually, ISO 15946-2 is deprecated (withdrawn) in favor of ISO 14888. Therefore, I don't think we need to specify anything w.r.t hash truncation. It is now uniformly defined in all current standards. > > > In security considerations section I have text: > ---------------------------------------------------------------------- > The hash algorithm registry does not include MD5 as supported hash > algorithm, as it is not considered safe enough for signature use. > > XXX Need reference for MD5 considered unsafe. XXX > ---------------------------------------------------------------------- > > Does anybody have good reference for MD5 especially with signatures > (not with HMAC). > Wikipedia list a good reference: Xiaoyun Wang; Hongbo Yu (2005). "How to Break MD5 and Other Hash Functions". If you are looking for standards... NIST SP 800-57 does not list MD5 as approved but does not explicitly mention it as ineligible. An explicit caveat is included in ETSI TS 102 176-1 "Recently some new attacks against hash function MD5 succeeded, it was shown that MD5 is not collision resistant by constructing classes of messages-pairs with the same hash value. Whereas the loss of collision resistance does not imply that a pre-image or second pre-image can easier be constructed, it is recommended to migrate to other hash functions, if the collision resistance becomes weaker." However, this standard is is from 2005 and focuses on Secure Electronic Signatures. Is this a problem? > > In the security considerations section I also have: > ---------------------------------------------------------------------- > The current IKEv2 uses RSASSA-PKCS1-v1_5, and does not allow using > newer padding methods like RSASSA-PSS. This new method allows using > other padding methods. > > XXX Need reference for RSASSA-PSS vs RSASSA-PKCS1-v1_5 security. > XXX > ---------------------------------------------------------------------- > > RFC4055 says > > " The RSASSA-PSS signature algorithm is preferred over the PKCS #1 > Version 1.5 signature algorithm. Although no attacks are known > against PKCS #1 Version 1.5 signature algorithm, in the interest of > increased robustness, RSASSA-PSS signature algorithm is recommended > for eventual adoption, especially by new applications." > > Is this still the case, or do we have some reference which would point > out why RSASSA-PSS is better.... Of course if we cannot support > RSASSA-PSS with the this new method properly, this text in the > security considerations section might not be needed... > There are attacks against implementations not checking for garbage after the hash value when using public exponent e=3 (a very special case, but the best attack I know of). http://csrc.nist.gov/groups/ST/toolkit/documents/dss/RSAstatement_10-12-06.pdf As permanent reference, this one is better: Ulrich Kuehn, Andrei Pyshkin, Erik Tews, Ralf-Philipp Weinmann: Variants of Bleichenbacher's Low-Exponent Attack on PKCS#1 RSA Signatures. Proceedings of Sicherheit 2008, pp. 97-109. > > In the security considerations section: > ---------------------------------------------------------------------- > XXX The text about the guidance how to select suitable hash > functions is missing here. XXX > ---------------------------------------------------------------------- > > I.e we need to guidance or references to good guidance. As this draft > is no longer only ECDSA, the RFC5480 might not be enough. For RSA, or > normal DSA might also need some guidance. What kind of guidance do we > want here. > NIST SP 800-57, Tables 2 in combination with Table 3. It seems that RFC 4055 also point to an early draft of NIST SP 800-57. -- Johannes _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
