[exim-dev] [Bug 1895] Default groups for DH possibly backdoored

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=1895

--- Comment #14 from Git Commit  ---
Git commit:
https://git.exim.org/exim.git/commitdiff/ea98874e2a6a5aee2d512f3246f7d3c19c2ec63d

commit ea98874e2a6a5aee2d512f3246f7d3c19c2ec63d
Author: Jeremy Harris 
AuthorDate: Mon Dec 27 15:15:42 2021 +
Commit: Jeremy Harris 
CommitDate: Thu Dec 30 13:50:33 2021 +

tls: deprecate rfc 5114 dh params.  bug 1895

 doc/doc-docbook/spec.xfpt  |  11 ++-
 doc/doc-txt/ChangeLog  |   2 +
 src/src/std-crypto.c   | 103 +++--
 test/confs/2049|  54 +++
 test/log/{2149 => 2049}|  18 +++-
 test/log/2149  |  17 
 test/mail/2149.userw   |  20 
 test/mail/2149.userx   |  20 
 test/mail/2149.usery   |  20 
 test/mail/2149.userz   |  20 
 test/paniclog/2049 |   3 +
 test/paniclog/2149 |   2 +
 .../{2100-OpenSSL/2149 => 2000-GnuTLS/2049}|  24 +++--
 test/scripts/2100-OpenSSL/2149 |  17 
 test/stderr/2049   |   3 +
 test/stderr/2149   |   2 +
 16 files changed, 194 insertions(+), 142 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 1895] Default groups for DH possibly backdoored

[Viktor Dukhovni via Exim-dev]

On Sun, Apr 07, 2019 at 07:25:38PM +, admin--- via Exim-dev wrote:

> > If so, assuming the p for a parameter has been chosen as a "safe prime",
> > q is entirely dependent on p - which we have from the PEM representation.
> > Why do we care about loading q?
> 
> FWIW: I have no idea.  I almost knew, once, when Viktor explained it before. 
> This again is part of why I try to stick to using crypto-engineering, not
> crypto policy, and defer to experts.

There are two common representations of FFDHE groups:

* (p, g) with just the modulus p and a generator g of a suitable
  subgroup of the non-zero residues mod p under multiplication.

* (p, g, q) with the modulus p, a generator g of a suitable
  subgroup of the non-zero residues mod p under multiplication,
  and the order (element count) of the subgroup generated by g.

The equivalent symmetric strength depends on p with brute-force attacks
roughly as difficult as for RSA keys of the same size, and also on q,
with attack cost of half the bit count of q.

Thus, e.g. for 80-bit security (now passé), you'd go with a 1024-bit
modulus and a generator of a subgroup with 2^160 elements.

Because exponents can be reduced mod q, computations are faster in (p,
g, q) groups when q is chosen much smaller than p, to match the
symmetric strength of the construction.

With "safe" primes, there is indeed no point in specifying q, unless
the library or protocol wants to work with (p, g, q).  With "safe"
primes there are no small subgroups other than {1, -1}.  With (p, g, q)
one can check that q is prime and that the order of g is q, and then
be sure to not be at risk of small subgroup issues.

These days, the trend is to use ECDHE, but when using FFDHE, to use
one of the RFC7919 groups.

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1895] Default groups for DH possibly backdoored

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=1895

--- Comment #13 from Jeremy Harris  ---
Commit ea98874e2a deprecates the ike1, ike22, ike23, ike24 groups.
Full removal still needs to be done in a later release.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1895] Default groups for DH possibly backdoored

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=1895

Phil Pennock  changed:

   What|Removed |Added

  Group||exim-security

--- Comment #12 from Phil Pennock  ---
(In reply to Jeremy Harris from comment #11)
> If so, assuming the p for a parameter has been chosen as a "safe prime",
> q is entirely dependent on p - which we have from the PEM representation.
> Why do we care about loading q?

FWIW: I have no idea.  I almost knew, once, when Viktor explained it before. 
This again is part of why I try to stick to using crypto-engineering, not
crypto policy, and defer to experts.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1895] Default groups for DH possibly backdoored

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=1895

--- Comment #11 from Jeremy Harris  ---
The commit of https://bugs.exim.org/show_bug.cgi?id=1895#c5 includes, for the
RFC 7919 params, text "The group size is: q = (p-1)/2".

This matches a comment in
https://security.stackexchange.com/questions/94390/whats-the-purpose-of-dh-parameters
:-
"Finding the prime p means finding a value for p for which p=2q+1 holds, with q
being a prime. p is then called a safe prime."

Is this the q we're talking about?

If so, assuming the p for a parameter has been chosen as a "safe prime",
q is entirely dependent on p - which we have from the PEM representation.
Why do we care about loading q?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 1895] Default groups for DH possibly backdoored

[Viktor Dukhovni via Exim-dev]

On Tue, Mar 19, 2019 at 07:37:37AM +, Andrew C Aitchison via Exim-dev wrote:

> > FWIW, Postfix 3.4, released a few weeks ago no longer supports OpenSSL 
> > versions prior to 1.0.2.
> 
> Not sure from that whether Postfix 3.4 supports OpenSSL 1.0.2 ?

It supports 1.1.x, 1.0.2, and nothing earlier.  Older OpenSSL
releases are still supported with Postfix 3.1, 3.2 and 3.3.

My posts are basically lending support to the idea that this may
be a good time for *new* Exim releases to require OpenSSL 1.0.2 or
later.  Now OpenSSL 1.0.2 is slated for EOL at the end of this year,
and 1.1.0 (not an LTS release) in September, so one may be tempted
to set the floor at 1.1.1, but that would probably leave some
supported O/S releases behind, that may still be supporting OpenSSL
1.0.2 beyond its upstream EOL.

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1895] Default groups for DH possibly backdoored

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=1895

--- Comment #10 from Jeremy Harris  ---
I take it that the bit of code in OpenSSL dhparam.c around the use of
d2i_DHxparams_bio()  is relevant?
As usual I am finding the OpenSSL docs unhelpful wrt. guidance on actually
using the library.

I think we need to retain support for PEM files; which means (if I understand
correctly about the need for q for sufficient security to enable support for
session resumption) that we'll want docs guidance.  Can someone who understands
crypto say how the need arises, succinctly?  We'll also want to describe how
to generate the parameter files.

We'll also need to look at the GnuTLS support.  Currently we use
gnutls_dh_params_import_pkcs3() with a PEM flag; it does take DER as an
alternate
 - but I don't know if "pkcs3" implies no q.  The function is also "considered
obsolete", in favour of using RFC7919 parameters (which are now GnuTLS builtins
as well as being Exim builtins) - but note that Exim docs encourage sites to
generate their own.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 1895] Default groups for DH possibly backdoored

[Andrew C Aitchison via Exim-dev]

On Tue, 19 Mar 2019, Viktor Dukhovni via Exim-dev wrote:


On Tue, Mar 19, 2019 at 02:43:04AM +, admin--- via Exim-dev wrote:


--- Comment #9 from Phil Pennock  ---
IMO yes we're ready to drop support for older OpenSSL.  We set a clear policy,
it's over a year (or two?) after that point, and other projects have adopted
similar policies.


https://lists.exim.org/lurker/message/20170102.153501.d4c71d99.en.html
(January 2017) says that we are dropping support for openssl v1.0.1
and below.

https://www.openssl.org/policies/releasestrat.html says:
  With regards to current and future releases the OpenSSL
  project has adopted the following policy:
The next version of OpenSSL will be 3.0.0.
Version 1.1.1 will be supported until 2023-09-11 (LTS).
Version 1.1.0 will be supported until 2019-09-11.
Version 1.0.2 will be supported until 2019-12-31 (LTS).
Version 1.0.1 is no longer supported.
Version 1.0.0 is no longer supported.
Version 0.9.8 is no longer supported.

Is it time to announce when exim will drop support for
openssl 1.0.2 and 1.1.0 ?


FWIW, Postfix 3.4, released a few weeks ago no longer supports OpenSSL 
versions prior to 1.0.2.

Though folks on this list probably don't care, Postfix support
covers and the current and 3 previous stable releases, so we're
still supporting Postfix 3.1, 3.2 and 3.3 which build with older
OpenSSL releases, all the way back to 0.9.7, but DANE support
requires at least OpenSSL 1.0.0. So users who're stuck with
OpenSSL 1.0.2 can continue to use it, with a slightly older
Postfix release, until 3.4 becomes the oldest supported stable
release.


Not sure from that whether Postfix 3.4 supports OpenSSL 1.0.2 ?

