On 24/02/2017 16:10, Steffan Karger wrote: > 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. >
That sounds good. So how about legacy allows 1024-bit RSA keys and sha1, default requires 2048-bit keys and sha256 or higher? James ------------------------------------------------------------------------------ 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
