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

Watson Ladd <> Mon, 18 November 2013 16:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 94B4911E811A for <>; Mon, 18 Nov 2013 08:35:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.33
X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YG4wTihVN1LS for <>; Mon, 18 Nov 2013 08:35:13 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c00::22f]) by (Postfix) with ESMTP id 5CC1D11E810F for <>; Mon, 18 Nov 2013 08:34:44 -0800 (PST)
Received: by with SMTP id y10so6322620wgg.2 for <>; Mon, 18 Nov 2013 08:34:43 -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=ycxaeC7Zn3EHFlnZScHIsJLwAc+8bw5JSKZC/W81Mbk=; b=1InL+WJ6crX6h51NSrKG2746n6k4MUZ7eLrlkgdK4suzn7HkS2WOj2ave4TjW8j7Oq tx3uTkAoXok9I7V8BcKfnwJ9C+2NO0U3mJDnNlwVcIgdVdDk1ofK3wcoBgBYMMOtzD1L 2a3jkubO8zO+3jplv7rxAhp1awly83PzpWxCwe2kXi2GkR8OOq51CaE0N3wkyya3Q5gg XcmwvCK0inlffXd2fRQniVM5oaoRNCgtSAOTBID4u6q+O1RYi1MJBvvHyaKS7XtyXkkG TWyTYnlqSmokAmJA85bus4IOjVeVEmE05RMOzGy0sjpUWBL0Q7naYz5nu7UH57GLbmBl EV8g==
MIME-Version: 1.0
X-Received: by with SMTP id fy1mr5100365wib.10.1384792483514; Mon, 18 Nov 2013 08:34:43 -0800 (PST)
Received: by with HTTP; Mon, 18 Nov 2013 08:34:43 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Mon, 18 Nov 2013 08:34:43 -0800
Message-ID: <>
From: Watson Ladd <>
To: "Salz, Rich" <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>
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 16:35:15 -0000

On Mon, Nov 18, 2013 at 7:02 AM, Salz, Rich <> wrote:
>> TLS 1.2 solves the same problem as TLS 1.0. It should therefore have the same API.
> Do you really believe this or are you trying to just be provocative?
Do you really believe that backwards compatibility at the source level
had to be sacrificed?
Stable interfaces are the norm, unstable ones are remarkable. How many
prongs does a ground-fault detecting electricity socket have?
BLAS has multiple implementations, all with the same API. MPI looks
the same on a bunch of Xboxes wired together with Ethernet as it does
on a several million dollar supercomputer. GMP doesn't gratuitously
change its interface with every performance enhancement, and to this
day "Hello World" works unchanged on my machine, some 40 years after
it first ran on a PDP-11. Everything about the environment it runs on
is different, from the word size, to the endianness, to the output
mechanism, to the interface I am using. And yet it works with only a

TCP has undergone many changes to the implementation, yet the BSD
sockets API still works. Why exactly does an application need to care
about which ciphersuite is used? Why does it need to do more than hand
over some trusted PKI roots, and a server certificate?

The current APIs have caused lots of security bugs as people don't use
them correctly. The solution: high level APIs that won't change when
the implementation is upgraded. Is this really too lofty a goal? The
costs of the current approach are obvious: what are the costs of
making better APIs?
Watson Ladd

> --
> Principal Security Engineer
> Akamai Technology
> Cambridge, MA

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin