From owner-freebsd-arch@freebsd.org Tue May 7 15:13:28 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6DE68158A498 for ; Tue, 7 May 2019 15:13:28 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id BBD018D27D for ; Tue, 7 May 2019 15:13:27 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: by mailman.ysv.freebsd.org (Postfix) id 7C26F158A497; Tue, 7 May 2019 15:13:27 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6AA3C158A495 for ; Tue, 7 May 2019 15:13:27 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EBD9F8D27B; Tue, 7 May 2019 15:13:26 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from [194.32.164.27] ([194.32.164.27]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id x47FDIte044271; Tue, 7 May 2019 16:13:18 +0100 (BST) (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Deprecating crypto algorithms in the kernel From: Bob Bishop In-Reply-To: <41ed59c2-f06c-710b-0e77-3b78add85ca3@FreeBSD.org> Date: Tue, 7 May 2019 16:13:18 +0100 Cc: arch@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <245B376C-F79C-4615-8021-6692EE58CE60@gid.co.uk> References: <41ed59c2-f06c-710b-0e77-3b78add85ca3@FreeBSD.org> To: John Baldwin X-Mailer: Apple Mail (2.3273) X-Rspamd-Queue-Id: EBD9F8D27B X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.968,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 15:13:28 -0000 Hi, > On 7 May 2019, at 02:13, John Baldwin 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