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

On Mon, 17 Oct 2016, Yoav Nir wrote:

> I’m not entirely comfortable with calling something a MUST NOT when all we have is conjecture,

It's a little more than conjecture.

1) It has been proven that malicious 1024 bit DH values can be generated
    by academia that cannot be independantly discovered. Therefore any
    nationstate with access to the same theory and more CPU power could
    have done this years ago.

2) We have the RFC 5114 values who'se original authors/sponsors are not
    disclosing how these were generated.

1) + 2) means we cannot know if these values were trapdoor'ed.

If BBN/NIST/NSA wants to share how they seeded these values, we can all
publicly decide if we can keep using these or not. Without such
information, it just becomes an unnecessary risk to take.

Adding Steve Kent, co-author of RFC-5114, to the CC: so that he has
the opportunity to share what he knows about the origins of these
values and their seeds.

>  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.

Thanks,

Paul

> 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> 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
> 
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> 
> 
>