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

I’m not entirely comfortable with calling something a MUST NOT when all we have is conjecture, but I have no love and no need of those DH groups.

I don’t believe anyone else depends on these groups (at least in IPsec), so I’m fine with such a change.

Yoav

> On 17 Oct 2016, at 18:54, Daniel Migault <daniel.migault@ericsson.com> wrote:
> 
> 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 <mailto: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 <mailto:ipsec-bounces@ietf.org> on behalf of paul@nohats.ca <mailto:paul@nohats.ca>> wrote:
> 
> >
> >Released a few days ago:
> >
> >       http://eprint.iacr.org/2016/961 <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 <mailto:IPsec@ietf.org>
> >https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>
> 
> _______________________________________________
> saag mailing list
> saag@ietf.org <mailto:saag@ietf.org>
> https://www.ietf.org/mailman/listinfo/saag <https://www.ietf.org/mailman/listinfo/saag>
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec