[Swan-dev] [IPsec] trapdoor'ed DH (and RFC-5114 again) (fwd)

[Paul Wouters]

FYI,

I think regardless of the outcome at IETF, it would be prudent
to completely remove RFC-5114 DH group (22-24) support.

We already never allowed it without explicit configuration, so
this should only effect those forced to use these groups with
an explicit ike= line containing dh22/dh23/dh24.

Paul

---------- Forwarded message ----------
Date: Sun, 9 Oct 2016 17:26:02
From: Paul Wouters <paul at nohats.ca>
Cc: saag at ietf.org
To: "ipsec at ietf.org WG" <ipsec at ietf.org>
Subject: [IPsec] trapdoor'ed DH (and RFC-5114 again)


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 at ietf.org
https://www.ietf.org/mailman/listinfo/ipsec