Hi, On 24-02-17 22:28, James Yonan wrote: > On 24/02/2017 02:40, Steffan Karger wrote: >> On 23-02-17 22:41, James Yonan wrote: >>> On 23/02/2017 01:22, Steffan Karger wrote: >>>> On 22-02-17 19:48, James Yonan wrote: >>>>> mbedTLS 2 has a new feature that allows rejection of certificates if the >>>>> key size is too small or the signing hash is weak. >>>>> >>>>> The feature is controlled via struct mbedtls_x509_crt_profile. >>>>> >>>>> For example, you could specify that certificates must be at least 2048 >>>>> bits and use a SHA-2 signing alg. >>>>> >>>>> Wondering if we should enable this via an option, or tie it into the >>>>> existing tls-version-min. >>>>> >>>>> The granular approach would be to have specific options for each limit, >>>>> such as ssl-min-key-size, ssl-require-sha2 >>>>> >>>>> The bundled approach would be to take an existing option such as >>>>> tls-version-min and add additional constraints onto it. For example, if >>>>> tls-version-min is 1.2 or higher, then also require minimum key size to >>>>> be 2048 and certificate signing hash to be SHA-2. >>>> OpenVPN 2.4 currently just uses mbed TLS' default profile, and we tell >>>> people to use stronger keys (RSA 2048+ / ECDSA) or a stronger hash >>>> function (SHA1+) if that causes trouble. >>>> >>>> If we are going to make this configurable, I think we should separate it >>>> from tls-version-min. The main use case I see for using a lower >>>> security setting would be an out-of-the-admins-control CA, or something >>>> like (old) smart cards that don't support RSA-2048. I wouldn't want to >>>> block people from enforcing TLS 1.2, because their smart card is crappy. >>>> >>>> So I think we'll have to add the relevant --tls-rsa-key-size-min, >>>> --tls-curves (could replace --ecdh-curves), --tls-digests options. If >>>> we want to make it configurable, that is. >>> I think it needs to be configurable to allow for transitions to stronger >>> keys. >>> >>> For naming, how about --tls-rsa-key-size-min and --tls-cert-sign-min? >> Adding 'cert' in the option name is very good, it removes confusion >> between the TLS transcript digest and the cert digest. >> >> 'sign' reads like 'signature', while RSA (or ECDSA) is the signature >> algorithm, but 'SHAx' is the certificates message digest algorithm. >> >> So, I raise you '--tls-cert-digest-min' (or '--tls-cert-md-min'?). >> >>> For --tls-cert-sign-min, the choices could be "none" (anything allowed >>> by the underlying SSL lib) or "sha2" (requiring sha256 or higher). >> This makes sense for the SHA family, but 'or higher' becomes tricky when >> e.g. BLAKE2 enters the arena. I'm uncertain whether we should worry >> about that. > > I'm still somewhat on the fence about making these options granular vs. > bundled.
Yeah, I too find it hard to decide what the best approach is here. Being involved in OpenVPN the past few years has definitely learned me the importance of choosing the options right... > If we do granular, then we need to deal with every option, i.e. rsa key > size, cert digests, curves, etc. and we need to establish defaults and a > notion of "minimum" which is problematic as you mention above when new > algs (such as BLAKE2 as you mention above) enter the mix and its not > clear where to place them on the continuum. Or avoid minimums by simple > enumerating the whole whitelist. But this can become unwieldy with so > many options. > > Using the bundled approach would be more like the mbedTLS cert profiles > approach where you have a default that allows everything reasonable, and > a somewhat stricter profile that requires RSA key sizes >= 2048 and > disallows SHA1. If we use this approach with OpenVPN, then we could > have an option --tls-cert-profile <profile-name>. We would of course > need to define named profiles for this to work. Something like --tls-cert-profile sounds good, I think. It's decoupled from --tls-version-min (which I think is good), but still doesn't offer a gazillion combinations of configurations. We good go for e.g. 'legacy', 'default', 'suiteb' and perhaps something like 'paranoid'? We'd have to keep actively monitoring cryptographic advances, and kick out algs when they become deprecated and/or broken though. -Steffan ------------------------------------------------------------------------------ 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 Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
