On Fri, July 27, 2012 12:13 am, Yoav Nir wrote: > > 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?
I meant "we" as the WG. I think this design team is working at the pleasure of the WG anyway. I'm not sure why a survey of https servers can accurately gauge the use of DSA in IKEv2. One could also look at it in the light that the SHA-1-only nature of DSA in IKEv2 only became a problem recently (as FIPS 186-3 and SP 800-57 say such signatures were valid only through 2010). The reason we need to fix it now is that IKEv2 cannot produce a valid DSA signature today and unless IKEv3 is just around the corner I'd say we should fix it in IKEv2 (and given the sound of crickets I hear every time I bring up IKEv3 I'm less inclined to think it's just around the corner). >>> 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. Yes that would work. Since there would be a new AUTH method we could overload the Authentication Data field. It seems sort of a "6 of one; half dozen of the other" kind of thing but I guess "we" can decide that. Dan. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
