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

[Georgi Guninski]

On Sat, Sep 05, 2015 at 07:41:11AM +0000, Alfonso De Gregorio wrote:
> parameters? Or, if, as you correctly pointed out, an implementation
> MAY NOT check group parameters, which entity deserves credit for it?
>

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).

Suppose implementation X1 follows MAY and X2 does not.

Observe that in real world neither X1 nor X2 need be
RFC compliant (like malware).

Even if they are compliant, this might cause troubles.

In my DSA SSL example (which might be technical bug in openssl,
but not necessarily technical bug in hypothetical DH implementation),
the key/cert wasn't RFC compliant, but passed verification.

Cheers,
-- 
georgi