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
