[Cryptography] IPsec DH parameters, other flaws (fwd)

[Paul Wouters]

On Tue, 7 Jul 2020, Ray Dillinger wrote:

> So.  If I am understanding this correctly, someone relatively
> unfamiliar with the RFC process obtained a set of parameters from NIST,

Steve Kent was and is _very_ familiar with the RFC process.

> Instead this one set of
> parameters has seen use so broad that, *IF* there is a back door,
> *THEN* these parameters have become a "golden key" to a substantial
> fraction of the entire traffic.

No, RFC 5114 was never widely supported, and never made it in the "defaults"
of ny IPsec implementations that I'm aware of.

> And then there was the Dual_EC_DRBG debacle

If you're doing history, you should start with Windows NT SP3 NSAKEY :)

> So "MUST NOT" isn't an unreasonable thing to say given the
> circumstances.
>
> At the very least those parameters snould be decertified.  In the same
> way and for the same reasons that DUAL_EC_DRBG was decertified.  Until
> then people need to be warned against using them.

As I^W the IPsec working group wrote in RFC 8247:

https://tools.ietf.org/html/rfc8247#section-2.4

    Groups 22, 23, and 24 are MODP groups with Prime Order Subgroups that
    are 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 groups 2 and 14 but never
    saw wide deployment.  It has been shown that group 22 with 1024-bit
    MODP is too weak and academia have the resources to generate
    malicious values at this size.  This has resulted in group 22 to be
    demoted to MUST NOT.  Groups 23 and 24 have been demoted to SHOULD
    NOT and are expected to be further downgraded in the near future to
    MUST NOT.  Since groups 23 and 24 have small subgroups, the checks
    specified in the first bullet point of Section 2.2 of "Additional
    Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2
    (IKEv2)" [RFC6989] MUST be done when these groups are used.

Note here that the argument against DH 23/24 was made "not in wide use"
to prevent any discussion about trustwortiness.

As for the implementation I work on (libreswan), we have disabled all
three at compile time the moment the RFC was published in 2017. In a year
or so, we will likely also remove the disabled code for it.

> And if the standard is a way to facilitate intercepting domestic
> traffic, then it's failing in its purpose.

> P.S. They're still intercepting domestic traffic BTW.

I personally don't care about the difference between domestic US or
otherwise, not being an American citizen. I am always amused at how
important Americans feel this difference is, because it means those
people find it acceptable that I have no privacy rights or expectations.

Paul