Date: Thu, 23 May 2019 18:12:59 -0700 From: John Baldwin <jhb@FreeBSD.org> To: rgrimes@freebsd.org Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r348205 - head/sys/netipsec Message-ID: <2ccc4dd0-19d4-981e-82cb-c6fcab355eda@FreeBSD.org> In-Reply-To: <201905240051.x4O0pSI3093116@gndrsh.dnsmgr.net> References: <201905240051.x4O0pSI3093116@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/23/19 5:51 PM, Rodney W. Grimes wrote: >> Author: jhb >> Date: Thu May 23 22:06:57 2019 >> New Revision: 348205 >> URL: https://svnweb.freebsd.org/changeset/base/348205 >> >> Log: >> 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. > > Can you provide me these specific ones and I'll investigate > the Ietf datatracker and IANA documents and see if I can > get the long story. Ie what IANA assignments are you refering > to that do not appear in RFC, it may simply be the case there > is a final RFC that says "new foo are assigned numbers by IANA > and no RFC is needed" That is how port numbers and other > such things just are, there is not a RFC for everything! I suggest you start by reading RFC 8221 to get an understanding for why the commit log uses the language it does. >> Specifically, this adds warnings for the following ciphers: >> - des-cbc >> - blowfish-cbc >> - cast128-cbc >> - des-deriv >> - des-32iv >> - camellia-cbc The RFC explicitly lists all DES variants and blowfish as MUST NOT in the table in section 5. As far as I can tell, the draft document for CAST expired in 1997: https://tools.ietf.org/html/draft-ietf-ipsec-esp-cast-128-cbc-00 As noted in the review comments, Camellia is the only one of these ciphers that might be worth retaining if there are actual users. It is in theory comparable to AES, but it is not widely used. In addition, whereas with AES we support AEAD modes such as AES-GCM and AES-CCM (though we do not currently support AES-CCM with IPsec), for Camellia we only support CBC. I believe there are specs for CCM and GCM modes for Camellia but no one has implemented them. In terms of algorithm diversity, it would be better to expend effort on supporting chacha20 + poly1035-hmac (as RFC 8221 suggests since these are now a SHOULD) rather than Camellia. >> Warnings for the following authentication algorithms are also added: >> - hmac-md5 >> - keyed-md5 >> - keyed-sha1 >> - hmac-ripemd160 hmac-md5 and keyed-md5 are both MUST NOT in 8221. The Internet (google) doesn't seem to think that keyed-sha1 even exists, so I wonder if it's a local invention in FreeBSD. sha1 is MUST- in 8221 so we probably should be removing it soon, but this change does not do that. ripemd160 is a more obscure hash that is more like sha1 than the sha2 variants. RFC 6071 states that you can't use ripemd with IKE due to no IANA number which would seem to preclude its use in any "real" deployments (and 6071 is already 8 years old). -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2ccc4dd0-19d4-981e-82cb-c6fcab355eda>