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 <watsonbl...@gmail.com> To: "s...@ietf.org" <s...@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-d...@dukhovni.org> To: s...@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)
