Subject: [IPsec] revisiting 3DES and -graveyard

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 14 Apr 2020 19:13:21 -0700

Hi all,

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

Thanks,

Ben

---

From: Paul Wouters <[email-masked]>
Date: Tue, 14 Apr 2020 23:13:05 -0400 (EDT)

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

> consumers could stay on an old OS release to match the old algorithms, at

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

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 15 Apr 2020 15:49:01 +0300

> for how quickly that will change, the scope of existing deployments, etc.?

One of the problems is that we as an IETF give instructions to
implementors, not to users. If we change 3DES MUST NOT, then all
implementations out there who do implement 3DES, but where it is
disabled in configuration by default are no longer conformant to the
new RFC, as they do still implement 3DES.

Anybody who puts 3DES in any of the new implementations or new
releases of the current implementations are going against the SHOULD
NOT in the current RFC.

Meaning they most likely have some old legacy stuff they need to
support which only supports 3DES and thats why they want to keep 3DES
in their current releases as they want to be able to talk to those.

I would wait bit more than 2.5 years before saying MUST NOT. 

> consumers could stay on an old OS release to match the old algorithms, at

Especially with consumers and general-purpose OS there is no option
for using old OS release anymore. Most of those will automatically
update to latest version, and there usually isn't any easy way to
downgrade back to previous version when issues are found.
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 Apr 2020 11:03:49 -0400

> consumers could stay on an old OS release to match the old algorithms, at

1) They all have AES128, and have had it for at least a decade.

2) general-purpose OS implementations are (sadly) *not* being used by the majority
   of "VPN" users, whether that's site-to-site or remote-access.
   Except on iOS and Android, where OS-provided IKEv2/IPsec is winning,
   and I'll bet they could drop 3DES tomorrow.

The last time I have seen 3DES configured was for site-to-site VPNs between
different (medical!) enterprises because neither side could be sure what the
other side had, and equipment was old.  They didn't dare change the configuration, or
replace the hardware.  (Cargo culting...) This was maybe 6 years ago.

I believe that we could remove it.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 17 Apr 2020 19:07:47 -0400

Just as an aside thought about 3DES:

perhaps you saw my questions to the CFRG list where I have exactly 64 
bits to encrypt and no place for an IV or such.

One of the serious suggestions WAS 3DES with 3 keys.

For a number of reasons I am not offering that in the initial ID, rather 
AES-CFB16...

But for only 64 bits to encrypt, 3DES is a consideration.

Nah.

(also it may change to exactly 96 bits to encrypt.  They left out the UA 
Altitude and the FAA is not happy with that).

Have a good weekend all!

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 20 Apr 2020 17:00:37 -0700

Thanks all for the responses; this helps me get a better picture of the
state of things and our future direction!

> replace the hardware.  (Cargo culting...) This was maybe 6 years ago.

Funnily enough, we see a similar thing in the Kerberos world, with 3DES
cross-realm keys set up decades ago that everyone is afraid to touch :)
(It turns out that most of the time you don't actually need to get both
administrators in the same room to update things, and it can be done
asynchronously and asymmetrically, by one administrator at a time.)

-Ben

---

From: Michael Richardson <[email-masked]>
Date: Mon, 20 Apr 2020 21:48:02 -0400

> asynchronously and asymmetrically, by one administrator at a time.)

That requires clue that the current operators (no longer/don't) have.
If it breaks, they don't how to fix or debug it either.

In short: as Tero has pointed out it's already SHOULD NOT, and making it MUST
NOT makes existing deployed products out of spec.  I guess we don't have to rush.

---

From: Dan Brown <[email-masked]>
Date: Tue, 21 Apr 2020 15:58:13 +0000

Minor points about 3DES below (likely redundant).

> -----Original Message-----
> From: IPsec <[email-masked]> On Behalf Of Robert Moskowitz
>
> perhaps you saw my questions to the CFRG list where I have exactly 64 bits 
> to
> encrypt and no place for an IV or such.
>

[DB] Yes, but "serious" is not the right word.  Also, just to be super-clear, 
this was not a CFRG suggestion!

> But for only 64 bits to encrypt, 3DES is a consideration.

[DB] Last week, I looked up what NIST documents say about 3DES.
https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final
If I read them correctly, this document implies something like:
- NO: new deployment of 3DES
- OK: old deployment of 3DES encryption, until 2023, then NO more 3DES 
encryption.
- OK: old deployment of 3DES decryption (e.g. to decrypt archived stuff).
Not sure how much IPSec wants to follow NIST.  Presumably they do for 3DES, 
since 3DES is NIST's?
The text below sounds to me like IPSec is already trying to do something along 
the NIST guidelines. (So, info above I wrote above is already well-known to 
IPSec.)

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

----------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 21 Apr 2020 13:42:53 -0400 (EDT)

> the NIST guidelines. (So, info above I wrote above is already well-known to

There is also the SP800-77 rev 1 draft "Guide for IPsec"

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-77r1-draft.pdf

Which puts 3DES (TDEA) into the "Legacy" category.

It also states:

 	When migrating from IKEv1 to IKEv2, an upgrade of the algorithms
 	used is strongly recommended. 3DES, MD5, SHA-1 and DH Group
 	2 and 5 should not be used.

 	The Triple DES (3DES) encryption algorithm is no longer
 	recommended. It is much slower than AES-GCM and AES-CBC,
 	and it requires more frequent rekeying to avoid birthday attacks
 	due to its smaller block size of 64 bits.

Paul