svn commit: r348205 - head/sys/netipsec

[John Baldwin]

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