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.


IPsec mailing list

Reply via email to