Date: Tue, 7 May 2019 12:44:36 -0700 From: John Baldwin <jhb@FreeBSD.org> To: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, cem@freebsd.org Cc: "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: Deprecating crypto algorithms in the kernel Message-ID: <0c8c59cf-7d3a-a751-0775-47b1bc0403df@FreeBSD.org> In-Reply-To: <201905071939.x47JdPQA013095@gndrsh.dnsmgr.net> References: <201905071939.x47JdPQA013095@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/7/19 12:39 PM, Rodney W. Grimes wrote: >> 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. This does not affect TCPMD5. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0c8c59cf-7d3a-a751-0775-47b1bc0403df>