Date: Tue, 7 May 2019 08:55:12 -0700 From: Conrad Meyer <cem@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: Deprecating crypto algorithms in the kernel Message-ID: <CAG6CVpXRkVgwzKdtnp5nqcBMU4MZH9d_45Tn9HwBHQ3%2BwT7OOQ@mail.gmail.com> In-Reply-To: <41ed59c2-f06c-710b-0e77-3b78add85ca3@FreeBSD.org> References: <41ed59c2-f06c-710b-0e77-3b78add85ca3@FreeBSD.org>
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 shortcoming= s > in the in-kernel open crypto framework. =E2=80=A6 some of the currently = supported > algorithms have known weaknesses or are deprecated in RFCs, by the author= s, > etc. I would like to take a stab at trimming some of this for FreeBSD 13= . > For an initial proposal, =E2=80=A6 > > 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 =E2=80=94 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. :-) Best, Conrad
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpXRkVgwzKdtnp5nqcBMU4MZH9d_45Tn9HwBHQ3%2BwT7OOQ>