Red Hat Enterprise Linux 6 is stuck with OpenSSL 1.0.1, but is on its
last legs (entered "Maintenance Support 2 Phase" May 2017 and will be
retired November 30, 2020) so I hope that its users will be moving the OS on
and not in great need for the latest exim features.

--
Andrew C. Aitchison Cambridge, UK
and...@aitchison.me.uk

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 1895] Default groups for DH possibly backdoored

[Viktor Dukhovni via Exim-dev]

On Tue, Mar 19, 2019 at 02:43:04AM +, admin--- via Exim-dev wrote:

> --- Comment #9 from Phil Pennock  ---
> IMO yes we're ready to drop support for older OpenSSL.  We set a clear policy,
> it's over a year (or two?) after that point, and other projects have adopted
> similar policies.

FWIW, Postfix 3.4, released a few weeks ago no longer supports
OpenSSL versions prior to 1.0.2.

Though folks on this list probably don't care, Postfix support
covers and the current and 3 previous stable releases, so we're
still supporting Postfix 3.1, 3.2 and 3.3 which build with older
OpenSSL releases, all the way back to 0.9.7, but DANE support
requires at least OpenSSL 1.0.0.  So users who're stuck with
OpenSSL 1.0.2 can continue to use it, with a slightly older
Postfix release, until 3.4 becomes the oldest supported stable
release.

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1895] Default groups for DH possibly backdoored

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=1895

--- Comment #9 from Phil Pennock  ---
IMO yes we're ready to drop support for older OpenSSL.  We set a clear policy,
it's over a year (or two?) after that point, and other projects have adopted
similar policies.

I haven't done anything to move us to the newer APIs.  That LibreSSL doesn't
support and doesn't like the cleaner configuration system of newer OpenSSL is a
little off-putting.  We've never formally said yes/no to supporting LibreSSL
but de facto we have supported it simply as a result of the APIs being
identical in the past, so we didn't need to care.

But for the ability to load a DH param including q?  Go for it!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1895] Default groups for DH possibly backdoored

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=1895

--- Comment #8 from Jeremy Harris  ---
Does this "missing q" affect a possible future that does TLS session resumption
(probably stateless, by caching tickets in the client hints DB)?

Have we hit the "switching support" point yet?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1895] Default groups for DH possibly backdoored

[admin]

https://bugs.exim.org/show_bug.cgi?id=1895

--- Comment #7 from Phil Pennock  ---
Current status: Exim 4.89 will "not support prior to 1.0.2" but in _practice_
we're keeping the codebase using old APIs for one final release, to give people
a little breathing room and an upgrade checkpoint.

After 4.89, we can start switching support to rely upon 1.0.2+ APIs, which gets
us the ability to load the q from DH and be in a slightly stronger
cryptographic position.

We're doing a bunch of stuff around re-using connections and TLS moving
forward, so rather than leave this as a timebomb just because it doesn't affect
us _now_, we should fix it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1895] Default groups for DH possibly backdoored

[admin]

https://bugs.exim.org/show_bug.cgi?id=1895

Phil Pennock  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #6 from Phil Pennock  ---
I have merged to master (following discussion with jgh and cryptographic input
from Viktor Dukhovni of Postfix (many thanks!)) a change which is not ideal,
but better.

http://git.exim.org/exim.git/commit/317e40ac8b1b816f4a22620a5647c6258de61598
https://github.com/Exim/exim/commit/317e40ac8b1b816f4a22620a5647c6258de61598

It's a signed commit because of the cryptographic material added, to provide
some provenance.

I have added the TLS groups from RFC 7919.  I also added three primes which I
generated in May of this year, to move away from the RFC-offered primes.

Because we load from PEM and still need to support OpenSSL pre-1.0.2, I can't
use the "X9.42 DH" CMS support to load DH parameters with q in them.  We're
loading PEM, so AFAICT our choices are "switch to DER embedding" (and not
support q in external files, elevating the Exim-internal parameters to
"especially privileged") or require OpenSSL 1.0.2.

I have sent mail to exim-announce:
  https://lists.exim.org/lurker/message/20161008.231103.c70b2da8.en.html
which warns of the issue, points to work-arounds, and reminds folks that as of
next year, OpenSSL 1.0.2 is the minimum supported by the OpenSSL project.

My understanding, from talking with people who actually understand the math in
crypto (where I'm at a rather more dangerous level, which is why I try hard to
_avoid_ forcing crypto policy on people) is that the missing "q" does not
matter for Exim's use-model, where we fork a new process for each new inbound
connection and establish the TLS context after that, never re-using it for
another connection.

