On Jul 27, 2012, at 9:30 AM, Dan Harkins wrote: > > On Thu, July 26, 2012 8:07 pm, Tero Kivinen wrote: >> Dan Harkins writes: >>> On Thu, July 26, 2012 1:59 pm, Yaron Sheffer wrote: >>>> the fact that we need to study the protocol details and go into the >>>> ASN.1 bits to ascertain that we have a problem, strongly suggests to >>> me >>>> that non-EC DSA is not terribly important. So if we can have a >>> *simple* >>>> solution that also deals with this problem, fine. Otherwise, let's >>> just >>>> focus on ECDSA. >>> >>> How does one currently indicate the hash algorithm used for non-EC DSA >>> in IKEv2 today? >> >> Same way than IKEv1 does it, meaning it is assumed to be SHA-1. > > OK, so you're admitting that there's a problem with non-EC DSA in > IKEv2. Good, I agree. I would say the inability for IKEv2 to construct > a signature that is valid today according to FIPS 186-3 is a problem > and we should address it.
Is that "we" as in the IPsecME group, or "we" the design team? Either way, non-EC DSA is hardly used. There are effectively zero certificates on https servers using it. People preferred RSA even in the days when RSA had to be licensed and DSA was free. Why do we need to fix it now? >> Also I would be more happy to reuse the stuff from PKIX than adding >> new registy for hashes. This would simplify the auth payload >> processing too as the domain parameters and hash both could be seen >> from the same place (i.e. from the auth payload) and then we do not >> need to add stuff to this registry when new hash functions are added, >> we can just assume someone will allocate oids for them. > > The domain parameter comes from the CERT payload not the AUTH > payload. In any event there's 1 bunch of 8 RESERVED bits and then on the > next aligned ulong there's another 24, that's 32 available but disjoint > bits. How do you propose encoding an OID into the AUTH payload? One way is to just place the ASN.1 structure similar to a certificate signature: a sequence containing an OID and a bitstring. That structure can be placed there as the "Authentication Data" field. The only issue I have with that is that there is no negotiation about support for the algorithm, so the OID may turn out to be ECDSA-with-SHA2-224 when the receiver does not even support SHA2-224, but that problem exists also with encoding the SHA2-224 in the currently reserved fields. The advantage is that no specification would need to be updated when a new hash function is defined. As long as it has an OID, the spec supports it with no change. Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
