Re: [saag] [IPsec] trapdoor'ed DH (and RFC-5114 again)

In fact is there anyone opposing their status becomes MUST NOT in
rfc4307bis.

On Mon, Oct 17, 2016 at 11:30 AM, John Mattsson <john.mattsson@ericsson.com>
wrote:

> > I'm proposing it is time to change this to MUST NOT for 4307bis.
>
>
>
> +1
>
> On 09/10/16 23:26, "IPsec on behalf of Paul Wouters"
> <ipsec-bounces@ietf.org on behalf of paul@nohats.ca> wrote:
>
> >
> >Released a few days ago:
> >
> >       http://eprint.iacr.org/2016/961
> >
> >       A kilobit hidden SNFS discrete logarithm computation
> >       Joshua Fried and Pierrick Gaudry and Nadia Heninger and Emmanuel
> Thomé
> >
> >       We perform a special number field sieve discrete logarithm
> >       computation in a 1024-bit prime field. To our knowledge, this
> >       is the first kilobit-sized discrete logarithm computation ever
> >       reported for prime fields. This computation took a little over
> >       two months of calendar time on an academic cluster using the
> >       open-source CADO-NFS software.
> >
> >Basically, this paper shows how to make a DH group of 1024 modp
> >with a backdoor, in two months of academic computing resources,
> >
> >The paper mentions 5114 a few times:
> >
> >       RFC 5114 [33] specifies a number of groups for use with
> >       Diffie-Hellman, and states that the parameters were drawn
> >       from NIST test data, but neither the NIST test data [39] nor
> >       RFC 5114 itself contain the seeds used to generate the finite
> >       field parameters
> >
> >And concludes:
> >
> >       Both from this perspective, and from our more modern one,
> dismissing the
> >       risk of trapdoored primes in real usage appears to have been a
> mistake,
> >       as the apparent difficulties encountered by the trapdoor designer
> in
> >1992
> >       turn out to be easily circumvented. A more conservative design
> decision
> >       for FIPS 186 would have required mandatory seed publication
> instead of
> >       making it optional.  As a result, there are opaque, standardized
> >1024-bit
> >       and 2048-bit primes in wide use today that cannot be properly
> verified.
> >
> >This is the strongest statement yet that I've seen to not trust any
> >of the RFC-5114 groups.
> >
> >The latest 4307bis document has these groups (22-24) as SHOULD NOT,
> >stating:
> >
> >       Group 22, 23 and 24 or 1024-bit MODP Group with 160-bit, and
> >       2048-bit MODP Group with 224-bit and 256-bit Prime Order Subgroup
> >       have small subgroups, which means that checks specified in the
> >       "Additional Diffie-Hellman Test for the IKEv2" [RFC6989] section
> >       2.2 first bullet point MUST be done when these groups are used.
> >       These groups are also not safe-primes.  The seeds for these groups
> >       have not been publicly released, resulting in reduced trust in
> >       these groups.  These groups were proposed as alternatives for
> >       group 2 and 14 but never saw wide deployment.  It is expected
> >       in the near future to be further downgraded to MUST NOT.
> >
> >I'm proposing it is time to change this to MUST NOT for 4307bis.
> >
> >Possibly, we should do this via SAAG in general, and then follow SAAG's
> >advise in IPSECME.
> >
> >Is there _any_ reason why group 22-24 should not be MUST NOT ?
> >
> >Paul
> >
> >_______________________________________________
> >IPsec mailing list
> >IPsec@ietf.org
> >https://www.ietf.org/mailman/listinfo/ipsec
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>