svn commit: r348205 - head/sys/netipsec

[Rodney W. Grimes]

> 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.

I understand the language, I want to know which IANA assigned
numbers entries are at issue here without having to recreate
that list from your commit and RFC 8221.

I have 0 issue with the deprecation as it stands,
and am wanting to see why this issue in the Ietf/IANA
documentation exists.

> >>   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

Well at least 00 expired, the problem here is that this is
attempting to track things in the wrong direction, and it may
of totally changed name shapes so is hard to find in the
data tracker.  I did confirm that this document pretty much
died at submission.

> 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).

I did not need that info, just a list of IANA assigned numbers
of things you can not find in RFC/Ietf documents.  I'll do the
leg work from the other side and if Ietf/Iana documents need
fixed I'll get that in process.

> -- 
> John Baldwin
-- 
Rod Grimes                                                 rgrimes at freebsd.org