Re: [IPsec] New draft on IKE Diffie-Hellman checks

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) <
sfluhrer@cisco.com> wrote:

>  ** **
>
> ** **
>
> *From:* ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] *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 <yaronf.ietf@gmail.com>
> 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
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec****
>
> ** **
>