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