Date: Tue, 7 May 2019 16:13:18 +0100 From: Bob Bishop <rb@gid.co.uk> To: John Baldwin <jhb@freebsd.org> Cc: arch@freebsd.org Subject: Re: Deprecating crypto algorithms in the kernel Message-ID: <245B376C-F79C-4615-8021-6692EE58CE60@gid.co.uk> 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
Hi, > On 7 May 2019, at 02:13, John Baldwin <jhb@freebsd.org> wrote: >=20 > I have been doing some work off and on to address some of the = shortcomings > in the in-kernel open crypto framework. However, some complexity can = be > removed by having fewer algorithms. Also, 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, I have a set of (untested) changes in a git = branch > here: >=20 > https://github.com/freebsd/freebsd/compare/master...bsdjhb:crypto_warn >=20 > 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). Can=E2=80=99t speak to Kerberos, but I have an uneasy feeling that in = the case of IPsec there may be implementations out there that require = the obsolescent algorithms to interwork, RFC 8221 notwithstanding. = Haven=E2=80=99t had to do it myself for a while but last time I remember = being surprised by how far behind the curve the other end was. > 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. >=20 > 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. >=20 > 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. >=20 > I've attached the log messages from the commits below to give a bit = more > detail about the proposed changes. There is also an 'ipsec_deprecate' > branch that has a few of the actual remove commits if you want to see > what those look like, but the first step is really to decide what = changes > we should/can make and adding suitable warnings. >=20 > BTW, not listed here is the compression support for IPsec. That = actually > adds a fair bit of complexity, and it also in my testing doesn't = actually > work on head. However, RFC 8221 notes that it is not widely = implemented > and is generally considered optional (the RFC lists all of the = algorithms > of which FreeBSD only supports 1 as MAY). > [etc] -- Bob Bishop rb@gid.co.uk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?245B376C-F79C-4615-8021-6692EE58CE60>