RFC7919 Diffie-Hellman parameters in Fedora
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: RFC7919 Diffie-Hellman parameters in Fedora
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: RFC7919 Diffie-Hellman parameters in Fedora
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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Re: RFC7919 Diffie-Hellman parameters in Fedora
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: RFC7919 Diffie-Hellman parameters in Fedora
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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: RFC7919 Diffie-Hellman parameters in Fedora
On Sun, Aug 23, 2020 at 2:27 AM 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. 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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: RFC7919 Diffie-Hellman parameters in Fedora
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@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
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. 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@lists.fedoraproject.org > > > To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: RFC7919 Diffie-Hellman parameters in Fedora
- Original Message - > From: "Simo Sorce" > To: "Development discussions related to Fedora" > > 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@lists.fedoraproject.org > > > > To unsubscribe send an email to devel-le...@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@lists
Re: RFC7919 Diffie-Hellman parameters in Fedora
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/crypto-groups/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: RFC7919 Diffie-Hellman parameters in Fedora
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
