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@xxxxxxxxxxxxxxxxxxxxxxx > > > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > > 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@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx -- Simo Sorce RHEL Crypto Team Red Hat, Inc _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
