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 Testlist
mailing list