Deprecating crypto algorithms in the kernel

[Bob Bishop]

Hi,

> On 7 May 2019, at 02:13, John Baldwin <jhb at 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.  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:
> 
> https://github.com/freebsd/freebsd/compare/master...bsdjhb:crypto_warn
> 
> 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’t 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’t 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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 at gid.co.uk