Re: [IPsec] revisiting 3DES and -graveyard

[Paul Wouters <[e-mail]>]

On Tue, 14 Apr 2020, Benjamin Kaduk wrote:

> I see in
> https://datatracker.ietf.org/meeting/104/materials/minutes-104-ipsecme-00
> that we didn't want to get rid of 3DES at that time.  Do we have a sense
> for how quickly that will change, the scope of existing deployments, etc.?

3DES is already defined as SHOULD NOT. The next step in evolation would
be a MUST NOT. So I think we are on the right path. The SHOULD NOT
recommendation is from 2.5 years ago. Unfortunately, VPN deployments
are slow to change, and I fear that a lot of IKEv1 gear is still out
there running on 1990's configuration with 3DES, MD5/SHA1 and DH2/5.
But I think those deployments will die out over time as hardware is
replaced, and configurations are (very very slowly) upgraded.

Anything with IKEv2 already does not really use 3DES anywhere.

> In particular, would a general-purpose OS's implementation cause problems
> for its consumers if the next release dropped support?  (Noting that
> consumers could stay on an old OS release to match the old algorithms, at
> least for a while.)

General-purpose OS's are a bit more modern than hardware VPN boxes.
These all already do IKEv2 and even for IKEv1 would default to AES/AES-GCM.
They would not need 3DES unless it is talking to a 1990's device.

Note that in Fedora and RHEL, we already have a systemwide crypto policy
that also applies to IKE/IPsec, and its DEFAULT policy is:
(see /usr/share/crypto-policies/DEFAULT/libreswan.txt)

 	ikev2=insist
 	pfs=yes
 	ike=aes_gcm256-sha2_512+sha2_256-dh19+dh20+dh21+dh14+dh15+dh16+dh18,chacha20_poly1305-sha2_512+sha2_256-dh19+dh20+dh21+dh14+dh15+dh16+dh18,aes256-sha2_512+sha2_256-dh19+dh20+dh21+dh14+dh15+dh16+dh18,aes_gcm128-sha2_512+sha2_256-dh19+dh20+dh21+dh14+dh15+dh16+dh18,aes128-sha2_256-dh19+dh20+dh21+dh14+dh15+dh16+dh18
 	esp=aes_gcm256,chacha20_poly1305,aes256-sha2_512+sha1+sha2_256,aes_gcm128,aes128-sha1+sha2_256

So no 3DES. I don't know how often people are overriding this on a
per-configuration basis, but we (redhat) have definitely not had
any complains of people who wanted to use 3des.

I just noticed even our LEGACY systemwide crypto policy does not allow 3DES.
I'm checking with our crypto people to see if that is by design or a bug.
I think it is by design because even our LEGACY policy insists on ikev2 :)

So in short, general purpose OSes have no problem, but might need to
talk to 1990s old gear.

I do think the next document update should change 3DES to MUST NOT. But
I would like the graveyard draft to go out first pointing a bit further
to the death of IKEv1. Perhaps a document update for October would be
good? That would have given 3DES three years to go from SHOULD NOT to
MUST NOT.

Paul