[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal for new DH Groups 6, 7, and 8
Hi,
I agree with Paul that RFC 2412 isn't the most appropriate place for
the new groups. A developer shouldn't use RFC 2412
as a base, but rather RFC2409 (IKE). I think the IKE document
must cover all "well-known" groups for Phase 1 and
Phase 2. All other groups must fall into the new group mode.
However, "well-known" groups must have reasonable
security level. We have to let a developer decide which groups
to use in Phase 1. Many implementations might not
have PFS, so they will not perform KE in Phase 2, in
this case they will be forced to use only groups defined in
IKE. Then, we'd better provide more flexibility for
Phase 1 by including more groups into RFC2409 (IKE),
such as recently proposed new ECDH and DH groups.
Because the existing RFC2409(IKE) EC curves have questionable security
level and not aligned with the other standards such as ANSI
and NIST, we have proposed new EC curves.
Groups 6-9 proposed in draft-ietf-ipsec-ike-ecc-groups-01.txt are designed
to provide secure elliptic curve groups. This draft is particularly relevant now
since the existing elliptic curve groups in IKE have recently been broken by
Gaudry, Hess, and Smart (http://www.hpl.hp.com/news/ecc.html).
We warned over a year ago about the security of the existing IKE ECC groups
and unfortunately nothing has yet been done. An additional feature of the the
new groups proposed is that they align ECC in IPSec with ECC in ANSI and NIST.
I think it's important to add these groups to IKE both in order encourage implementors
to use ECC which is increasingly recognized by researchers as offering superior security
to regular Diffie-Hellman and in order to make use of these groups easily available to
implementors in Phase 1 without having to resort to the new group mode.
If adding the groups to IKE is impossible, then I think the draft should become
an informational RFC.
Going forward surely we want to offer public-key security comparable to AES strength in IPSec.
Following Lenstra and Verhuel's paper (www.cryptosavvy.com) and NIST's recommendations, this means:
128-bit AES approx= 256-bit ECC approx= 3072-bit RSA/DH
192-bit AES approx= 384-bit ECC approx= 7680-bit RSA/DH
256-bit AES approx= 512-bit ECC approx= 15360-bit RSA/DH
Best regards,
Yuri Poeluev
Certicom Corp.
Paul Koning wrote:
> >>>>> "Joe" == Joe MacLellan <Joseph.Maclellan@entrust.com> writes:
>
> Joe> The DH well-known primes are listed in Appendix E of RFC 2412
> Joe> (Oakley), not RFC 2409 (IKE). I don't think they should be
> Joe> going to Dan to include in the IKE doc, they should be added to
> Joe> 2412 with the rest.
>
> That seems odd, because 2412 is "Informational". Things that affect
> how a protocol works or how it interoperates should be in standards
> track specs, I would think.
>
> I suppose the notion of a protocol spec (which 2412 seems to be)
> marked "informational" is a bit odd in general.
>
> paul