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

Watson Ladd <> Mon, 18 November 2013 04:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C7B611E822A for <>; Sun, 17 Nov 2013 20:50:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.14
X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QPXtV5655yQw for <>; Sun, 17 Nov 2013 20:50:35 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c03::22b]) by (Postfix) with ESMTP id 5B6CD11E8165 for <>; Sun, 17 Nov 2013 20:50:35 -0800 (PST)
Received: by with SMTP id t61so5680835wes.16 for <>; Sun, 17 Nov 2013 20:50:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GzwR5I9Rfaf65bEMHLHeGf6i0goJnz/BozVgoBYZFII=; b=axnmU3qppzEMy7LmCjTPR30dFer2shtAC4MqDar3Hge4+2whI48pX7yjwdS/2zwYdA liSXBx3dMBUVx+hDFtdaWE6ttyM8JTF2sXE5gmAKKmhEV+mbDkymz0KSGj3UAkaUxj2V 0dAs35PJXwL+cvHYSmj4PFazFzUbUe8eMWpHlV3yvrffaAXJTe83lbPClVgWw8Spl8Ag yUAPYb1PZjkJFsZ05v9hQ8dbs4g/t1os7TqqJ22DzzUGOOHHH5vmrhaVk50/yzrApoM9 gb8k2CSJqJY+g8yeT2hkpkImrtDhmPX6tC9fXB4atfE8OXutlFsoyMeMcksOHnhF5jph TTMQ==
MIME-Version: 1.0
X-Received: by with SMTP id ev13mr15046958wjd.20.1384750234352; Sun, 17 Nov 2013 20:50:34 -0800 (PST)
Received: by with HTTP; Sun, 17 Nov 2013 20:50:34 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Sun, 17 Nov 2013 20:50:34 -0800
Message-ID: <>
From: Watson Ladd <>
To: =?UTF-8?B?SnVobyBWw6Row6QtSGVydHR1YQ==?= <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>, Kyle Hamilton <>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 18 Nov 2013 04:50:37 -0000

TLS 1.2 solves the same problem as TLS 1.0. It should therefore have
the same API.
Somehow, having a state machine driven by data coming from a socket
driven by various options is
hard to design a good API around. (Seriously, transition(stateobject,
data_fed_in, length of data, data_maybe_coming_out, length_out) and
getcurrentstate(stateobject) together with some queries and setup of
options would do just fine.)

Part of the reason for the lack of updates is good Internet
citizenship brings no rewards. F5 customers don't give a damn about
holding the rest of
us back so long as that little lock icon still appears, embedded
device makers see no reason to upgrade, etc. Add this to the fight of
browser makers for market share, and anything that is good to do/has a
risk of breaking some sites will not get done.

The complexity of OpenSSL building, and most of the complexity of
OpenSSL is purely gratuitous. There is no reason it cannot be as clear
as the Go TLS library or PolarSSL.

This of course means that we have to live with whatever choices we
make for a long time, and ensure that implementations are simple
to be bug-free.
Watson Ladd