Deprecating crypto algorithms in the kernel

John Baldwin jhb at FreeBSD.org
Tue May 7 19:44:39 UTC 2019


On 5/7/19 12:39 PM, Rodney W. Grimes wrote:
>> On Mon, May 6, 2019 at 6:14 PM 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.  ? 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


More information about the freebsd-arch mailing list