Yoav Nir writes: > >> And for the digital signature method, why should we require SHA-1? > > > > Because it is very common to use right now. We cannot go from MUST to > > MUST NOT. > > No, but RFC 4307 says nothing about hashes in signatures (whether > RSA(1) or digital signature(14)). So whatever we recommend here is > new.
There are two issues there. The RFC7296 says that SHA-1 is SHOULD for RSA Digital Signatures in section 3.8: RSA Digital Signature 1 Computed as specified in Section 2.15 using an RSA private key with RSASSA-PKCS1-v1_5 signature scheme specified in [PKCS1] (implementers should note that IKEv1 used a different method for RSA signatures). To promote interoperability, implementations that support this type SHOULD support signatures that use SHA-1 as the hash function and SHOULD use SHA-1 as the default hash function when generating signatures. Implementations can use the certificates received from a given peer as a hint for selecting a mutually understood hash function for the AUTH payload signature. Note, however, that the hash algorithm used in the AUTH payload signature doesn't have to be the same as any hash algorithm(s) used in the certificate(s). So for RSA Digital Signatures the SHA-1 was SHOULD, and I think it should still be SHOULD for that, as that is the algorithm everybody are using. Also note, that there is no negotiation for the signature algorithm there, thus if one end picks SHA2-256 and other end does not support it the authentication will simply fail, and there is no way to recover. On the other hand we should be downgrading that method completely over the generic Digital Signature method specified in RFC7427. When using RFC7427 signature there is negotiation for the signature algorithm, providing the algorithm agility. I.e. in that case it is safe to propose SHA-1, SHA-256 etc and then both ends pick one of the algorithms other end supports. For RFC7427 support there is no point of requiring MUST for SHA-1 as all of RFC7427 implementations are new, and they should support SHA2 based algorithms too. I.e. It would be better to say SHA-1 for RFC7427 for SHOULD NOT, and SHA2-256 for MUST. The RFC7427 support is still only SHOULD... > This is even more true for digital signature(14) as we hardly have > any legacy code to maintain backwards compatibility with[1]. Yes. > So ISTM that we should be fine recommending SHA2-256 at the MUST > level with SHA1 in the SHOULD NOT level (to allow people who manage > to interface old hardware modules to new IKE software) Agree for RFC7427. For Old RSA Digital Signatures SHA-1 is the one that is still used, and I think we should keep that SHOULD- or similar. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec