Date: Tue, 7 May 2019 12:01:15 -0500 From: Benjamin Kaduk <kaduk@mit.edu> To: John Baldwin <jhb@freebsd.org> Cc: arch@freebsd.org Subject: Re: Deprecating crypto algorithms in the kernel Message-ID: <20190507170115.GI19509@kduck.mit.edu> In-Reply-To: <245B376C-F79C-4615-8021-6692EE58CE60@gid.co.uk> References: <41ed59c2-f06c-710b-0e77-3b78add85ca3@FreeBSD.org> <245B376C-F79C-4615-8021-6692EE58CE60@gid.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi John, Thanks for taking this on; it seems worth doing. [inline] On Tue, May 07, 2019 at 04:13:18PM +0100, Bob Bishop wrote: > Hi, > > > On 7 May 2019, at 02:13, 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. 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. I can speak to Kerberos (I'm an author on RFC 8429), and we were pretty careful about what we deprecated. There may be some deployments that (e.g.) need to talk to legacy Windows versions that can't be easily upgraded, which may need to retain a legacy unix system as a communication partner, but anything that is running current software should be fine with these changes. (IIUC the Windows UI to enable AES for Kerberos is a bit clunky, but it does work.) For IPsec, I have also heard rumors about truly weird implementations that insist on old/bad algorithms, but don't have personal experience to relate. That said, the major version timeline that John is proposing still seems like a reasonable plan to me, as we should not let ourselves be held hostage by external legacy implementations that cannot upgrade. > > 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] > > > > commit 28ee9a2b109251829e940660b53a3551e70b720b > > Author: John Baldwin <jhb@FreeBSD.org> > > Date: Mon May 6 15:48:24 2019 -0700 > > > > Add deprecation warnings for IPsec algorithms deprecated in RFC 8221. > > > > All of these algorithms are either explicitly marked MUST NOT, or they are > > implicitly MUST NOTs by virtue of not being included in IETF's list of > > protocols at all despite having assignments from IANA. [see below] > > Specifically, this adds warnings for the following ciphers: > > - des-cbc > > - blowfish-cbc > > - cast128-cbc > > - des-deriv > > - des-32iv > > - camellia-cbc AFAIK Camellia is not bad per se, just not implemented/used much outside of Japan. For IETF protocols, it mostly got specified via Informational documents and not Standards-Track ones, since many people thought AES/etc. were fine. > > > > Warnings for the following authetication algorithms are also added: > > - hmac-md5 > > - keyed-md5 > > - keyed-sha1 > > - hmac-ripemd160 > > > > commit 0ab679486d7af95ff39fe8f43dd8a3c011088a9c > > Author: John Baldwin <jhb@FreeBSD.org> > > Date: Mon May 6 16:13:36 2019 -0700 > > > > Add warnings for Kerberos GSS algorithms deprecated in RFCs 6649 and 8429. > > > > All of these algorithms are explicitly marked SHOULD NOT in one of these > > RFCs. > > > > Specifically, RFC 6649 deprecates all algorithms using DES as well as > > the "export-friendly" variant of RC4. RFC 8429 deprecates Triple DES > > and the remaining RC4 algorithms. > > > > commit 9821e245defdac414636a9f2ea4a920f75bdea8a > > Author: John Baldwin <jhb@FreeBSD.org> > > Date: Mon May 6 16:34:46 2019 -0700 > > > > Add warnings to /dev/crypto for deprecated algorithms. > > > > These algorithms are deprecated algorithms that will have no in-kernel > > consumers in FreeBSD 13. Specifically, deprecate the following algorithms: > > - DES > > - CAST128 > > - Skipjack > > - ARC4 > > > > commit dcd2c0a4a4e5a82f7cec2fc7e77e9356c1125765 > > Author: John Baldwin <jhb@FreeBSD.org> > > Date: Mon May 6 17:39:56 2019 -0700 > > > > Add deprecation warnings for weaker algorithms to geli(4). > > > > - Triple DES has been formally deprecated in Kerberos (RFC 8429) > > and is soon to be deprecated in IPsec (RFC 8221). It is generally > > considered a weak cipher. Nitpicking the wording: it's not so much that it's weak per se (even single-DES is just falling to the 56-bit brute-force attack, and I think triple-DES still basically holds the expected 112-bit strength), but it's quite slow and has a 64-bit block size, which increases the risk of birthday collisions. I'm all for replacing/removing it, but mostly not because I think it's "weak". -Ben > > - Blowfish is deprecated. FreeBSD doesn't support its successor > > (Twofish). > > - MD5 is generally considered a weak digest that has known attacks. > > > > geli refuses to create new volumes using these algorithms and warns > > when attaching to existing volumes. The plan is to fully remove support > > for these algorithms in FreeBSD 13. > > > > commit 18e69bec6ee11ca2c7e89752ddab97bb8f776c7b > > Author: John Baldwin <jhb@FreeBSD.org> > > Date: Mon May 6 17:54:33 2019 -0700 > > > > Add additional warnings to /dev/crypto for deprecated algorithms. > > > > If these algorithms are removed from geli(4) then there will no longer be > > any in-kernel consumers: > > - 3DES > > - Blowfish > > - MD5-HMAC > > > > -- > > -- > > John Baldwin > > _______________________________________________ > > freebsd-arch@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190507170115.GI19509>