I think we should just remove these in 13. Who is harmed if we gone_in(13, TDEA/3DES?

I did ping Ben off list about 3DES and he seemed to think 14 was more prudent than 13 for IPsec:

While I personally am happy to see the end of triple-DES in general (I
wrote RFC 8429, after all), it seems that in the IKE world it is not quite
as much of a no-brainer as one might think:
https://datatracker.ietf.org/meeting/104/materials/minutes-104-ipsecme-00
suggests that we cannot get rid of it quickly, due to use in telephony.
That said, telephony has been making progress in cryptography recently, as
the US has a mandate pending to use the SHAKEN/STIR mechanisms to reduce
caller-ID spoofing, so I cannot rule out telephony also migrating off 3DES.
But for now, deprecating it for 14.0 is probably the right choice.

While I'm definitely a fan of removing older, non-ideal crypto, we also have to allow some leeway for what people still deploy in practice. I'm not really sure if FreeBSD is really used in that market TBH, but realistically this only delays rm'ing the code in head by a year or so.

In D24341#537325, @jhb wrote:

I did ping Ben off list about 3DES and he seemed to think 14 was more prudent than 13 for IPsec:

While I personally am happy to see the end of triple-DES in general (I
wrote RFC 8429, after all), it seems that in the IKE world it is not quite
as much of a no-brainer as one might think:
https://datatracker.ietf.org/meeting/104/materials/minutes-104-ipsecme-00
suggests that we cannot get rid of it quickly, due to use in telephony.
...

The link is devoid of any actual basis for that assertion. It's literally just "cannot get rid of 3des. used in telephony."

If we take for granted that the assertion is true: telephony has a strong history of clownshoes security, and I don't think we should enable them. We don't have any evidence these are actual FreeBSD users who will actually update to 13. To the extent this group is real, they haven't managed to migrate to AES in the 19 years since its standardization by NIST. IMO, they will keep using the worst option available until it is literally removed from their grasp. This is the industry that continues to use SS7, dating to 1975. If they're even running FreeBSD, it's probably FreeBSD 6 or something else awful.

NIST has deprecated it and "plans to disallow" since 2017: https://csrc.nist.gov/News/2017/Update-to-Current-Use-and-Deprecation-of-TDEA

And on the flip side: I'm disinclined to believe the assertion without evidence.

While I'm definitely a fan of removing older, non-ideal crypto, we also have to allow some leeway for what people still deploy in practice. I'm not really sure if FreeBSD is really used in that market TBH, but realistically this only delays rm'ing the code in head by a year or so.

I don't think we should allow people to deploy long-broken crypto. DES has been broken for a quarter of a century. AES is old enough to be in college. It's time to kill 3DES. If they want broken crypto, they can use FreeBSD 12.

In D24341#537336, @cem wrote:

In D24341#537325, @jhb wrote:

I did ping Ben off list about 3DES and he seemed to think 14 was more prudent than 13 for IPsec:

While I personally am happy to see the end of triple-DES in general (I
wrote RFC 8429, after all), it seems that in the IKE world it is not quite
as much of a no-brainer as one might think:
https://datatracker.ietf.org/meeting/104/materials/minutes-104-ipsecme-00
suggests that we cannot get rid of it quickly, due to use in telephony.
...

The link is devoid of any actual basis for that assertion. It's literally just "cannot get rid of 3des. used in telephony."

The minutes only have to record the conclusions. You or I are welcome to watch the recording and/or ask the WG list for further clarification.

If we take for granted that the assertion is true: telephony has a strong history of clownshoes security, and I don't think we should enable them. We don't have any evidence these are actual FreeBSD users who will actually update to 13. To the extent this group is real, they haven't managed to migrate to AES in the 19 years since its standardization by NIST. IMO, they will keep using the worst option available until it is literally removed from their grasp. This is the industry that continues to use SS7, dating to 1975. If they're even running FreeBSD, it's probably FreeBSD 6 or something else awful.

NIST has deprecated it and "plans to disallow" since 2017: https://csrc.nist.gov/News/2017/Update-to-Current-Use-and-Deprecation-of-TDEA

That's good; I'm happy to see that!
I'm trying to provide input from the people who maintain the protocol on what algorithms are expected to be in use over the full spread of users.
You are welcome to ignore that input, especially if you think that your subset of users has a different set of needs than the full spread of users of the protocol.
But there's just as much need to document such an assertion as there is to document the assertion that TDES is used in IPsec for telephony.

And on the flip side: I'm disinclined to believe the assertion without evidence.

While I'm definitely a fan of removing older, non-ideal crypto, we also have to allow some leeway for what people still deploy in practice. I'm not really sure if FreeBSD is really used in that market TBH, but realistically this only delays rm'ing the code in head by a year or so.

I don't think we should allow people to deploy long-broken crypto. DES has been broken for a quarter of a century. AES is old enough to be in college. It's time to kill 3DES. If they want broken crypto, they can use FreeBSD 12.

Sorry, remind me how DES is broken other than just having a 64-bit key and being brute-forceable? Like, something that would translate to an attack on 3DES?
I have no love for 3DES; I wrote RFC 8429. But the arguments you are making in support of this course of action do not come off as giving a strong case that we need to urgently take action right now. What harm is there in the more leisurely deprecation path? Is the code a burden to maintain for a few more years?

This doesn't seem productive.

There's some more discussion ongoing at https://mailarchive.ietf.org/arch/msg/ipsec/IyE2dP17oKPFXeBgSs6hjfjXiIE/ which may end up indicating that gone_in(13) is more reasonable for us.

In D24341#537467, @bjk wrote:

There's some more discussion ongoing at https://mailarchive.ietf.org/arch/msg/ipsec/IyE2dP17oKPFXeBgSs6hjfjXiIE/ which may end up indicating that gone_in(13) is more reasonable for us.

My take on reading the responses in that thread is that removing in 13 probably is fine. If it really is 1990's boxes doing 3des, then those probably aren't relevant peers for FreeBSD 13.0. Also, unlike the assumption of the one response that is more mixed, FreeBSD users are fairly capable at using older releases if necessary. Thanks for prodding them to get more detail.

In D24341#537980, @jhb wrote:

In D24341#537467, @bjk wrote:

There's some more discussion ongoing at https://mailarchive.ietf.org/arch/msg/ipsec/IyE2dP17oKPFXeBgSs6hjfjXiIE/ which may end up indicating that gone_in(13) is more reasonable for us.

My take on reading the responses in that thread is that removing in 13 probably is fine. If it really is 1990's boxes doing 3des, then those probably aren't relevant peers for FreeBSD 13.0. Also, unlike the assumption of the one response that is more mixed, FreeBSD users are fairly capable at using older releases if necessary. Thanks for prodding them to get more detail.

I agree; removing in 13 seems more reasonable to me now.