[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: RFC7919 Diffie-Hellman parameters in Fedora
From:       Alex Scheel <ascheel () redhat ! com>
Date:       2020-08-24 19:08:48
Message-ID: 1573790052.9498825.1598296128946.JavaMail.zimbra () redhat ! com
[Download RAW message or body]

----- Original Message -----
> From: "Simo Sorce" <simo@redhat.com>
> To: "Development discussions related to Fedora" <devel@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@lists.fedoraproject.org
> > > > To unsubscribe send an email to devel-leave@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-leave@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-leave@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-leave@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

[prev in list] [next in list] [prev in thread] [next in thread]