9:13 a.m.
Hi,
tl;dr should we make it easier/automatic for users to use the
Diffie-Hellman parameters defined in RFC7919?
For a long time, the general recommendation for Finite-Field
Diffie-Hellman Ephemeral Parameters (FFDHE, for use with
non-elliptic-curve DH, i.e. the dhparam-file many server configs ask us
to specify) used in TLS was to generate your own. However, RFC7919
specifies fixed, auditable parameters with lengths of 2048-8102 bits
[1], Mozilla has switched their recommendation from 'generate your own'
to 'use ffdhe2048' [2] and IIRC TLSv3 mandates their use.
Main advantage in using them is a) since they're fixed & well-defined,
they can be and are audited, b) clients don't have to check whether
parameters they're given by a server are legit or meddled with
(something that usually any client program would have to but few
actually do).
So, questions:
1) do we already ship these groups somewhere, e.g. via a package that I
don't know about? If not, should we maybe add one?
2) Many programs either ship their own dhparam files (on my systems at
least proftpd, certbot & openssh, via the moduli file) or expect the
user to point them to one (like webservers, dovecot, postfix etc.) +
some for sure hardcode some defaults if the user does not specify
parameters. Would it make sense to change their defaults - if possible -
to use (one of the) RFC7919 groups? One could even integrate this with
crypto-policies, if at some point one wants to e.g. change the desired
group size.
Best,
Christopher
[1] https://tools.ietf.org/html/rfc7919
[2] https://wiki.mozilla.org/index.php?title=Security/Server_Side_TLS
9:26 p.m.
Christopher Engelhard wrote:
tl;dr should we make it easier/automatic for users to use the
Diffie-Hellman parameters defined in RFC7919?
While I understand the motivation behind the RFC (interoperability, safety
against intentionally or unintentionally bad parameters), hardcoded
parameters sound suspicious to me. How do we know that these are not chosen
to allow the NSA or some other country's equivalent agency to decrypt the
conversation?
Kevin Kofler
5:49 a.m.
On 23.08.20 04:26, Kevin Kofler wrote:
While I understand the motivation behind the RFC (interoperability,
safety
against intentionally or unintentionally bad parameters), hardcoded
parameters sound suspicious to me. How do we know that these are not chosen
to allow the NSA or some other country's equivalent agency to decrypt the
conversation?
Good point, that's a thorny issue in general.
I have, of course, not way to disprove that, but those parameters are
not just some random magic numbers, they're derived from a public,
defined & simple [1] formula, using as far as possible common constants
with no known relation to the DHE problem. This is no different than the
process that gives us Ed25519 [2], although admittedly that one is more
extensively explained in the relevant RFC.
There are mathematical ways of looking for trapdoors, and having the
method that created the number known makes such analysis feasable.
In the ideal case, (1) server operator A generates & validates & uses
safe parameters, and (2) user B knows & trusts A to have done so.
However, in general while (1) might well be true, but (2) usually isn't.
So the tradeoff is 'unvetted but secret' vs. 'highly vetted but known to
the NSA'.
There's probably no good answer here (other than not using FFDHE, of
course), but I think given that Fedora by default also uses the
potentially-NSA-tainted NIST curves & TLSv3 with FFDHE, encouraging use
of RFC7919 generally removes some potential security issues while not
introducing attack vectors that we already deem not significant (in
default configurations - what anyone deems significant for their own
system is of course entirely their business).
Christopher
[1] for a given definition of simple - RFC7919 primes are defined as
p = 2^b - 2^{b-64} + (floor(2^{b-130}*e)+X) * 2^64 - 1
where b is the bitsize and X is the smallest integer that creates a safe
prime.
[2] https://tools.ietf.org/html/rfc7748#appendix-A
There's some discussion of the general problem of validating DHE
parameters here:
[3] https://eprint.iacr.org/2019/032.pdf
11:40 a.m.
On Sun, 2020-08-23 at 04:26 +0200, Kevin Kofler wrote:
Christopher Engelhard wrote:
> tl;dr should we make it easier/automatic for users to use the
> Diffie-Hellman parameters defined in RFC7919?
While I understand the motivation behind the RFC (interoperability, safety
against intentionally or unintentionally bad parameters), hardcoded
parameters sound suspicious to me. How do we know that these are not chosen
to allow the NSA or some other country's equivalent agency to decrypt the
conversation?
You don't, except for all the reviews mentioned, which are definitely
more review than randomly selected parameters which often are more
suspicious.
If you are worried about DH I suggest you just disable it entirely and
rely on RSA/ECDH key exchanges instead.
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
11:57 a.m.
On Sun, Aug 23, 2020 at 2:27 AM Kevin Kofler <kevin.kofler(a)chello.at> wrote:
While I understand the motivation behind the RFC (interoperability,
safety
against intentionally or unintentionally bad parameters), hardcoded
parameters sound suspicious to me.
I'll note that the RFC 7919 values were added
as available in openssl and nss somewhere
between three and four years ago as I recall.
11:51 a.m.
On 8/22/20 7:26 PM, Kevin Kofler wrote:
Christopher Engelhard wrote:
> tl;dr should we make it easier/automatic for users to use the
> Diffie-Hellman parameters defined in RFC7919?
While I understand the motivation behind the RFC (interoperability, safety
against intentionally or unintentionally bad parameters), hardcoded
parameters sound suspicious to me. How do we know that these are not chosen
to allow the NSA or some other country's equivalent agency to decrypt the
conversation?
TL/DR:
Most "randomly" chosen values for primes today are known to be subject
to small group attacks. Getting this right is difficult (which I'll
demonstrate below). The chosen primes were vetted by the TLS working
group based on physical constants and a generation scheme that has the
required safe criteria. That is these values meet the requirements that
we already know. We can all recheck them. The chances that the NSA has
an attack, that happens to work on primes that someone else (IETF)
generated, and doesn't work on all DH primes is pretty unlikely. As simo
says, If you are worried, don't use DH. If you aren't using one of these
primes, your DH connection is probably vulnerable to active attacks.
Longer explanation:
In order to do DH safely, you need to make sure that the public key you
are provided is in a large subgroup. This can be checked in the
following ways:
* The prime 'P' is a safe prime (sometimes incorrectly called a strong
prime. This means the p is prime and (p-1)/2 is prime (in this case
(p-1)/2 is called a Sofie-germaine prime).
o You check p is prime, and (p-1)/2 is prime. This is expensive
for a random prime.
o You check that the public key y is < p, and != 0, 1, or -1 mod
p. This check is very fast.
* The prime 'P is not a safe prime, but you know a large prime 'q'
which is a factor of (p-1).
o You check that p is prime, and q is prime.
o You check that y^q mod p == 1
o You check y != 1 or -1
If you precheck known 'P' values you can skip the very expensive prime
checks (because we've already checked those values and they are known to
be good). To make matters worse, It's very expensive to generate a safe
prime for large prime values. If you search the internet about how to
do this, they well give you instructions on how to generate a non-safe
prime with large q, but none of our common protocols include a q value,
which means you cannot do either the prime check or the y^q mod p ==1
check, and thus a man in the middle attacker can supply a q that falls
in a small subgroup and eaves-drop on your connection.
TLS 1.3 allows you to only connect if the server is using a known prime,
which has already been vetted as a safe prime. If you aren't using and
requiring these primes, you basically have the following choices:
1) use RSA and loose PFS.
2) use ECDH (which will likely fall to quantum computers first).
Since Quantum computers will ultimately remove PFS, ECDH is probably
your best bet. But then you are again trusting in fixed sets of Curves
that came from somewhere, and if you are paranoid about the NSA, well....
11:43 a.m.
On Fri, 2020-08-21 at 16:13 +0200, Christopher Engelhard wrote:
Hi,
tl;dr should we make it easier/automatic for users to use the
Diffie-Hellman parameters defined in RFC7919?
We already are making it easier in some ways, but feel free to open a
bug if there are specific components you are worried about.
Simo.
For a long time, the general recommendation for Finite-Field
Diffie-Hellman Ephemeral Parameters (FFDHE, for use with
non-elliptic-curve DH, i.e. the dhparam-file many server configs ask us
to specify) used in TLS was to generate your own. However, RFC7919
specifies fixed, auditable parameters with lengths of 2048-8102 bits
[1], Mozilla has switched their recommendation from 'generate your own'
to 'use ffdhe2048' [2] and IIRC TLSv3 mandates their use.
Main advantage in using them is a) since they're fixed & well-defined,
they can be and are audited, b) clients don't have to check whether
parameters they're given by a server are legit or meddled with
(something that usually any client program would have to but few
actually do).
So, questions:
1) do we already ship these groups somewhere, e.g. via a package that I
don't know about? If not, should we maybe add one?
2) Many programs either ship their own dhparam files (on my systems at
least proftpd, certbot & openssh, via the moduli file) or expect the
user to point them to one (like webservers, dovecot, postfix etc.) +
some for sure hardcode some defaults if the user does not specify
parameters. Would it make sense to change their defaults - if possible -
to use (one of the) RFC7919 groups? One could even integrate this with
crypto-policies, if at some point one wants to e.g. change the desired
group size.
Best,
Christopher
[1] https://tools.ietf.org/html/rfc7919
[2] https://wiki.mozilla.org/index.php?title=Security/Server_Side_TLS
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
12:29 p.m.
On 24.08.20 18:43, Simo Sorce wrote:
On Fri, 2020-08-21 at 16:13 +0200, Christopher Engelhard wrote:
We already are making it easier in some ways, but feel free to open a
bug if there are specific components you are worried about.
What ways are that?
I'm not worried about any specific component, I'm just looking for
opinions wrt Fedora defaulting to these parameters generally, where
possible.
(I was thinking along the lines of a package containing those parameters
& letting other packages link to those files instead of of asking the
user to get/create the files themselves - so dovecot, instead of having
/etc/dovecot/dh.pem in it's default conf files, could Require: that
package and have /etc/pki/dhparam/something.pem or whatever.)
Christopher
Simo.
> For a long time, the general recommendation for Finite-Field
> Diffie-Hellman Ephemeral Parameters (FFDHE, for use with
> non-elliptic-curve DH, i.e. the dhparam-file many server configs ask us
> to specify) used in TLS was to generate your own. However, RFC7919
> specifies fixed, auditable parameters with lengths of 2048-8102 bits
> [1], Mozilla has switched their recommendation from 'generate your own'
> to 'use ffdhe2048' [2] and IIRC TLSv3 mandates their use.
>
> Main advantage in using them is a) since they're fixed & well-defined,
> they can be and are audited, b) clients don't have to check whether
> parameters they're given by a server are legit or meddled with
> (something that usually any client program would have to but few
> actually do).
>
> So, questions:
> 1) do we already ship these groups somewhere, e.g. via a package that I
> don't know about? If not, should we maybe add one?
> 2) Many programs either ship their own dhparam files (on my systems at
> least proftpd, certbot & openssh, via the moduli file) or expect the
> user to point them to one (like webservers, dovecot, postfix etc.) +
> some for sure hardcode some defaults if the user does not specify
> parameters. Would it make sense to change their defaults - if possible -
> to use (one of the) RFC7919 groups? One could even integrate this with
> crypto-policies, if at some point one wants to e.g. change the desired
> group size.
>
> Best,
> Christopher
>
> [1] https://tools.ietf.org/html/rfc7919
> [2] https://wiki.mozilla.org/index.php?title=Security/Server_Side_TLS
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
1:06 p.m.
On Mon, 2020-08-24 at 19:29 +0200, Christopher Engelhard wrote:
On 24.08.20 18:43, Simo Sorce wrote:
> On Fri, 2020-08-21 at 16:13 +0200, Christopher Engelhard wrote:
> We already are making it easier in some ways, but feel free to open a
> bug if there are specific components you are worried about.
What ways are that?
Some of the crypto libraries use only named DH moduli in FIPS mode
(more relevant for RHEL) for example, regardless of configuration.
So we have already some experience with this problem, but we haven't
pursued this to force everything to just use the RFC parameters.
I'm not worried about any specific component, I'm just
looking for
opinions wrt Fedora defaulting to these parameters generally, where
possible.
(I was thinking along the lines of a package containing those parameters
& letting other packages link to those files instead of of asking the
user to get/create the files themselves - so dovecot, instead of having
/etc/dovecot/dh.pem in it's default conf files, could Require: that
package and have /etc/pki/dhparam/something.pem or whatever.)
This has been proposed (somewhere, I forgot where) before, and it is a
definite possibility.
Unclear what package would distribute them, potentially the crypto-
policies package.
Simo.
Christopher
> Simo.
>
> > For a long time, the general recommendation for Finite-Field
> > Diffie-Hellman Ephemeral Parameters (FFDHE, for use with
> > non-elliptic-curve DH, i.e. the dhparam-file many server configs ask us
> > to specify) used in TLS was to generate your own. However, RFC7919
> > specifies fixed, auditable parameters with lengths of 2048-8102 bits
> > [1], Mozilla has switched their recommendation from 'generate your own'
> > to 'use ffdhe2048' [2] and IIRC TLSv3 mandates their use.
> >
> > Main advantage in using them is a) since they're fixed & well-defined,
> > they can be and are audited, b) clients don't have to check whether
> > parameters they're given by a server are legit or meddled with
> > (something that usually any client program would have to but few
> > actually do).
> >
> > So, questions:
> > 1) do we already ship these groups somewhere, e.g. via a package that I
> > don't know about? If not, should we maybe add one?
> > 2) Many programs either ship their own dhparam files (on my systems at
> > least proftpd, certbot & openssh, via the moduli file) or expect the
> > user to point them to one (like webservers, dovecot, postfix etc.) +
> > some for sure hardcode some defaults if the user does not specify
> > parameters. Would it make sense to change their defaults - if possible -
> > to use (one of the) RFC7919 groups? One could even integrate this with
> > crypto-policies, if at some point one wants to e.g. change the desired
> > group size.
> >
> > Best,
> > Christopher
> >
> > [1] https://tools.ietf.org/html/rfc7919
> > [2] https://wiki.mozilla.org/index.php?title=Security/Server_Side_TLS
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
2:08 p.m.
----- Original Message -----
From: "Simo Sorce" <simo(a)redhat.com>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
Sent: Monday, August 24, 2020 2:06:19 PM
Subject: Re: RFC7919 Diffie-Hellman parameters in Fedora
On Mon, 2020-08-24 at 19:29 +0200, Christopher Engelhard wrote:
> On 24.08.20 18:43, Simo Sorce wrote:
> > On Fri, 2020-08-21 at 16:13 +0200, Christopher Engelhard wrote:
> > We already are making it easier in some ways, but feel free to open a
> > bug if there are specific components you are worried about.
>
> What ways are that?
Some of the crypto libraries use only named DH moduli in FIPS mode
(more relevant for RHEL) for example, regardless of configuration.
So we have already some experience with this problem, but we haven't
pursued this to force everything to just use the RFC parameters.
> I'm not worried about any specific component, I'm just looking for
> opinions wrt Fedora defaulting to these parameters generally, where
> possible.
>
> (I was thinking along the lines of a package containing those parameters
> & letting other packages link to those files instead of of asking the
> user to get/create the files themselves - so dovecot, instead of having
> /etc/dovecot/dh.pem in it's default conf files, could Require: that
> package and have /etc/pki/dhparam/something.pem or whatever.)
This has been proposed (somewhere, I forgot where) before, and it is a
definite possibility.
Unclear what package would distribute them, potentially the crypto-
policies package.
I at least mentioned this in a conversation with you IRC or perhaps email.
As a maintainer, this would've made the late FIPS changes much more
palatable.
I've opened the following BZ for this:
https://bugzilla.redhat.com/show_bug.cgi?id=1871988
- Alex
Simo.
> Christopher
>
> > Simo.
> >
> > > For a long time, the general recommendation for Finite-Field
> > > Diffie-Hellman Ephemeral Parameters (FFDHE, for use with
> > > non-elliptic-curve DH, i.e. the dhparam-file many server configs ask us
> > > to specify) used in TLS was to generate your own. However, RFC7919
> > > specifies fixed, auditable parameters with lengths of 2048-8102 bits
> > > [1], Mozilla has switched their recommendation from 'generate your
own'
> > > to 'use ffdhe2048' [2] and IIRC TLSv3 mandates their use.
> > >
> > > Main advantage in using them is a) since they're fixed &
well-defined,
> > > they can be and are audited, b) clients don't have to check whether
> > > parameters they're given by a server are legit or meddled with
> > > (something that usually any client program would have to but few
> > > actually do).
> > >
> > > So, questions:
> > > 1) do we already ship these groups somewhere, e.g. via a package that I
> > > don't know about? If not, should we maybe add one?
> > > 2) Many programs either ship their own dhparam files (on my systems at
> > > least proftpd, certbot & openssh, via the moduli file) or expect the
> > > user to point them to one (like webservers, dovecot, postfix etc.) +
> > > some for sure hardcode some defaults if the user does not specify
> > > parameters. Would it make sense to change their defaults - if possible
> > > -
> > > to use (one of the) RFC7919 groups? One could even integrate this with
> > > crypto-policies, if at some point one wants to e.g. change the desired
> > > group size.
> > >
> > > Best,
> > > Christopher
> > >
> > > [1] https://tools.ietf.org/html/rfc7919
> > > [2] https://wiki.mozilla.org/index.php?title=Security/Server_Side_TLS
> > > _______________________________________________
> > > devel mailing list -- devel(a)lists.fedoraproject.org
> > > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> > > Fedora Code of Conduct:
> > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> > >
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
10:10 a.m.
On 24.08.20 20:06, Simo Sorce wrote:
This has been proposed (somewhere, I forgot where) before, and it is
a
definite possibility.
Unclear what package would distribute them, potentially the crypto-
policies package.
Or a separate package, but at least the logic of selecting a default
from the available groups should probably reside in crypto-policies.
Christopher
P.S.: I put the package I created to install various default DH groups
on my systems on Copr, in case this is useful for anyone else:
https://gitlab.com/lcts/crypto-groups
https://copr.fedorainfracloud.org/coprs/lcts/fedora-rpm-addons/package/cr...
1340
days inactive
1344
days old
10 comments
6 participants
participants (6)
-
Alex Scheel -
Christopher Engelhard -
Gary Buhrmaster -
Kevin Kofler -
Robert Relyea -
Simo Sorce