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

[Paul Wouters]

On Tue, 7 Jul 2020, Peter Gutmann wrote:

>  Paul Wouters <paul at cypherpunks.ca> writes:
>
>>  And if it makes you feel better, once I investigated the history and lack
>>  of
>>  justification of RFC 5114, which Steve Kent admitted to having just
>>  forwarded
>>  from NSA/BNN to IETF without explanation, I pushed to kill the whole thing.
>>  It's now dead.
>
>  Interesting, so the RFC 5114 values are NSA-generated rather than NIST as
>  the
>  RFC implies?  I'd always avoided them because, apart from not serving any
>  obvious purpose, they also use incredibly inefficient values for g, making
>  them a non-starter for any real use.


Steve's exact words:

Date: Tue, 18 Oct 2016 10:47:00
From: Stephen Kent <kent at bbn.com>
Cc: "ipsec at ietf.org WG" <ipsec at ietf.org>, Security Area Advisory Group 
<saag at ietf.org>
To: Paul Wouters <paul at nohats.ca>, Yoav Nir <ynir.ietf at gmail.com>
Subject: Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again)

Paul,

It's  been over 8 years since this RFC was published, and I have not looked at 
it since then. My recollection is that we wrote 5114 because an IPsec developer 
approached me and said that he wanted to support
these groups in a product. He said that he wanted test vectors for the groups, 
consistent with what we have done for many other algs. I persuaded Matt to 
generate the RFC because it was a relatively easy
task a good way for Matt to get acquainted with the RFC process.

As to your question, I have no info about how the NIST DH values were 
generated. However, I do agree with Yoav and Tero that it seems unduly 
prejudicial to declare these to be a MUST NOT. The fact that one
can generate trap-doored DH values that cannot be detected is not the same as 
having proof that a given set of values have been generated in that fashion. 
Moreover, if one interprets a MUST NOT in this
context to mean that an implementation supporting any of these groups is 
non-compliant, then that unfairly penalizes existing implementations, as Tero 
noted. Moreover, if the concern raised by the paper
(which I have read) is with MODP groups of size 1024 (or smaller), only 1 of 
the groups in 5114 fits that criteria (section 2.1).

I have not tracked the status of these NIST groups re evaluation criteria like 
FIPS 140-2. If these groups are approved for use in products evaluated under 
that FIPS (I don't know if they are), deprecating
them creates a possible conundrum for vendors who want to comply with RFCs and 
with FIPS evaluation criteria. Thus I suggest a less dramatic response than 
declaring all of the groups in 5114 to be MUST NOT.

I'm not a vendor of any crypto products (these days), and I've never been a 
crypto mathematician. So my views are based only on what I recall about the 
creation of 5114 and about IETF crytpo standards
practices in general.

Steve