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

[Stephen Kent <[e-mail]>]

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