Re: [Openvpn-devel] Should we use mbedTLS certificate profiles?
On 28-02-17 06:09, James Yonan wrote: > On 27/02/2017 18:18, David Sommerseth wrote: > >> On 27/02/17 23:06, James Yonan wrote: >>> On 25/02/2017 08:40, Steffan Karger wrote: >> [...snip...] I'd say so. Something like: legacy: RSA 1024+, SHA1+, all curves default: RSA 2048+, SHA2+, all curves suiteb: no RSA, SHA256/SHA384, P-256/P-384 As long as we kick anything that's deprecated out of 'default', that should probably suffice. >>> That sounds good, but I'm thinking that we should probably name >>> "default" something else, such as "standard", so there's no confusion >>> between the cert profile name, and which cert profile is chosen by >>> default which may vary according to app preferences/settings. >>> >>> For example in mobile clients, we would probably need an app-level >>> setting to indicate whether "legacy" or "standard" should be the >>> default, but that would be confusing if "default" was actually a profile >>> name. >> There's a narrow edge here before it becomes bike-shedding; I do try to >> avoid that ... but what about: legacy, preferred and suiteb ? >> >> "Standard" just sounds a bit too static to me, that is not something >> which changes much. So in 5 or 10 years from now, "standard" may just >> as much be "legacy". Hence my suggestion for "preferred"; this is what >> we prefer now. "legacy" is what we used and can even include what we >> preferred earlier. > > I'm okay with legacy, preferred and suiteb. Me too. -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
Re: [Openvpn-devel] Should we use mbedTLS certificate profiles?
On 27/02/2017 18:18, David Sommerseth wrote: > On 27/02/17 23:06, James Yonan wrote: >> On 25/02/2017 08:40, Steffan Karger wrote: > [...snip...] >>> I'd say so. Something like: >>> >>> legacy: RSA 1024+, SHA1+, all curves >>> default: RSA 2048+, SHA2+, all curves >>> suiteb: no RSA, SHA256/SHA384, P-256/P-384 >>> >>> As long as we kick anything that's deprecated out of 'default', that >>> should probably suffice. >> That sounds good, but I'm thinking that we should probably name >> "default" something else, such as "standard", so there's no confusion >> between the cert profile name, and which cert profile is chosen by >> default which may vary according to app preferences/settings. >> >> For example in mobile clients, we would probably need an app-level >> setting to indicate whether "legacy" or "standard" should be the >> default, but that would be confusing if "default" was actually a profile >> name. > There's a narrow edge here before it becomes bike-shedding; I do try to > avoid that ... but what about: legacy, preferred and suiteb ? > > "Standard" just sounds a bit too static to me, that is not something > which changes much. So in 5 or 10 years from now, "standard" may just > as much be "legacy". Hence my suggestion for "preferred"; this is what > we prefer now. "legacy" is what we used and can even include what we > preferred earlier. I'm okay with legacy, preferred and suiteb. 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
Re: [Openvpn-devel] Should we use mbedTLS certificate profiles?
On 27/02/17 23:06, James Yonan wrote: > On 25/02/2017 08:40, Steffan Karger wrote: [...snip...] >> I'd say so. Something like: >> >> legacy: RSA 1024+, SHA1+, all curves >> default: RSA 2048+, SHA2+, all curves >> suiteb: no RSA, SHA256/SHA384, P-256/P-384 >> >> As long as we kick anything that's deprecated out of 'default', that >> should probably suffice. > > That sounds good, but I'm thinking that we should probably name > "default" something else, such as "standard", so there's no confusion > between the cert profile name, and which cert profile is chosen by > default which may vary according to app preferences/settings. > > For example in mobile clients, we would probably need an app-level > setting to indicate whether "legacy" or "standard" should be the > default, but that would be confusing if "default" was actually a profile > name. There's a narrow edge here before it becomes bike-shedding; I do try to avoid that ... but what about: legacy, preferred and suiteb ? "Standard" just sounds a bit too static to me, that is not something which changes much. So in 5 or 10 years from now, "standard" may just as much be "legacy". Hence my suggestion for "preferred"; this is what we prefer now. "legacy" is what we used and can even include what we preferred earlier. -- kind regards, David Sommerseth OpenVPN Technologies, Inc signature.asc Description: OpenPGP digital signature -- 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
Re: [Openvpn-devel] Should we use mbedTLS certificate profiles?
On 25/02/2017 08:40, Steffan Karger wrote: > On 25-02-17 07:04, James Yonan wrote: >> On 24/02/2017 16:10, Steffan Karger wrote: >>> 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 . 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? >> > I'd say so. Something like: > > legacy: RSA 1024+, SHA1+, all curves > default: RSA 2048+, SHA2+, all curves > suiteb: no RSA, SHA256/SHA384, P-256/P-384 > > As long as we kick anything that's deprecated out of 'default', that >
Re: [Openvpn-devel] Should we use mbedTLS certificate profiles?
On 25-02-17 07:04, James Yonan wrote: > On 24/02/2017 16:10, Steffan Karger wrote: >> 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 . 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? > I'd say so. Something like: legacy: RSA 1024+, SHA1+, all curves default: RSA 2048+, SHA2+, all curves suiteb: no RSA, SHA256/SHA384, P-256/P-384 As long as we kick anything that's deprecated out of 'default', that should probably suffice. -Steffan -- Check out the vibrant tech community on one of
Re: [Openvpn-devel] Should we use mbedTLS certificate profiles?
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 . 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
Re: [Openvpn-devel] Should we use mbedTLS certificate profiles?
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 . 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
Re: [Openvpn-devel] Should we use mbedTLS certificate profiles?
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. 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 . We would of course need to define named profiles for this to work. 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
Re: [Openvpn-devel] Should we use mbedTLS certificate profiles?
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. > Wondering what the defaults should be. The mbed TLS x509 defaults look pretty sane to me: * Cert signatures: RSA2048+ or ECDSA with any curve * Cert digests: SHA1+ It might be nicer to bump the digest to SHA2+, if we are going to make it configurable though. Especially since Google and Stevens just gave us another stick to slap people using SHA1 with[0]. -Steffan [0] https://shattered.io/ -- 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
Re: [Openvpn-devel] Should we use mbedTLS certificate profiles?
On 23/02/2017 01:22, Steffan Karger wrote: > Hi James, > > 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? For --tls-cert-sign-min, the choices could be "none" (anything allowed by the underlying SSL lib) or "sha2" (requiring sha256 or higher). Wondering what the defaults should be. James > > -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 -- 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
Re: [Openvpn-devel] Should we use mbedTLS certificate profiles?
Hi James, 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. -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
