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.miga...@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.matts...@ericsson.com > <mailto:john.matts...@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-boun...@ietf.org <mailto:ipsec-boun...@ietf.org> on behalf of > p...@nohats.ca <mailto:p...@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 > s...@ietf.org <mailto:s...@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
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
