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

Juho Vähä-Herttua <juhovh@iki.fi> Sun, 17 November 2013 21:48 UTC

Return-Path: <juhovh@iki.fi>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE5A11E886D for <tls@ietfa.amsl.com>; Sun, 17 Nov 2013 13:48:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.902
X-Spam-Level:
X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44nDx4b1vs7P for <tls@ietfa.amsl.com>; Sun, 17 Nov 2013 13:48:27 -0800 (PST)
Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by ietfa.amsl.com (Postfix) with ESMTP id 7276511E92EC for <tls@ietf.org>; Sun, 17 Nov 2013 13:48:26 -0800 (PST)
Received: from [10.187.75.77] (85-76-137-52-nat.elisa-mobile.fi [85.76.137.52]) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id 866F4216601; Sun, 17 Nov 2013 23:48:19 +0200 (EET)
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com> <52874576.9000708@gmx.net> <CAPMEXDbgp5+Gg6mkMWNrcOzmAbSpv3kjftGV0cjpqvMnRxpw=A@mail.gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CAPMEXDbgp5+Gg6mkMWNrcOzmAbSpv3kjftGV0cjpqvMnRxpw=A@mail.gmail.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-EA1E4120-FAC6-4EAE-AE91-8B6B895C061C
Content-Transfer-Encoding: 7bit
Message-Id: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi>
X-Mailer: iPhone Mail (11B554a)
From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= <juhovh@iki.fi>
Date: Sun, 17 Nov 2013 23:44:44 +0200
To: Kyle Hamilton <aerowolf@gmail.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Nov 2013 21:48:43 -0000

> On 17.11.2013, at 22.43, Kyle Hamilton <aerowolf@gmail.com> 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