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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
