If the recommendation is to be compatible with the unnecessary checks of 56A in this case then say that. As written now, one would assume that there is a security benefit to it. (That's how we carry legacy misconceptions from standard to standard.)
Hugo On Mon, Dec 10, 2012 at 4:53 PM, Scott Fluhrer (sfluhrer) < [email protected]> wrote: > ** ** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On Behalf > Of *Hugo Krawczyk > *Sent:* Monday, December 10, 2012 2:50 PM > *To:* Yaron Sheffer > *Cc:* IPsecme WG > *Subject:* Re: [IPsec] New draft on IKE Diffie-Hellman checks**** > > ** ** > > The tests in sections 2.1 and 2.3 are cheap and can serve as sanity checks > for an implementation as stated in the draft, even if DH is not reused. > > On the other hand, the test in 2.2 is expensive, equivalent to a group > exponentiation, and therefore should not be recommended without DH re-use > (in which case the test is an expensive waste). > > Actually, the right recommendation (or MUST) for 2.2 groups is NOT to > reuse DH values. > Indeed, the reason to reuse DH is to save an exponentiation but if you do > so you pay with an extra exponentiation for the membership test. Moreover, > while the exponentiation you are saving can be performed offline (before > the run of the IKE session), the group membership test is online, so either > way it makes no sense to reuse the DH exponents.**** > > I cannot disagree with anything you say. However, the real reason the 2.2 > groups (22, 23, 24) exist is the other MODP groups do not conform to NIST > SP 800-56A (see section 5.5.1.1). And, SP 800-56A also mandates the checks > we recommend (section 5.6.2.4).**** > > That is, if you are implementing (say) group 24 specifically for > conformance reasons, you’re going to do that test anyways (yes, it may be > an expensive waste for cryptographical reasons, however, it isn’t for > conformance reasons). In that scenario, DH reuse does make sense (because > not doing DH reuse doesn’t let you eliminate the test).**** > > I would agree that maybe we need to extend the draft to discuss these > noncryptographical issues.**** > > ** ** > > > By the way, if you forbid re-use, you need to actually mandate fresh > exponents with each session (otherwise, an implementation maybe tempted to > avoid re-use by using g^x, g^{x+1}, g^{x+2}, etc.) > > Hugo**** > > On Mon, Dec 10, 2012 at 1:43 PM, Yaron Sheffer <[email protected]> > wrote:**** > > Hi, > > following the recent discussion on the mailing list, Scott Fluhrer and > myself just published a draft that updates RFC 5996 by adding the required > recipient-side tests for ECDH. Please see > http://www.ietf.org/internet-drafts/draft-sheffer-ipsecme-dh-checks-00.txt > . > > We have not addressed the issues raised by Dan and Tero regarding > inconsistencies between various RFCs that define ECDH groups for IKE. I > personally deem these issues to be out of scope of the current document. > > Comments are very welcome. > > Thanks, > Yaron > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec**** > > ** ** >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
