On 26/06/17 16:00, Arne Schwabe wrote: [...snip...] >> >> Currently there is an agreement of the following profiles: >> >> - legacy: SHA1 and newer, RSA 2048-bit+, any elliptic curve. >> - preferred: SHA2 and newer, RSA 2048-bit+, any elliptic curve. >> (default in v2.5) >> - suiteb: SHA256/SHA384, ECDSA with P-256 or P-384. >> [...snip...] >> The suiteb profile is just reusing the mbed TLS definition directly. >> >> With that said ... The legacy profile does not include MD5. So either >> we allow MD5 into the legacy profile; or we need legacy-md5. >> > > Yes but I think that is seperate effort. I am not sure how to probably > implment that with OpenSSL. SECLEVEL is similar but does not have > exactly the same consequences. YOu could probably emulate the profiles > with some kind of tls-cipher settings. But if you do that, you still > need this patch :)
I agree we need to have a mechanism for adjusting the SECLEVEL/--tls-cert-profile. The challenge is that we have users which expects a similar behaviour, regardless if their OpenVPN build is using OpenSSL or mbed TLS. For end users, that matters - and we can't tell them "for this OpenVPN variant, you need to use this syntax". In addition, AFAIK the --tls-cert-profile support is already released for OpenVPN Connect. IIRC, that approach was agreed upon between James and Steffan at the last Hackathon. Unless there are really strong reasons not to continue with --tls-cert-profile, I am of the opinion we should go that path. That is to ensure sites already rolled out --tls-cert-profile will not start yelling at us later on. OpenVPN 3 based clients needs to behave similarly to OpenVPN 2.x when it comes to configuration options. And OpenVPN 3 is what is inside OpenVPN Connect and PrivateTunnel clients, which again have ties to OpenVPN Access Server. We need to ensure we don't add fragmentation inside the OpenVPN environment. Of course, it won't be easy to make the users have the same experience regardless if OpenVPN use mbed TLS or OpenSSL under the hood. But I am do strongly believe that is the proper way to handle this. OpenVPN need to "glue" this together so the user experience is unified. I am also aware that we have a few mbed TLS specific features (--use-prediction-resistance) and there are some features only available in OpenSSL (f.ex. PKCS#12 support, --capath, --engine). This is unfortunate, and we should try to reduce such gaps to an absolute minimum. So I cannot give an ACK to any patches which contributes further to such a fragmentation - unless there are really strong reasons to do so. In this particular case, both OpenSSL and mbed TLS have a similar features, so in this case it should be possible to get a unified experience. So lets try to aim for that. -- 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