So: I think that Exim 4.88 provides better options, with a better default,
here, but there's still more we can do next year.  But the commit does actually
resolve your issue, I believe, including providing the newly standardized DH
primes for those who want verifiable provenance.

Can you think of something we should be doing better, in advance of dropping
support for OpenSSL prior to 1.0.2 and supporting q in the DH parameters?

I think that after the next release, we might switch the structs of in-built
parameters to include a "deprecated" flag and log on start-up, but I'm really
not convinced it's worth it.  I strongly suspect that fewer than 10 people/orgs
in the world are explicitly setting `tls_dhparam` to any of the `ike` values:
they're taking the default, or specifying a filename, or specifying "historic"
or perhaps "none" for some weird reason (corporate snooping compatibility?).

If I'm wrong in any of the above, I truly do welcome education and pointers.  I
need to know more here.

Thanks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1895] Default groups for DH possibly backdoored

[admin]

https://bugs.exim.org/show_bug.cgi?id=1895

Git Commit  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
 CC||g...@exim.org

--- Comment #5 from Git Commit  ---
Git commit:
http://git.exim.org/exim.git/commitdiff/317e40ac8b1b816f4a22620a5647c6258de61598

commit 317e40ac8b1b816f4a22620a5647c6258de61598
Author: Phil Pennock 
AuthorDate: Sun May 29 02:31:18 2016 -0400
Commit: Phil Pennock 
CommitDate: Sat Oct 8 19:23:37 2016 -0400

dh parameters update, new values & default

* add three new exim-specific dh parameter constants; state provenance,
  but no way for others to verify; this is a signed commit, which is
  about as much as we can do for the truly paranoid: provide an audit
  trail.
* add the rfc 7919 dh primes
  + no tls feature negotiation, per 7919, but the dh primes can be used
if folks so choose
* fixed broken format string in util/gen_pkcs3.c
* tried to make gen_pkcs3.c support q values.
  + turns out, q doesn't affect the pem and that's not a mistake in my
initialisation; i've checked with a cryptographer, we're losing some
server-side optimizations but not any security properties for our
scenario.

fixes: 1895

 doc/doc-docbook/spec.xfpt |  38 +++-
 doc/doc-txt/ChangeLog |   3 +
 doc/doc-txt/NewStuff  |   2 +
 src/scripts/source_checks |   1 +
 src/src/std-crypto.c  | 503 +-
 src/util/.gitignore   |   2 +
 src/util/gen_pkcs3.c  |  41 +++-
 7 files changed, 574 insertions(+), 16 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1895] Default groups for DH possibly backdoored

[admin]

https://bugs.exim.org/show_bug.cgi?id=1895

Andreas Metzler  changed:

   What|Removed |Added

 CC||eximus...@bebt.de

--- Comment #4 from Andreas Metzler  ---
BTW I think the documentation on tls_dhparam is not completely correct for
GnuTLS:

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.

Afaict this is not OpenSSL-specific but also applies to GnuTLS.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1895] Default groups for DH possibly backdoored

[admin]

https://bugs.exim.org/show_bug.cgi?id=1895

--- Comment #3 from Watson Ladd  ---
http://eprint.iacr.org/2016/961.pdf has the most details about the concern.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1895] Default groups for DH possibly backdoored

[admin]

https://bugs.exim.org/show_bug.cgi?id=1895

--- Comment #2 from Jeremy Harris  ---
Internal ref: a799883d8ad3

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 1895] Default groups for DH possibly backdoored

[Viktor Dukhovni]

On Thu, Oct 06, 2016 at 07:08:38PM +, ad...@bugs.exim.org wrote:

> https://bugs.exim.org/show_bug.cgi?id=1895
> 
> --- Comment #1 from Jeremy Harris  ---
> Citation for this concern?

Watson tends to be rather well informed on crypto algorithms, the
immediate trigger for the ticket is I expect:

https://www.ietf.org/mail-archive/web/saag/current/threads.html#07407

I am not familiar with the underlying algorithmic number theory,
a reference would be good to have.

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1895] Default groups for DH possibly backdoored

[admin]

https://bugs.exim.org/show_bug.cgi?id=1895

--- Comment #1 from Jeremy Harris  ---
Citation for this concern?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##