Bug#839978: exim4: Potential backdoor'ed D-H groups in use by Exim4?

[Theodore Y. Ts'o]

Source: exim4
Severity: important

>From a recent discussion on IETF's Security Area Advisory Group:

Date: Thu, 6 Oct 2016 08:56:45 -0700
From: Watson Ladd <watsonbladd at gmail.com>
To: "saag at ietf.org" <saag at ietf.org>
Subject: [saag] Possible backdoor in RFC 5114

https://tools.ietf.org/html/rfc5114

Let's review some publicly known facts:

1) BBN is a defense contractor

2) The NSA subverts crypto standards

3) It is possible to design primes so the discrete log problem is easy

4) The primes in RFC 5114 are not generated in verifiable manner: it
is possible they are hidden SNFS primes.

At minimum we should obsolete RFC 5114 in favor of primes generated in
a verifiable manner. The fact that there already were primes for IKE
use makes me wonder why this was even needed in the first place.

-------------------------------------

Date: Thu, 6 Oct 2016 17:15:29 +0000
From: Viktor Dukhovni <ietf-dane at dukhovni.org>
To: saag at ietf.org
Subject: Re: [saag] Possible backdoor in RFC 5114

On Thu, Oct 06, 2016 at 07:28:57PM +0300, Yoav Nir wrote:

> > At minimum we should obsolete RFC 5114 in favor of primes generated in
> > a verifiable manner. The fact that there already were primes for IKE
> > use makes me wonder why this was even needed in the first place.
> > 
>
> RFC 5114 is an Informational document published by two employees (at the
> time) of BBN as individuals. As the boilerplate says, �it does not specify
> an Internet standard of any kind�.
> 
> IANA numbers have been assigned to them for IKE, but they have not seen
> widespread use.  In TLS they are all but unknown, and recent work is
> deprecating the use of DHE with explicit parameters anyway.

Sadly, their use was facilitated by support for these groups being
added in OpenSSL 1.0.2, making it easier for users to stumble into
using them.  Thus, for example, these are in use in Exim, likely
because it seemed more convenient to use "standard" groups, than
to ask users to generate their own DH parameters, and "they're in
an RFC, so they must be better than just random...".

    http://www.exim.org/exim-html-current/doc/html/spec_html/ch-main_configuration.html#SECTalomo
    [ scroll down to the entry for tls_dhparams ]

    If Exim is using OpenSSL and this option is empty or unset,
    then Exim will load a default DH prime; the default is the 2048
    bit prime described in section 2.2 of RFC 5114, "2048-bit MODP
    Group with 224-bit Prime Order Subgroup", which in IKE is
    assigned number 23.

    Otherwise, the option must expand to the name used by Exim for
    any of a number of DH primes specified in RFC 2409, RFC 3526
    and RFC 5114. As names, Exim uses "ike" followed by the number
    used by IKE, of "default" which corresponds to "ike23".

    The available primes are: ike1, ike2, ike5, ike14, ike15, ike16,
    ike17, ike18, ike22, ike23 (aka default) and ike24.

Fortunately for some, the Postfix compiled-in default DHE parameters
use SG primes (that I generated in the usual way), but users are
encouraged to use their own.

    http://www.postfix.org/FORWARD_SECRECY_README.html

----------------------------

Please consider disabling the Diffie-Hellman primes specified in RFC
5114 in Exim.

Thanks!!



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-00041-gecd2f69 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)