Re: [TLS] Deployment ... Re: This working group has failed

[Juho Vähä-Herttua <[e-mail]>]

> On 17.11.2013, at 22.43, Kyle Hamilton <[e-mail]> wrote:
> 
> If the library were a drop-in replacement that didn't alter binary compatibility, it would be a simple matter to just drop it in, put a new config defaults and override file in place, and call it done.
> 
> Unfortunately, C is not this easy.
> 
...
> I have found myself despising C and C++ and other compiled-to-native languages as a result of this kind of thing.
> 

I'm not sure why C is getting the blame here. C++ has had its problems with binary compatibility across compiler versions etc, but C calling conventions are usually very clearly defined. (cdecl/stdcall separation on windows confuses this a bit) Yes, a Windows library doesn't work well in Linux, but neither do CLR binaries, Mono is not a serious option for this kind of stuff.

What is a bigger problem is designing a stable API between major upgrades. This is indeed slightly easier in languages that support overloading methods, like C++ or C#, compared to plain C. However, TLS 1.2 (and based on the discussion TLS 1.3/2.0 as well) are major updates to the protocol, I don't think it is going to be that easy to do a major upgrade without affecting the API, be it CLR or compiled to native. Having a new crossplatform dynamic loader doesn't help much if the API cannot be kept stable, it would only add new restrictions.

The problem you've brought up is certainly valid, but I'm not sure if the blame is going to the right place. Complex compilation process of OpenSSL is mostly coming from FIPS requirements as well and no platform or linker can prevent that, because the problem itself is not technical but bureaucratic. Some things just can't be avoided, but all ideas of how to make TLS upgrades less painful should be taken into account. As much as I'd like to design the protocol from scratch as well, it doesn't help if no one is going to use it.


Juho