Possible crypto backdoor in RFC-2631 Diffie-Hellman Key Agreement Method

Alfonso De Gregorio alfonso.degregorio at gmail.com
Sat Sep 5 06:41:23 PDT 2015


On Sat, Sep 5, 2015 at 11:50 AM, Georgi Guninski <guninski at guninski.com> wrote:
...
> If you feel like debugging RFC, start from:
>
> RFC:  2119
>
> https://tools.ietf.org/html/rfc2119#section-5
> 5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
> truly optional.
>
> This includes many backdoors per lack of formalism.
>
> IMHO RFC must use only MUST or "MUST NOT" to make
> the ``formal model'' soundly defined (recursively RFC compliant).

While I sympathize with your point of view, and while I would welcome
a full equivalence of implementations, exclusivity of mandatory
requirements is neither a principle governing today's standardization
works, nor, sure enough, a principle that guided the standardization
of protocols back in the 1990s.

The key words defined in RFC 2119 reflect one one or any combinations
of the following:
  * A robustness principle, codified in the Postel's Law;
  * Economic interests at stake;
  * Understanding of the subject matter.

Today our community has finally reconsidered the principle that,
asking designers to "[b]e conservative in what [they] send, [but] be
liberal in what [they] accept", promised robustness on the internet.
But the incentives are still the same; interoperability and security
are always in tension.

It is worth to note that, yesterday as today, we need a better
understanding of the subject matter. It should have been obvious that
a validation of group parameters has security implications. And, just
like any and all security relevant requirements, it should have been
made a mandatory check.

I second Peter's recommendation; consider filing an erratum.

Cheers,

-- Alfonso



More information about the cypherpunks mailing list