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!

On 4/15/20 8:49 AM, Tero Kivinen wrote:
Benjamin Kaduk writes:
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.?
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.

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

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to