opened
whislock
username_0
This conforms to current recommendations and best practices for a
128-bit security margin.

2048 is still the minimum recommended, but 2048-bit RSA only aligns to a
112-bit security margin, roughly analogous to 3DES. AES-128, the
minimum recommended cipher, requires a 3072-bit RSA key and a 256-bit digest
(SHA256) to provide an equivalent security level in all cryptographic
components.
Added 3072-bit key length options.
issue
created
whislock
username_0
Need to further test this.
comment
created
whislock
username_0
Additional question: Where are we sourcing the sample DH parameter files from?
comment
created
fichtner
username_1
This should be split in two: 3072 bits for certificates and 3072 bits for DH. For the latter it may be more favourable to avoid adding a lot of "odd" DH default params to the system, because...

... to answer your question we sporadically provide new parameters and it takes a long time to update them if they grow in number (and bit size).
comment
created
fichtner
username_1
I know it's a standard, but if I regenerate fr a release it already takes a while, adding more standard sizes will make it even longer, making it less likely to provide new files for the existing ones.
comment
created
whislock
username_0
So, more to the point, you should not be generating DH parameters for releases. You should be using the default ones from RFC 7919. If the end-user wants to use custom parameter sets, they should generate them themselves.
comment
created
fichtner
username_1
Fine, so who will do the work necessary to avoid lower security in these circumstances? When will we be switching to a default regeneration of DH parameters and how will it be done? How do we minimise the gap between using default parameters and custom parameters in new installs? Do we have all the code in place or do we need to do more? How much *measurable* security will we gain from doing what is suggested here?

Besides this my review points still stand... if you want a change merged please split it into Cert and DH parts...
comment
created
whislock
username_0
That depends on your risk profile and tolerance. For most users, this would be a transparent change whose benefits may never be observed. In raw terms, shipping audited and standard values provides an assurance that the values included with the release were not tampered with or poorly-generated. A "nothing up my sleeve" number, if you will.

The Mozilla Foundation states this advice explicitly. [Server-Side TLS](https://wiki.mozilla.org/Security/Server_Side_TLS#Pre-defined_DHE_groups) While the page itself may offer guidance on configuring web servers, the rest of it is fully-applicable to anything participating in TLS connections.
comment
created
fichtner
username_1
We've been following up on https://weakdh.org/sysadmin.html ever since 2015 and this is the first complaint that it's *all wrong*. What you state here is therefore news to me. On first glance I cannot find enough info to back up your claims, so I'll park this PR and ask around to give it the benefit of the doubt it deserves and I wish you will do the same for what we have currently in place.
comment
created
fichtner
username_1
Ah, thanks for the clarification.
comment
created
whislock
username_0
I'm going to undo the commits to the DH portions so that the cert parts can go in under this PR, and I'll submit a DH-specific PR later if its agreed upon.
comment
created
whislock
username_0
Done.
comment
created
fichtner
username_1
Merged, thank you.

As for RFC 7919, how about we make them optionally usable? We already have a mode selector in the development version. This also means one day we could switch to them by default in new installation and not take anything away from existing users.
comment
created
fichtner
username_1
Because we're not making RFC 71919 a default unless the community is willing to support this move. So the community needs to be engaged, best by shipping options to them to try out and discuss further in the forum. :)

Other issue is that 1024 is not provided by RFC, but still of deprecated use in existing installs so you end up with a mixed or broken environment on upgrade if we were to do the switch. As a stopgap we'll be bumping the defaults in OpenVPN to 2048 with 18.1.10 and then give RFC a fair chance on 18.7 so that we could switch to it by default when 19.1 is out.
comment
created
whislock
username_0
The "wisdom of crowds" approach is not the correct approach where crypto is concerned. The fact that you accepted a pull request predicated on the idea that periodic regeneration of DH groups is good or necessary is proof of that fact. Do what you will, but this is the wrong approach.
comment
created
fichtner
username_1
Your mind is set; I have no reason to change it. :)
comment
created
whislock
username_0
My mind isn't the issue. I have standards and best practices on my side, reinforced with documentation. You're choosing to ignore that, which is strange to me.

You accepted a pull request regarding DH params with "a couple dudes talked about it on IRC" as support, but you resist this proposal when an actual RFC exists in support of the proposal with the statement of "we're not doing this unless the community supports it." Talk about double standards. I won't be contributing further to this project.
comment
created
fichtner
username_1
You have:

1. Asserted that you set your opinion above a community voice in an open source project scope.
2. You continue to be pushy with no regard for other people's schedules, ideas and explicit questions to give "the benefit of the doubt".
3. Have failed to realise that 90% of what you asked is already in the development version.

Feel free to not back off, but in any case this is the last you see of me responding.


Thanks,
Franco
comment
created
whislock
username_0
Again, that's on you. I have the knowledge and expertise to render a judgment on this. It's a shame you choose not to benefit from it.
comment
created
fichtner
username_1
Your assertion is wrong and it makes you act like a less than favourable human being. People live and learn, either with you or without you. I'm closing this thread, because you continue to deviate from the topic for attacks because you don't get what you want.
comment