Re: [Openvpn-devel] [PATCH] Set tls-cipher restriction before loading certificates

[David S. <op...@sf...>]

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