Deprecate --keysize

The --keysize option can only be used with already deprecated ciphers, such as CAST5, RC2 or BF. Deviating from the default keysize is generally not a good idea (see man page text), and otherwise only complicates our code.>
(If this patch is accepted, I'll send a follow-up patch to remove the option from the master branch.)

Quoted 6 lines · Steffan Karger

The --keysize option can only be used with already deprecated ciphers, such as CAST5, RC2 or BF. Deviating from the default keysize is generally not a good idea (see man page text), and otherwise only complicates our code.>
(If this patch is accepted, I'll send a follow-up patch to remove the option from the master branch.)

I agree to the wanted intention of this change. But, it hits badly if we remove --keysize on configurations still enforcing BF-CBC with --keysize 256. I don't have any numbers of how many users uses it; but I know many have preferred BF-CBC for a long time - at least before SWEET32 came and hit us all. Bare in mind that BF-CBC was the default since 2002-ish (probably even longer, if considering the OpenVPN v1.x branch). And many have added --cipher BF-CBC in their configs despite it was the default.

As long as BF-CBC is available, we cannot remove --keysize. And to remove BF-CBC support, I think that needs a bit longer timespan than v2.5. Users *must* be far better prepared for that and we need to make loud and clear announcements with such a change.

Yes, in all this, I know that NCP is a nice rescue. As long as everyone either runs v2.4 everywhere or deploys --ncp-ciphers and starts the migration. But I've lost confidence that the vast majority of our users pays closely attention to such feature changes - thus they won't notice until it stops working. We need to PUSH this information into their faces, with large posters carrying promises of rainbow coloured unicorns if they comply today(!). In addition to adding clear warnings in the log files for a looong time.

So I propose:

- We add the warning about removing --keysize for both v2.4 and v2.5.

- Add a warning in v2.4 and v2.5 that ciphers with block sizes < 128 bits will be *removed* in v2.6

- When removing those ciphers in v2.6, we can remove --keysize together with the ciphers, as it will no longer be valid. But --keysize needs to be a NOP for some time (with a warning it has no effect), to avoid OpenVPN stopping to run on upgrades.

Hi,

Quoted 35 lines · David Sommerseth

Quoted 6 lines · Steffan Karger

The --keysize option can only be used with already deprecated ciphers, such as CAST5, RC2 or BF. Deviating from the default keysize is generally not a good idea (see man page text), and otherwise only complicates our code.>
(If this patch is accepted, I'll send a follow-up patch to remove the option from the master branch.)

I agree to the wanted intention of this change. But, it hits badly if we remove --keysize on configurations still enforcing BF-CBC with --keysize 256. I don't have any numbers of how many users uses it; but I know many have preferred BF-CBC for a long time - at least before SWEET32 came and hit us all. Bare in mind that BF-CBC was the default since 2002-ish (probably even longer, if considering the OpenVPN v1.x branch). And many have added --cipher BF-CBC in their configs despite it was the default.

As long as BF-CBC is available, we cannot remove --keysize. And to remove BF-CBC support, I think that needs a bit longer timespan than v2.5. Users *must* be far better prepared for that and we need to make loud and clear announcements with such a change.

Yes, in all this, I know that NCP is a nice rescue. As long as everyone either runs v2.4 everywhere or deploys --ncp-ciphers and starts the migration. But I've lost confidence that the vast majority of our users pays closely attention to such feature changes - thus they won't notice until it stops working. We need to PUSH this information into their faces, with large posters carrying promises of rainbow coloured unicorns if they comply today(!). In addition to adding clear warnings in the log files for a looong time.

So I propose:

- We add the warning about removing --keysize for both v2.4 and v2.5.

Quoted 7 lines

- Add a warning in v2.4 and v2.5 that ciphers with block sizes < 128 bits will be *removed* in v2.6

- When removing those ciphers in v2.6, we can remove --keysize together with the ciphers, as it will no longer be valid. But --keysize needs to be a NOP for some time (with a warning it has no effect), to avoid OpenVPN stopping to run on upgrades.

Okay. Instead of sending the keysize removal patch, I'll send a patch that warns that small block ciphers will be removed in 2.6.

Can you then do s/2.5/2.6/ on the patch, or shall I send a v2?

Quoted 6 lines

The --keysize option can only be used with already deprecated ciphers, such as CAST5, RC2 or BF. Deviating from the default keysize is generally not a good idea (see man page text), and otherwise only complicates our code.>
(If this patch is accepted, I'll send a follow-up patch to remove the option from the master branch.)

I agree to the wanted intention of this change. But, it hits badly if we remove --keysize on configurations still enforcing BF-CBC with --keysize 256. I don't have any numbers of how many users uses it; but I know many have preferred BF-CBC for a long time - at least before SWEET32 came and hit us all. Bare in mind that BF-CBC was the default since 2002-ish (probably even longer, if considering the OpenVPN v1.x branch). And many have added --cipher BF-CBC in their configs despite it was the default.

As long as BF-CBC is available, we cannot remove --keysize. And to remove BF-CBC support, I think that needs a bit longer timespan than v2.5. Users *must* be far better prepared for that and we need to make loud and clear announcements with such a change.

Yes, in all this, I know that NCP is a nice rescue. As long as everyone either runs v2.4 everywhere or deploys --ncp-ciphers and starts the migration. But I've lost confidence that the vast majority of our users pays closely attention to such feature changes - thus they won't notice until it stops working. We need to PUSH this information into their faces, with large posters carrying promises of rainbow coloured unicorns if they comply today(!). In addition to adding clear warnings in the log files for a looong time.

So I propose:

- We add the warning about removing --keysize for both v2.4 and v2.5.

- Add a warning in v2.4 and v2.5 that ciphers with block sizes < 128 bits will be *removed* in v2.6

- When removing those ciphers in v2.6, we can remove --keysize together with the ciphers, as it will no longer be valid. But --keysize needs to be a NOP for some time (with a warning it has no effect), to avoid OpenVPN stopping to run on upgrades.

- Ensure these changes are synchronised within OpenVPN 3 as well

- Start a new wiki page: "How-To: Migrate to secure and modern OpenVPN configurations" where we list all deprecated features/options and their replacement (including examples). We also need to have a description on the reasoning for deprecating and removing these options.

- And the most tricky one: Get some publicity that OpenVPN is going to deprecate and remove support for weak ciphers out to the public. Not just on crypto focused sites, but more broadly reaching "media
channels". (I believe we can facilitate some of the PR work done by
the company, but we do need more than that). Channels/sites I'm pondering on:

~ An official Press Release by the company? (Samuli and I can check) ~ twitter (via the @OpenVPN account)
~ reddit? (and similar sites)
~ LWN.net
~ arstechnica
~ ThreatPost
~ OS Distribution channels (blog posts, mailing lists, etc) ~ Our own wiki and web pages
~ others?

The first round is to clearly state that BF-CBC, CAST and RC2 are deprecated and their support will be removed in a coming release (not mentioning version, on purpose!). Users are strongly advised to upgrade to OpenVPN v2.4 or server and client side instantly, to benefit from NCP (byt more less-tech worded) and to point at the "How-To" described above.

And then we try to re-iterate this once again with the release of v2.5 and v2.6.

I know and understand this hurts security focused people, and probably in even more those who understand crypto very well. But my personal experience is that the average users are usually less understanding than security minded people. (Yes, I've burnt my, and other's, fingers within the Fedora community with the v2.4 upgrade)

--
kind regards,

David Sommerseth
OpenVPN Technologies, Inc

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

2017-08-14 15:36 GMT+05:00 David Sommerseth <
[email protected]...>:

Quoted 14 lines · Steffan Karger

So I propose:

- We add the warning about removing --keysize for both v2.4 and v2.5.

- Add a warning in v2.4 and v2.5 that ciphers with block sizes < 128 bits will be *removed* in v2.6

- When removing those ciphers in v2.6, we can remove --keysize together with the ciphers, as it will no longer be valid. But --keysize needs to be a NOP for some time (with a warning it has no effect), to avoid OpenVPN stopping to run on upgrades.

Quoted 8 lines

- Ensure these changes are synchronised within OpenVPN 3 as well

- Start a new wiki page: "How-To: Migrate to secure and modern OpenVPN configurations" where we list all deprecated features/options and their replacement (including examples). We also need to have a description on the reasoning for deprecating and removing these options.

there are special cases like Mikrotik openvpn (pretty popular), where user simply use what hardware vendor installed (without possibility to recompile).

should we contact such hardware vendors as well ?

Quoted 26 lines

2017-08-14 15:36 GMT+05:00 David Sommerseth <
[email protected]...>:

Quoted 14 lines · Steffan Karger

So I propose:

- We add the warning about removing --keysize for both v2.4 and v2.5.

- Add a warning in v2.4 and v2.5 that ciphers with block sizes < 128 bits will be *removed* in v2.6

- When removing those ciphers in v2.6, we can remove --keysize together with the ciphers, as it will no longer be valid. But --keysize needs to be a NOP for some time (with a warning it has no effect), to avoid OpenVPN stopping to run on upgrades.

Quoted 8 lines

- Ensure these changes are synchronised within OpenVPN 3 as well

- Start a new wiki page: "How-To: Migrate to secure and modern OpenVPN configurations" where we list all deprecated features/options and their replacement (including examples). We also need to have a description on the reasoning for deprecating and removing these options.

Quoted 5 lines

there are special cases like Mikrotik openvpn (pretty popular), where user simply use what hardware vendor installed (without possibility to recompile).

should we contact such hardware vendors as well ?

there might be an non-predictable number of vendors shipping their own openvpn version. We can't contact them all. It's their responsibility to stay behind the changes in what they ship.

If they don't, their users will complain aloud with them ;)

On top of that, this does not prevent users from using their own config, right? So they can still configure the client to avoid deprecated options.

Cheers,

--
Antonio Quartulli

Quoted 5 lines

there are special cases like Mikrotik openvpn (pretty popular), where user simply use what hardware vendor installed (without possibility to recompile).

should we contact such hardware vendors as well ?

there might be an non-predictable number of vendors shipping their own openvpn version. We can't contact them all. It's their responsibility to stay behind the changes in what they ship.

If they don't, their users will complain aloud with them ;)

On top of that, this does not prevent users from using their own config, right? So they can still configure the client to avoid deprecated options.

you cannot use regular openvpn config with Mikrotik
https://wiki.mikrotik.com/wiki/OpenVPN

you can use mikrotik configuration options

[...]

Quoted 20 lines

Quoted 5 lines

there are special cases like Mikrotik openvpn (pretty popular), where user simply use what hardware vendor installed (without possibility to recompile).

should we contact such hardware vendors as well ?

there might be an non-predictable number of vendors shipping their own openvpn version. We can't contact them all. It's their responsibility to stay behind the changes in what they ship.

If they don't, their users will complain aloud with them ;)

On top of that, this does not prevent users from using their own config, right? So they can still configure the client to avoid deprecated options.

you cannot use regular openvpn config with Mikrotik
https://wiki.mikrotik.com/wiki/OpenVPN

Quoted 1 line

you can use mikrotik configuration options

Which just emphasizes even more that Mikrotik needs to do their own homework on their own. Their config syntax is completely alien to us, so we have no direct influence on how their syntax ends up as a configuration OpenVPN is capable of understanding. And _we_ shouldn't care how Mikrotik does that, it's their own implementation design.