On Mon, July 23, 2012 2:19 am, Tero Kivinen wrote:
> Dan Harkins writes:
>> So instead of being able to use the negotiated hash function to
>> compute an ECDSA signature we're forced to eat through the "scarce
>> resource" of the authentication method registry. Very clumsy, very
>> hackish, very unfortunate.
>
> I disagree it being clumsy or hackish or unfortunate. It is just one
> way of designing the system. Some peole do want to make sure there is
> no way to mix algorithms of different strength. I myself think this
> should be something that is restricted by policy, not by protocol, but
> some people do disagree that and design systems differently. It is not
> necessarely bad or good, it is just different.
So some people want to do it one way and other's want to do it a
different way. What's hackish is to do both and that's what IKEv2 does.
For (EC)DSA the hash algorithm to use is determined by the auth
method (no way to mix algorithms) but the cipher and D-H group
are not (something restricted by policy).
Doing it one way or the other might not necessarily be good or bad
but doing it both is.
> Also there is no reason why the ECDSA RFC could not have added a new
> transform type for HASH function, but it instead decided to use fixed
> hash functions for the curves (just like we do for DSA in the IKEv1,
> which always used SHA-1 as hash function when calculating signature,
> regardless what was negotiated in the SA payloads for HASH).
And in IKEv2 you got rid of the hash negotiation but retained the
SHA-1 only nature of DSA regardless of the PRF being negotiated.
Section 3.8 of RFC 5996 says:
"DSS Digital Signature 3
Computed as specified in Section 2.15 using a DSS private key
(see [DSS]) over a SHA-1 hash."
Dan.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
