Hi, On 22-06-2020 16:01, Arne Schwabe wrote: > Am 22.06.20 um 14:43 schrieb Steffan Karger: >> Maybe these should be the steps: >> >> 2.4: Use to AES-256-GCM when available (basically what NCP did) >> 2.5: Switch to AES-256-GCM as the default cipher (but allow overriding) >> 2.6: Remove support for small block ciphers all together >> >> Yes, this will probably break some (less secure) setups and make some >> people angry. But at some point people need to move on. We've been >> throwing warnings at them for a while now. > > I had a different suggestion in the channel: > > - Deprecate ncp-disable. Reason: Was a good debug switch when introduced > should not be necessary anymore.
Deprecate in 2.5, remove in 2.6 makes sense to me.
Should we do the same for --cipher in P2MP configs?
> - Introduce ncp-fallback-cipher for compatibility with ncp-disable/old
> versions
> - needs to be a cipher from ncp-ciphers list
> - Eventually default the first cipher from ncp-ciphers list
> - in 2.5 default to --cipher if --cipher is set and automatically
> add cipher to ncp-ciphers and set ncp-fallback-cipher.
>
> - If cipher is not set
> a) warn about that cipher will be ignored in p2mp mode and if BF-CBC is
> still needed (e.g. peer 2.3 or older) that ncp-fallback-cipher should be set
> b) same a) but do it automatically for the user+warn
>
> This allows us to eventually get rid of --cipher while providing still a
> smooth transaction.
That does sounds more friendly than my proposal.
But do we really need an extra option? Does is really differ so much
from changing the default cipher to AES-256-CBC? Both proposals require
config changes to keep old clients working with 2.5+ if --cipher wasn't
set explicitly.
We already have a lot of things in place to cater for a smooth transition:
- 2.4+ does NCP by default.
- Any 2.4+ client always sends OCC strings, which makes "poor man's
NCP" work for --ncp-disable clients as long as their cipher is in the
server's --ncp-ciphers list.
- pre-2.4 clients almost always send OCC strings too, except for
ENABLE_SMALL builds.
- If NCP and poor-man's NCP fail, 2.5 can (if --cipher is explicitly
set) fall back to whatever is in --cipher and print a big fat warning
that this connection will break in 2.6.
- If someone *really* wants to have 2.3 ENABLE_SMALL clients connect to
a 2.6 server, they can run a separate server for those clients with only
the cipher of their choice in --ncp-ciphers ("Fall back to the first
cipher", as you proposed).
Basically: if we can agree to no longer guarantee interoperability
between 2.6+ and 2.3- ("mostly just works, but special cases - in
particular ENABLE_SMALL builds - might break"), I don't think we need to
add yet another option.
-Steffan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
