Date: Tue, 7 May 2019 12:39:25 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: cem@freebsd.org Cc: John Baldwin <jhb@freebsd.org>, "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: Deprecating crypto algorithms in the kernel Message-ID: <201905071939.x47JdPQA013095@gndrsh.dnsmgr.net> In-Reply-To: <CAG6CVpXRkVgwzKdtnp5nqcBMU4MZH9d_45Tn9HwBHQ3%2BwT7OOQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Mon, May 6, 2019 at 6:14 PM John Baldwin <jhb@freebsd.org> wrote: > > I have been doing some work off and on to address some of the shortcomings > > in the in-kernel open crypto framework. ? some of the currently supported > > algorithms have known weaknesses or are deprecated in RFCs, by the authors, > > etc. I would like to take a stab at trimming some of this for FreeBSD 13. > > For an initial proposal, ? > > > > This adds runtime deprecation notices in the kernel when using deprecated > > algorithms for IPsec (according to RFC 8221), and Kerberos GSS (RFCs 6649 > > and 8429). It then also adds deprecation notices for a few algorithms in > > GELI. For GELI, the current patches should refuse to create new volumes > > with these algorithms and warn when mounting an existing volume. > > > > The current optimistic goal would be to merge all the warning back to 11 > > and 12 and then remove support for these algorithms outright in 13.0. > > For GELI in particular, I recognize this is somewhat painful as it means > > doing a dump/restore if you've created volumes with affected algorithms. > > OTOH, these algorithms are not the current defaults. > > Nor were they ever ? the default has always been an aes-based > algorithm since the initial import of GELI in 2005 (r148456). > > > Finally, I've added warnings to /dev/crypto to warn if userland tries to > > create new sessions for algorithms that no longer have any non-deprecated > > in-kernel consumers. > > We've discussed this offline, but I just wanted to remark on the > public lists that I'm all in favor of removing crufty bad crypto > algorithms, and your chosen list seems to meet that criteria while > being a conservative change. Please kill 'em. :-) Does doing this in any way break TCPMD5, which is extensively still in use for BGP sessions. Breaking that would probably be a bad idea. -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201905071939.x47JdPQA013095>